Classic software engineering tells us that iterations and incremental delivery are all about risk management. With each iteration of working code, risk is reduced for the whole release. This is a key theme in Barry Boehm and Richard Turner's Balancing Agility and Discipline. It's oft repeated by the establishment and by the SEI. So when you are selecting a feature mix for an iteration, you should be selecting the riskiest things first. That would be good risk management and good use of iterations. A fail early strategy!

I'd like to suggest that there are other reasons why we do iterative development. Reasons which are aligned with the Declaration of Interdependence and with Lean and agile concepts of value flow. We iterate to keep batch sizes small. Small batch transfers to system or user acceptance test, keep flow smooth through test and keep WIP inventory in test departments manageable. Small batch sizes facilitate short lead times. Short lead times mean knowledge is created quickly with minimum atrophy from concept to realization. This in turn implies that quality is higher. All of this applies regardless of how risky the individual features in an iteration mix may have been.

Naturally, it's academically easy to argue that all of that smooth flow is simply a risk management technique. Reducing everything to risk management is academically convenient as an abstraction. However, I feel it is a model which has outlived it's usefulness. I'm not saying that risk management as a practice is outmoded. It's not! Risk management - the practice of anticipating special cause events and mitigating them or forming contingency plans to recover from them if they occur is still good practice. However, we can widen our view of why iterations are useful. Iterations facilitate the smooth flow of value and consequently an improved quality assurance.

My colleague Randy Miller finally got the second draft of his new agile process out the door. We've created a new space at MSDN to house it and the debate around it. Go check it out.  I'd encourage you to download it. Take a look. Please provide all the feedback you have the energy to supply. We'll have another rev of this before the product ships later this year. So here is your chance to have an influence on Microsoft's agile offering.

Today, I presented the newly named MSF for Agile Software Development at Web Services Edge. At this conference, Visual Studio Team System was being shown everywhere. Before my presentation, there was a two-hour .Net mini-tutorial where the latest modeling capabilities were shown in a live demo. We also had machines set up in the exhibit hall so that conference goers could try it out for themselves.

Our new modeling diagrams, the logical datacenter, system, application, and class diagrams, really make building web services much easier. Not only are the code and the models synchronized, the logical datacenter diagram validates new web services against the deployment environment. The folks in the Whitehorse group, I mean, Visual Studio Team Architect group have really done a nice job.

This new entry replaces an earlier one Sometimes I just get it wrong. Here is an attempt to get it right second time around. This is a supplement to the content of Chapter 4 - Dealing with Uncertainty. The diagram reflects the 4-types of variation identified by De Meyer et al in their article from Winter 2002 edition of MIT Sloan Management Review, Managing Project Uncertainty from Variation to Chaos [PDF].

We can use this model to better understand a system for software engineering in a given market.  Variation is where assigned cause has been eliminated and only chance cause exists within a known and understood system. Foreseen Uncertainty is where there are identifiable risks and understood issues which affect the delivery of the project but the basic market for the deliverable is understood and the business model or go-to-market strategy is understood. However, there is sufficient uncertainty that assignable cause variation will be observed and must be dealt with through aggressive issue log management.  Unforeseen Uncertainty will feel out of control most of the time and what gets delivered won't be exactly what the customer wanted or when they wanted it. This could be because the software development is happening with a new paradigm of tools or method - when teams start using MDA or DSLs for example - but it may also occur in new markets where the business model is not understood and the degree of variation cannot be predicted. The answer is to iterate frequently and plan adaptively. It is primarily this class of project which Doug DeCarlo addresses with his Extreme Project Management method. Finally, there is Chaos, the land where we don't know what we don't know and we are trying to find out - neither the market, the business model, the customer base, the product features, or the technology are understood. It's the land of research projects.

From a project management perspective, knowing where our project lies in this continuum is important for setting expectations. With Variation we can simply create a common cause buffer based on existing process control limits. With Foreseen Uncertainty, we create a risk management plan which may contain some mitigation approaches which amount to further buffer. In some industries this is called insurance. Insurance works just like common cause buffering but the aggregation is at a higher level. Say for example, a risk mitigation was to bring on more staff to a project, then those staff must be coming from a pool of people elsewhere in the organization. In other words, the wider organization is underwriting the insurance for the project. Unforeseen Uncertainty is a land of high risk - we don't know what we know, or our system is not understood. Playing in this categorycould also be called gambling. As every gambler will tell you - you win some and you lose some. Many VC's will tell you that they lose up to 19 for every one they win. The Unforeseen Uncertainty category is the land of venture capital. Finally, Chaos is a land where only the research budget should venture. It's extreme gambling. It's adventure rather than merely venture. It's a world where you assume you lost your money and nothing got delivered. Delivery is a bonus. It's like winning the lottery. The project management objectives for Unforeseen Uncertainty are simple - try to move the project into the Foreseen Uncertainty quadrant before the money runs out - then ask for more. With Chaos it is similar - try to move the project into either the Unforeseen Uncertainty or Foreseen Uncertainty quadrants before the money runs out. It is unreasonable to buffer a plan in the lower half of the diagram - a not understood market. It simply costs too much. Better not to buffer, but to get as far as you can with what you've got and demonstrate that you've moved to a world of greater certainty before asking for more resources. Iterative projects with adaptive planning is the name of the game.

