PM Goes Radical on Agile

Project manager's view on agile methods ...

Agile Expertise Shared

PMO director and senior project manager share their experiences with agile project management methods. ...

Plan and Estimate using Agile

Agile techniques are not just for small projects. ...

Agile Scrum Concepts Discussed

Ken Schwaber, the original scrummaster, visits the Googleplex to discuss agile techniques. ...






The Agile Alliance

Enterprise Architecture Comes to Forefront

David Linthicum, an author and respected expert on integration, shares thoughts on the importance of a well-planned enterprise architecture and leveraging architects to develop a sustainable roadmap. ...

... "If investors hold management accountable for accounting irregularities and missed sales, then lost dollars around the ineffectiveness of IT can't be far behind. Thus, the ability to maintain effective and agile enterprise architecture is indeed a corporate responsibility ... " ...

Via InfoWorld: SOA

Google Project Manager Clip

Quick video insights from Google project manager ...

Agile starting to scale, but...

Here's a nice summary of the Agile 2007 conference:

...proposals and ideas delivered at Agile 2007 demonstrate that while agile is starting to scale, it still has along way to go before the methodology becomes robust enough for enterprise deployment.

Agile 2007 Roundup: Scaling to the Enterprise by Tony Baer 17 Aug 2007

Project Management Wisdom: PMThink Readers Speak

We recently asked PMThink readers to contribute the best project management advice they've even received. Here's the compiled list:

"Great organizations, especially those that do well over the long haul, are masters of the obvious and the mundane." - Bob Sutton, Harvard Business Online, May 4, 2007.
(contributed by PMThink blogger Garry Booker)

"Always remember, there is only us" - Alistair Cockburn, on collaboration instead of "us vs them", in Agile Software Development 2nd Ed.
(contributed by John Rusk)

It's about the people...not the processes or tasks. You treat your people right, they'll make sure the project is right.
(contributed by Eric Brown)

"When people don't care about a project they can find a 100 good ways to make it not work that aren't their fault"
(contributed by Jason Bates)

"Make sure you really need a collaboration/project management tool before you try to use one." Many times a PM or collab tool is overkill for something that you could have accomplished in a phone call, a single email or a single document.
(contributed by Isaac Garcia)

Although the PMBOK puts the statistic a little lower, experience shows that -- "100% of SUCCESSFUL project management is communication" (whether it is used for team building, coordination of activities, collection/ dissemination of data/metrics and status)
(contributed by Laurie)

I always try to balance the interest of the people. Always find out how you can make person "A" agree on an idea that contradicts his own idea.
(contributed by Randy, PMP)

"Your success is driven in large part by your ability to leverage the community you build around you."- Scott Allen and David Teten , authors, 'The Virtual Handshake'
(contributed by Jason Bates)

"Never take anything for granted, never assume that something is happening, check"
(contributed by Frederic Casagrande)

"If you can't measure it, you can't manage it"
(contributed by Lucas Rodriguez Cervera)

I also noticed that Frederic Casagrande (who, incidentally, won our drawing) has a great list of additional tips for project managers on his website...

1. You can't manage a Project on your own.
2. Never take anything for granted, never assume that something is happening, check.
3. Seek to understand before you seek to be understood.
4. Delegate and remember there is more than one way to complete the same task.
5. Allow the team to take responsibility for the tasks assigned to them.
6. Manage the sponsor and don't let them manage you, you own the project.
7. Be realistic with the expectations.
8. Everything is resolvable, it just may take time to find that solution. If something goes wrong, don't take it personally, it's not about life and death.
9. Look at the whole picture and keep the end in mind.
10. Taking a decision and moving forward is always preferable to indecision and delays.

Frederic runs a nice blog site, Digital Addictions, with some additional great advice. Check it out at: http://casagrande.blogs.com/english/ - Or, if you prefer it in French, visit: http://casagrande.blogs.com/

With all this good advice from our readers and colleagues, project managers can't go wrong.

Outcomes and Actions...Too simple?