It's easy to see from this chart that the more uncertain, the greater agility is needed to react to change. In the lower half, the iteration cycle must be short, the feedback loop very tight. By understanding where our project lies in this uncertainty continuum we can make decisions about what represents the best iteration cycle and make informed guesses about how much we want to invest in requirements and analysis versus code, test and refactor.

And finally, I conclude my explanation of the Declaration of Interdependence with the sixth statement about situationally specific strategies and tactics.

#6 - Situationally Specific

• We improve effectiveness and reliability through situationally specific strategies, processes and practices

For me this was the hardest of the six statements to accept. I had wanted something stronger - a recognition that the most effective solution couples the engineering discipline with the project management discipline and allows them to feed off each other intelligently. I've learned this from FDD. The project management aspects of FDD are different because the Coad Method of software engineering enables a different way to think about project management. Project management in FDD isn't some generic task-centric formula. It's based on the architecture and analysis method. The reporting isn't standard earned value rather it's based on the production of features. I believe that when project management and engineering disciplines are combined a more effective process is delivered. I didn't get that. So I settled for this message about situationally specific opportunities which gets us most of the way there.

So for me, the DOI is embracing the idea that it is OK to argue for different approaches and to go ahead and customize project management techniques and to couple them to knowledge of how the engineering technique works. It's OK if you can show that it is leading to a more economically effective solution.

And yet more explanation of the Declaration of Interdependence with the fifth statement focused on teams.

#5 - Team

• We boost performance through group accountability for results and shared responsibility for team effectiveness

Taylorism in the 20th Century was all about the cost accounting notion that you optimized the whole by focusing on efficiency at the individual level. With the DOI we are calling this out to be wrong. We're taking a Peter Drucker / Michael Porter style view that business is done in a value chain. The optimal performance is where everyone in the value chain partners together and has a vested interest in the success of the whole chain. It is this notion which led us to the statement "shared responsibility for team effectiveness".

"Group accountability" captures the notion of "personal safety". Personal safety is the flip-side of courage. Why should you need to be courageous? Because you do not live in an environment of personal safety! Hence, group accountability says, "we are all in this together. Together we succeed or together we accept responsibility for our failure." By creating an environment of personal safety, we believe that individuals are motivated to do the right thing for the optimal performance of the whole system and not take a local decision to protect themselves which is sub-optimal to the global performance.

And more explanation of the Declaration of Interdependence with the fourth statement focused on innovation.

#4 - Innovation

• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference

We wanted to capture something in the DOI which expressed the notion that we view individuals as assets in a business rather than faceless resources which are somehow magically interchangneable and fungible in a 3-sided iron traingle tradeoff. People are the ultimate source of value is a recognition that modern work is knowledge work. Knowledge is value. People create that knowledge. The creation of new knowledge is an act of creativity which generated innovation. This happens better when you create an environment where people are viewed as assets and encouraged to take risks and make a difference. This isn't really a project management practice rather a good modern management practice

More explanation of the Declaration of Interdependence with the third statement focused on uncertainty.

#3 - Uncertainty

• We manage uncertainty through iterations, anticipation and adaptation

The key term here is uncertainty and its scope. We had to settle on one word to capture the essence of variation, change, unknowns and chaos. We settled on uncertainty as the one single word which best captured the essence of the problem. Uncertainty in this context means from variation to chaos, as defined by De Meyer et al, Managing Project Uncertainty: from Variation to Chaos, and shown in this diagram

By embracing uncertainty into the new paradigm, we're clearly making a split from traditional project management theory. There is no concept of uncertainty in critical path. In the PMBOK uncertainty is handled through the notion of risk. Variation in the latest 2004 addition is handled through positive and negative risk. Positive risk? I hear you say. What the heck? Indeed!

The DOI embraces uncertainty. It's a reality of the universe we live in. It's fundamental. No model of project management can deny it or go without it.

We deal with uncertainty by iterating often, providing control and feedback points to make corrections based on the effects of uncertainty. We also anticipate uncertainty. It is the inclusion of "anticipate" in this statement which allows it to encompass Critical Chain. And finally, we learn from our feedback and adapt. This can mean adjusting future anticipation or simply reacting to current events with adaptive planning. In the new paradigm, uncertainty is a facet of planning and scheduling. Planning can be anticpatory or reactive or both. It's not a risk management problem.

Continuing my explanation of the Declaration of Interdependence with the second statement focused on customers.