Some of the feedback on my previous post, about a new and simpler definition of the word "project" has been that the definition may be too simple. How could something as complex as a major business project be defined by something as simple as "outcomes" and "actions?" My answer comes in five parts:
(1) Outcomes and actions can be combined in a staggering number of ways, not unlike the way protons, neutrons and electrons are combined to form matter. Consider Agile PM, where outcomes are defined by a backlog of user stories (with story points) and executed in fixed time bins (iterations). Consider how Agile actions are guided by daily stand-up meetings. Consider large government projects where interim outcomes are described in "work packages," are defined and refined into a complex performance measurement baseline (PMB), placed under tight change control, and tracked with various pre-defined earnings rules. Consider how outcomes include widely-agreed concepts of "deliverables" and "creating unique products, services or results." And yes, intended outcomes and next-actions help guide personal decisions as well. It is a very scalable definition of projects -- more scalable, in fact, than the traditional definition of a project.
(2) There is a lot of room for improvement, even in traditional projects, for how we define, control and track intended outcomes and how we translate those outcomes into front-line action. Consider how many projects have failed because day-to-day actions were not connected to clearly-defined intended outcomes. Not so simple, is it?
(3) It takes extra effort to decide if a project activity should be defined by its end state (outcome) or is simply a means of moving us forward (action). If we don't go this extra mile, we may create an amorphous and confusing froth of outcomes and actions that is a source of miscommunication and waste. Outcomes and actions should be distinct, yet linked. And that is far from simple to do.
(4) One of the things I've learned about outcomes and actions is that they are entirely different beasts. Outcomes are the realm of control. God bless order and structure. Outcomes need to be comprehensive and mutually-exclusive, which is not so simple to implement, but very important too. Actions will never be comprehensive and mutually-exclusive. Actions are the realm of knowledge worker freedom of choice (which is why they are knowledge workers). Actions are messy, but God bless the mess.
(5) In upcoming posts, I'll show how this definition helps with respect to the next great frontier in project management, which is Management by Project (MBP). This simple definition, although written by a personal productivity guru, has surprising power with a topic that is beyond the scope of the PMBOK Guide.
Is the outcome/action definition simple? Yes. But it explains and predicts a lot of things from personal management, to project management, to MBP.
/Garry

Project Methodologies: Keep 'Em Flexible

Time and time again, I've seen organizations spend months devising the perfect project management methodology, sometimes even building it into their EPM tools, only to find people complain that it slows them down and doesn't add much value.

In many cases, they're right. The problem is that not all projects require every step, and in many cases there are easier ways to accomplish what certain steps are meant to do. Another mistake many people make is forcing task dependencies into the project template, such that design cannot happen until planning is completed, and construction cannot occur until the design is approved, and so on.

While this may be true of some projects, on many others, work does not occur in a linear fashion. For instance, certain segments of a project can udergo development while other segments are still being planned. On agile IT projects, the feedback from prototypes and iterations will often dictate the design, and rightfully so.

When it comes to methodologies, frameworks, and templates, the most effective organizations use one or more of following approaches:

- A methodology and project schedule template that allows project managers the discretion of which steps to apply to their project.

- Multiple methodologies and templates for various types of work, with streamlined versions for smaller or more flexible efforts.

- A methodology that identifies which items are mandatory for all projects versus those that are at the project manager's discretion.

In project management, as in pretty much any field, one size does not fit all.

Software Requirements Specifications: The Right Way

There's a useful article on Developer.com by Aleksey Shevchekno on the proper way to create effective Software Requirements Specifications.

He discusses the importance of use cases, how to design use case scenarios, the proper structure of a Software Requirements Spec, and even the appropriate language to use. He also suggests making the spec technology-independent and recommends appropriate wording.

Even for those with Agile projects, where the requirements will evolve as prototypes and iterations are developed, it's a valuable exercise to go through. Read on...

Software Requirements Specifications: The Right Way

Agile Tipped?

Have agile methods for software development tipped yet? And, the survey says ...

... "There are two interesting observations about these results. First, although the majority of organizations are applying agile techniques on projects of 10 or fewer people, many are, in fact, trying agile on larger projects. " ...