#2 - Customers

• We deliver reliable results by engaging customers in frequent interactions and shared ownership

We wanted to capture the idea of close partnership with customers. The term partnership tends to get misused. In the same way that executives want you to "delight customers", they often also want you to "partner" with them without fully understanding what that means. Partner means to align the supply chain's interests and focus on the end consumer. This is how Japanese keiretsu work. It creates a mechanism to treat the whole value chain as a single system and optimize for the system not the parts.

We also wanted to capture the quality assurance that comes from frequent customer touch and feedback.

Together these two aspects of putting the customer's skin in the game through (inter-)active partnership and high touch gives us a mechanism to deliver reliable results. The word reliable embraces concepts like repeatable, dependable and trustworthy without the historical baggage that the word repeatable carries in process circles.

I'd like to dedicate a series of blog entries to explaining my personal take on the Declaration of Interdependence. These posts will represent my own views and not any official view from my co-signatories or the emerging organization behind the declaration.

#1 - Flow

The first statement in the declaration says...

• We increase return on investment by making continuous flow of value our focus

What this means for me is that we first need to treat projects as a flow problem. This is concomitant with Peter Drucker's idea of a value chain. In a (software) project, the value chain creates consumer value by transforming ideas into working knowledge through a series of transformative steps. This idea was fundamental to the thesis of my book and at the time (2003) I spent rather a lot of words laboring the point in the early chapters. It seems like a much more accepted principle nowadays but back then I felt I had to do a lot of justifying to get this principle build into the management paradigm.

So, that takes care of the latter half of the sentence but what about the first half?

Well, the argument goes that until you embrace the idea of flow through a value chain then you cannot understand where to focus management attention and investment dollars in order to maximize the investors' return for those dollars. Hence, adopting a flow paradigm is fundamental to devising optimal investment strategies.

A flow model also reveals the primary role for the agile project manager - issue log management and resolution. By focusing on what is obstructing flow - issues arising - the project manager keeps things moving. The Scrum community will identify with this as the primary role of the Scrummaster. Ken Schwaber teaches quite clearly that he sees the management of the issue log, surfacing issues at daily scrums and running them down before they impact "burn down" as the primary mechanism for realizing results.

Astute readers who are fans of TOC will realize that this first bullet also encompasses and embraces the underlying principles of TOC and the Five Focusing Steps. Once you have a flow model, you can go look for bottlenecks in the flow. More DOI and TOC when I get to the third statement about uncertainty.

Has existing project management guidance been annoying you with its failure to help when faced with uncertainty and change? Have you been doing your best but it just isn't working? Are you looking for something new to help make you successful? Then maybe its time for you to subordinate your PMBOK guide and embrace uncertainty! Melt down that iron triangle and learn to facilitate the flow of value! The Declaration of Interdependence is here! It's new! It's modern! It's progressive! It's a movement! Show your allegiance - sign the declaration! Let's lead the future of project management together.

• We increase return on investment by making continuous flow of value our focus
• We deliver reliable results by engaging customers in frequent interactions and shared ownership
• We expect uncertainty and manage for it  through iterations, anticipation and adaptation
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference
• We boost performance through group accountability for results and shared responsibility for team effectiveness
• We improve effectiveness and reliability through situationally specific strategies, processes and practices

©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.

[This is the fruits of almost a year of discussion which led to a 2 day meeting last week in Redmond, Washington. Getting 15 thought leaders in management and agility to agree was actually easier than you might think. We all agreed on the paradigm. The hard work was the wording. By the good fortune of alphabetical order, it seems I get to be the first named signatory. Hmmm. That's nice.]

This past 3 days, I've been hosting a group of authors and luminaries from the agile project management community. You'll be hearing a lot more about this meeting all across the Internet over the next few days and weeks. I'll be saying more about what we discussed and the outcome of the meeting next week (or later this week in my Yahoo! group). However, I thought I'd pause tonight, to mention not what we discussed but how we discussed it - test first meeting facilitation.

The idea really came (inadvertently) from Todd Little, a board member of the Agile Alliance, who kept asking "how will we know when we're finished discussing this (important) topic?" The answer was to devise a test for completeness of the topic. So as we started each agenda item, we identified the test (or checklist) against which the output must be measured. Perhaps an hour or two later, we'd be at a point of consensus, then we'd say, "now let's check this against our test to see if we're done." If it passed the test and everyone in the room had a thumb up, then it was minuted as agreed. If it failed the test, we kept discussing the outstanding points until we had a consensus agreement which passed the test.

The test represented the set of minimum criteria with which each participant in the session could live, i.e. if it didn't pass their test then they would veto the whole thing. Asking people to define the veto hurdle focused each person on what was most important to them. This made the accumulated test sufficient without being bloated. When the test was passed, a consensus was reached (by default) because each participant had passed their veto threshold.

A simple but powerful mechanism and one that I'll be using again.