Via Dr. Dobb's Journal: Agile Survey Results

BT IT Project Model

One way to increase inventory turns is to decrease the lot-size in the supply chain space. For IT, reducing project size can have a similar effect. BT takes this approach to increase project throughput. ...

... "No IT project at BT is allowed to last more than 90 days. Mott says: If you can't deliver it in 90 days, then we're not doing it. So you need to pull teams together for 90 days, then a new team needs to form for the next project. " ...

Via Building: Agile Approach

Project Forecasting and Uncertainty

Yesterday, I posted about the need to focus on time remaining, using a driving analogy. The premise was that, if we were traveling from Philadelphia to New York and we were at the New Jersey Turnpike entrance (and assuming arriving on time is a critical success factor), the best predictor of success would be to determine how much time remains on our trip.

But what if arriving on time were not the most pressing need? And what if we increased the uncertainty factor? Is "time remaining" still something we can and should monitor?

Let's take IT research projects, for example, which tend to carry great uncertainty. Using an agile approach, the team builds prototypes, and the deliverables get ever closer to "the truth" as the project progresses. If we used a fixed set of iterations, and/or fixed-time iterations, we still benefit from focusing on time remaining, possibly even more so. The only difference is, we're operating in increments.

And even if time is not the ultimate concern, any customer will still want to know "How long will it take before I see something of value?", and usually, "How much will it cost me?" These are the basic fundamentals of good customer service. We still need objectives and scope statements, even on agile projects. It's just that we recognize uncertainty more.

And speaking of uncertainty, proper preliminary research and planning can often help reduce it, and contingencies or buffers can help prepare for the unexpected. Piecemeal deliverables (iterations) can also help, as learnings can be applied to the next phase.

Getting Projects Off On the Right Foot: The Pre-Flight Checklist

Something you don't hear much about, but is a critical success factor for projects, is what I call the "pre-flight checklist." As projects are completed, not only is it important to review lessons learned, but it's vital to have a checklist that can be updated as a result. This checklist would be the first thing a project manager would look at upon undertaking a new project.

This is especially true for agile projects, where adjustments are constantly made based on user feedback. Of course, not everything would go on the checklist, but any item that could save time later on a future project is well worth adding. Why reinvent the wheel?

If warranted, there could even be a checklist for various types or categories of projects.

This checklist is different from a pre-project assessment (another underrated tool), where preset questions pertaining to objectives, risk, value, organizational alignment, and more, can be asked.

As the adage goes, projects fail at the beginning, not the end.

Agile Project Management: Mainstream at Last?

There's an excellent writeup on the LeadingAnswers blog site about the rise, fall, and rediscovery of Agile Project Management. I like the "Universal Lifecycle of New Technology" which outlines how ideas take flight, and then, after people inevitably misapply or overuse it, it fails, only to be resurrected successfully later with a slight twist.

I've seen this happen with a variety of non-technology processes and ideas as well, including TQM, Six Sigma, Critical Chain, PMOs, and---dare I say it---Project Management in general, all of which are currently in various stages of this lifecycle.

The article is well worth reading. For fans of Agile Project Management or those curious in the concepts, LeadingAnswers is a valuable site.

By the way, as a proponent of Geoffrey Moore's Crossing the Chasm book on marketing disruptive technology, I was also interested to see that the article has a link to a white paper titled, "Crossing the Agile Chasm."

LeadingAnswers: Leadership and Agile Project Management Blog: The Rise, Fall and Rediscovery of Agile Methods

Is Project Management Relevant?

Over the years, I've had discussions with software developers who question the need for project management. I've heard everything from "The developers are the only ones who really know what's needed anyway!" to "All the project managers do is slow things down and add unnecessary bureaucracy!" to "Why can't the the developers just work with the customer to give them what they need and avoid the middleman?"

The fact is, given the right developer and a fairly isolated project, all of these are valid statements. But many projects are much more complex than that. They involve multiple stakeholders with conflicting needs, offshore resources, multiple vendors, complex interrelationships with other activities and departments, and more. They frequently involve managing all of this against budget and schedule constraints.

Leading, facilitating, and managing all of these elements is where a good project manager can help. An effective project manager removes barriers for a team rather than adding barriers. Any activities that may appear like "nuisance work" to technicians, such as reporting time or percent complete against milestones, are often necessary to meet the project's schedule or budget constraints.

A good project manager will work with developers to determine the appropriate project approach, depending on the constraints and the level of uncertainty involved. Perhaps an agile approach is warranted, with learnings applied incrementally. Perhaps piecemeal deliverables can be achieved for quick wins and earlier value. A good project manager will also prepare management reports, conduct presentations, and deal with vendor issues.

Most of all, a good project manager will communicate to all parties throughout the project. Although some developers do indeed have the expertise to do all this, it distracts from the work they need to do.

This is not just a nuance of the software industry. The same holds true in any industry where technical or subject matter experts question the need for project management. Project management is a completely different skill set, necessarily so. It's geared toward leading people to achieve objectives. An organization can of course put the project manager in a better position to be successful by providing adequate tools, general principles, and minimal bureaucracy.

The article below offers clear and simple evidence of the importance of project management. It begins with the results of a 1999 study that showed that the number one reason companies stopped working with Internet design firms was not about their lack of creativity or high costs---it was about their inability to effectively manage a project.

Here's the article...

MB Journal Article Archives

Traditional vs. Agile Project Management: All You Need to Know

Here's the best article series I've seen to date comparing traditional "plan-driven" PMBOK practices to Agile "value-driven" approaches. It's a four-part series by Michele Sliger on StickyMinds.com.

Enjoy...

Column info : Relating PMBOK Practices to Agile Practices - Part 1 of 4

Agile Project Management: Everything You Need to Know

For those who have heard about the benefits of Agile Project Management, there's an excellent primer at Projects@Work, including the best graphic I've seen to date to illustrate the difference between Agile and Waterfall approaches.

There's practical advice on what Agile is and is not, along with 10 steps outlining how to try it out. Check it out...

http://www.projectsatwork.com/content/Articles/233272.cfm

Software Quality Assurance: Integration Testing ...

Rethink integration testing ... create an exciting process that engages developers and QA participants. Put the software product through an end-to-end process that exercises it from a user perspective. ...

... "On an iterative or Agile project, integration tests happen at the end of each iteration. But in all cases, developers need to convince themselves and others that the software really works before they feel comfortable releasing it. " ...

Software Quality Assurance: Integration Testing: Via Dr. Dobb's: Better, Stronger, Faster Integration Testing ...

Agile Project Leadership ...

Agile network sustains mission with election of new board members. I like the relentless focus on value and all of the core principles. Worth a quick check. It's valuable to anchor back to principles periodically. ...

... "Agile Project Leadership Network (APLN) New Officers and Board Members: The Agile Project Leadership Network (APLN), a partner non-profit organization focused on making people great project leaders by focusing on value, teams, context, customers, individuals and uncertainty also named several new officers to its roster. APLN was founded in 2004 by individuals active in writing about, practicing and evangelizing the movement toward fast, flexible, customer value-driven approaches to leading projects of many types. Although the organization is separate from the Agile Alliance, the group's aim is to work closely with the Agile Alliance to help them become better Project Leaders. " ...

Via Yahoo Finance: Agile Alliance and The Agile Project Leadership Network Announce New Board Members and Officers for 2006-2007 ...

IT Governance Meets Server Virtualization ...

Cassatt and NEC combine to deliver portfolio management for virtualization of servers aimed at the financial services industry. ...

... "Cassatt Corp., an innovator in providing enterprise software and services to enable agile IT infrastructures, and NEC Solutions (America), Inc., a premier provider of integrated solutions for the connected enterprise in North America, announced the immediate availability of a fast track IT Portfolio Management solution for server virtualization and consolidation. Express IT Portfolio Management (e-ITPM) is a joint solution from Cassatt and NEC that provides financial services customers with the ability to realize greater costs savings by combining IT governance initiatives with internal IT projects on virtualization and server consolidation. " ...

IT Governance Meets Server Virtualization: Via Cassatt Corporation: Cassatt and NEC Expand Partnership to Target Financial Services Customers: Joint solution combines NEC Solutions America IT Governance Practices with Cassatt's Server Virtualization Management and Consolidation Solution ...

Has Agile Development Lost its Way?

According to Steve McConnell, chief software engineer at Contrux and a pioneer in the "rapid development" movement, Agile development has fallen short in several areas, straying from its original focus and becoming overly process and tool centric.

I know the original intent behind Agile was to focus on rapid iterations and frequent communication, but I wouldn't be surprised to see it distorted by organizations that miss the point (or that use it as an excuse to forego risk management).

The Scrum approach seems to me to still maintain the right focus, but only the most forward-thinking companies have been bold enough to adopt it (and are reaping the rewards accordingly).

Another point McConnell made was that one size does not fit all. He's right on there. We need to adopt the right approach for the situation at hand.

For more on McConnell's insights, read on...

Agile programming has fallen short, conference attendees told - Computerworld

For Project Management State of the Art, Attend the PMI Research Conference 2006

At PMThink, we're committed to researching the latest methods in project management, portfolio management, and governance.

Whether it's Agile Scrum methods, more focus on conceptual phases, or the latest innovations in organizational leadership, we're always looking for new and better ways to manage projects.

One good way to find out the latest and greatest in the field is to attend the PMI Research Conference 2006, which will be held at the Centre Mont-Royal in Montreal on 16-19 July 2006. Between the speakers and the attendees, it should be quite informative. Registration begins March 1st.

Here's the info...

Research Conference 2006

Agile / Scrum Project Management: A Certain Future? ...

Gartner looks into crystal ball and makes prediction on the evolution of IT projects into, what sounds like, an agile / scrum project management model. ...

... "Demise of the IT project: And in this world, the 18-24 month project will be as dead as the dodo. Imagine a world, Austin invites, where we measure outcomes, not progress, against plans and look for continual process, like the move from the production line to the manufacturing cell. " ...

Agile / Scrum Project Management: A Certain Future?: Via MIS Magazine: Crystal ball-gazing ...

Microsoft on Scrum & Extreme Programming

One way Microsoft's development teams intend to deliver products to market faster is through the use of agile development methodologies, such as extreme programming and Scrum. You may have seen some of our many other blogs on Scrum.

David Treadwell, corporate vice president of the .Net Developer Platform group at Microsoft, said that while Microsoft welcomes the use of methodologies like Scrum, "we're not mandating them, but we're encouraging them..."

"The other is extreme programming—the concept where you might have two people working on a given piece of code and the idea is that two minds are better than one. Because you can find problems faster."

Scrum process can not only be used for developing applications, but also to test them for quality assurance sign-off.

Thanks to e-Week for the news. For more see:
Microsoft Lauds 'Scrum' Method for Software Projects

Why Projects are Late; The Top Six Reasons

Here are the top six reasons why projects are late and what we can do about it...

1) Unrealistic Deadlines - As we've reported here before, this is one of the most frequently overlooked reasons for late projects---and unfortunately, often the last thing people look at.

Solution: It's imperative for a project manager to defend the right plan and not give in to pressure to sacrifice good principles. If necessary, negotiate to time-box the project into multiple phases.

2) Customer/Partner Availability - I've seen numerous project managers over the years talk about the challenges they face keeping a project on schedule when they're waiting on a customer or business partner to do testing or sign off on some deliverable.

Solution: Set milestones, monitor progress, and raise an issue if the lack of availability will cause a delay. If necessary, negotiate a new project baseline---which may be quite appropriate if the customer and/or steering team agrees that a delay is acceptable.

3) Resource Availability - There's nothing worse than putting together a reasonable schedule only to have your key resources pulled off into different directions, but it happens more often than we care to admit.

Solution: Try to obtain full commitment up front for your resources' time. Even so, unexpected conflicts will happen. Same as #2 above, set milestones, monitor progress, and raise an issue if needed. Again, negotiation may be necessary, which can result in getting your resources back or in setting a new project baseline to accommodate the new priorities.

4) Uncertainty - Especially in the IT field, uncertainty is a given. At any time, unexpected circumstances may cause project delays.

Solution: Use rolling wave scheduling, planning the whole project from a high level, but only the nearest 90-day horizon in detail. Try agile approaches as well, aiming for prototypes and frequent iterations. Ideally, pilot the project, and aim for vertical rollouts (one group at a time). Build contingency into your schedule for known risks. Most of all, manage stakeholder expectations.

5) Management Decision - Sometimes, management makes a conscious decision to delay a project, either for strategic needs, changes in priorities, or any number of reasons.

Solution: If the delay is a management or customer decision, a new project baseline should be saved, with current metrics based on that. Note that it's also important to keep the original baseline, as that offers a different set of measures (mostly around organizational alignment).

6) Poor Estimates - Sometimes a project is late simply because tasks were underestimated or omitted from the schedule. Although this is not always the cause of project delays (and rarely the only cause), it tends to be the first one people look at.

Solution: Build experience and capture historical data by project category and activity. If the data isn't categorized it won't be useful. Create and maintain checklists of items to consider. Build project schedule templates. The most frequently overlooked areas in IT are: training, data-loading, cutover preparation, system network testing, adequate QA testing, and documentation.

Characteristics of Scrum Project Management

Scrum is an agile method for project management, first implemented by a team led by Jeff Sutherland at Easel Corporation in 1993.

Characteristics of scrum include:

• A living backlog of prioritised work to be done;
• Completion of a largely fixed set of backlog items in a series of short iterations or sprints;
• A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
• A brief planning session in which the backlog items for the sprint will be defined.
• A brief heartbeat retrospective, at which all team members reflect about the past sprint.

For more info see: http://en.wikipedia.org/wiki/Scrum_(in_management) or our many previous blogs on scrum.

Innovation in Project Management; A Lesson from Ford

Tom Peters blogged recently about Ford, Pixar and the new wave of innovation sweeping companies. Although he had a softer spot for what Pixar is doing, the main point was that innovation is the new world order. Operational excellence is out, as is short-term thinking and reactionary cost-cutting. Even GE is now all about innovation.

Just look at these enlightening statements in a recent announcement from Ford CEO, Bill Ford, announcing their renewed focus on innnovation...

Ford Motor Company stands for a far-sighted commitment to growth. We stand for a renewed focus on the customer. We stand for boundless innovation in every aspect of our business...

Here is what we will not stand for: incremental change, avoiding risk, thinking short-term, blocking innovation, tying our people's hands, defending procedures that don't make sense, and selling what we have instead of what the customer wants. In short, we will not stand for business as usual.

Going forward, our employee evaluations will include a section on innovation. We’re also going to design compensation plans that reward new thinking. And we’re going to create a way for employees to appeal a decision, even if they have an idea and the boss says no.

These are inspiring words. Don't be surprised to see this approach make its way into the project management field. Instead of taking a project charter and "executing well," enlightened project managers will encourage opportunity assessments, get their teams and management excited about new ideas and concepts (assuming they're not squashed), and attempt to try new methods.

We've been posting recently about Agile Scrum Project Management. That's just one example of something that's new and different, but will most likely not gain ground in traditional, conservative organizations.

Here's more from Bill Ford's presentation...

Innovation Acceleration: Innovation-Driven Vision: Ford Motor Company

Agile Scrum Project Management; Applicable to All Projects?

I just finished reading Agile Project Management with Scrum, by Ken Schwaber, and the case is most compelling.

As we've posted here, Scrum is all about daily communication and short 30-day iterations focused on business value. No doubt it's a change from traditional project management, but it takes a sensible, pragmatic approach. As the author points out, Scrum is about "the art of the possible" and especially shines when dealing with complex initiatives (which most IT projects are).

While the book is geared toward software development projects, I found myself asking if this approach would apply to other projects, such as implementing packaged software, or even non-IT projects. I think the answer is a definite "yes." However, the first round may take longer than 30 days, depending on the complexity of the configuration and a hundred other variables.

Suffice it to say that time-boxed iterations focused on delivering some level of pre-defined business value at each iteration is the right way to go for most projects, and certainly most IT projects. Phased deliverables offer earlier payback, quick wins, and allow the flexibility of changing course in future iterations. That sounds like a win-win to me!

Agile Software Vendor Nominated in Project Management Categories ...

... "Rally Software Development Corp., the leading on-demand provider of Agile software life cycle management solutions, announced it has been selected as a finalist for Software Development magazine's 16th Annual Jolt Product Excellence and Productivity Awards. Rally is a finalist for awards in both the Enterprise Project Management and Quality Project Management categories. " ...

Agile Software Vendor Nominated in Project Management Categories: Via Rally Software: Rally software development named finalist in two categories for the 16th annual jolt product excellence and productivity awards

Agile Project Management with Scrum

I have been wondering lately, what does agile really mean here?
This article says, Agile means responding to change - both technological change and changes in requirements perhaps due to customer demand and market opportunities.

It makes sense to me that this would be needed. The world is spinning much faster now and people expect content on the web, for example, to be relevant.

How does this differ from typical PM approaches? It has an answer there too...
-----
More traditional project management "command and control" approaches assume the relationship between the inputs and outputs of a software development process are stable and predictable and that the schedule of outputs will still be relevant by the time they appear. Scrum accepts the fact that things are going to change and takes an empirical approach.

In Scrum work is delivered in monthly "sprints". Each sprint delivers a single, usable piece of work called the "product increment". This product increment is immediately available for evaluation and use by the customer at the end of a sprint. Projects managed in a "command and control" style often have an infrequent release schedule. This can result in a gulf between customer expectations and reality. Scrum requires these predictable, frequent releases to ground customer expectations on demonstrated, working code rather than the false comfort of forecasts and reports. Short of an emergency, stakeholders aren't allowed to approach developers formally or informally with requests to do additional work during a sprint. This gives the development team enough stability to be able to complete a product increment without being distracted by the noise of external disruptions.
-----
Now that last part about not having stakeholders formally talk to developers is something that I try to enforce on my projects also. So, maybe it's not so different after all...to learn more visit:
ITWALES.COM - Agile Project Management with Scrum:

Agile Software Development: New Project Management Paradigm ...

According to article, traditional project management methods must be transformed to enable agile software development and service-oriented architectures. This new paradigm requires an organization that shares knowledge freely and quickly. An organization's readiness to work in the new paradigm of open collaboration is an indicator of success with agile software development methods. ...

... "Contrast that view with ASD, where scope creep is a given, changes happen often, developers respond quickly to those changes and, consequently, knowledge must be on hand at all times. Add in the service-oriented application method, where applications come together via units of work to be performed by a person, computer or team, and suddenly knowledge must not only be available, it needs to be shared freely and viewed as just one more piece to maneuver on the chess board. " ...

Agile Software Development: New Project Management Paradigm: Via Knowledge@W. P. Carey: Ready or Not, New IT Paradigm Requires Knowledge Sharing -- Part 2 ...

Agile Scrum: Game Software Development ...

In this interview, Clinton Keith, CTO High Moon Studios, discusses Scrum, which is being adopted for game development. ...

... "Agile Methodology is an approach to making products that is different from the typical development approach, which involves writing large documents, implementing features and putting it all together at the end of the development cycle. ... Scrum is just one of the four major Agile methods that are out there. " ...

Agile Scrum: Game Software Development: Via GameDAILY Biz: The news source for video game industry professionals

Via Vivendi Universal Games: VIVENDI UNIVERSAL GAMES ACQUIRES HIGH MOON STUDIOS: "Over the past year, High Moon earned numerous accolades for its development accomplishments. In December, High Moon was named among the Top 50 Technology Innovators of 2005 by IT Week for applying Agile Methodology to its development of next-generation games. The studio's adoption of the innovative R&D method also earned it a 2005 Workplace Excellence Award from the San Diego chapter of the Society for Human Resource Management. High Moon's critically acclaimed first-person shooter Darkwatch has been recognized with several art and animation awards, including five Davey Awards, two Aurora Awards and a Telly. "