The UP defines four phases, each of which address a different kind of risk:
- Inception. This phase focuses on addressing business risk by having you drive to scope concurrence amongst your stakeholders. Most projects have a wide range of stakeholdres, and if they don't agree to the scope of the project and recognize that others have conflicting or higher priority needs you project risks getting mired in political infighting. In the Eclipse Way this is called the "Warm Up" iteration and in other agile processes "Iteration 0". Disciplined Agile Delivery (DAD) also uses the term Inception phase.
- Elaboration. The goal of this phase is to address technical risk by proving the architecture through code. You do this by building and end-to-end skeleton of your system which implements the highest-risk requirements. Some people will say that this approach isn't agile, that your stakeholders should by the only ones to prioritize requirements. Yes, I agree with that, but I also recognize that there are a wide range of stakeholders, including operations people and enterprise architects who are interested in the technical viability of your approach. I've also noticed that the high-risk requirements are often the high-business-value ones anyway, so you usually need to do very little reorganization of your requirements stack. DAD has kept the Elaboration phase concept of proving the architecture, but instead of including an explicit phase for doing so it adopts the streamlined approach of doing so in the first iteration(s) of Construction.
- Construction. This phase focuses on implementation risk, addressing it through the creation of working software each iteration. This phase is where you put the flesh onto the skeleton. DAD includes an explict Construction phase, and Scrum focuses on this.
- Transition. The goal of this phase is to address deployment risk. There is usually a lot more to deploying software than simply copying a few files onto a server, as I indicated above. Deployment is often a complex and difficult task, one which you often need good guidance to succeed at. DAD includes an explicit Transition phase.
Each phase ends with a milestone review, which could be as simple as a short meeting, where you meet with prime stakeholders who will make a "go/no-go" decision regarding your project. They should consider whether the project still makes sense, perhaps the situation has changed, and that you're addressing the project risks appropriately. This is important for "agile in the small" but also for "agile in the large" because at scale your risks are often much greater. Your prime stakeholders should also verify that you have in fact met the criteria for exiting the phase. For example, if you don't have an end-to-end working skeleton of your system then you're not ready to enter the Construction phase. Holding these sorts of milestone reviews improves your IT governance efforts by giving senior management valuable visibility at the level that they actually need: when you have dozens or hundreds of projects underway, you can't attend all of the daily stand up meetings of each team, nor do you even want to read summary status reports.
These milestone reviews enable you to lower project risk. Last Autumn I ran a survey via Dr. Dobb's Journal (www.ddj.com) which explore how people actually define success for IT projects and how successful we really were. We found that when people define success in their own terms that Agile has a 71% success rate compared with 63% for traditional approaches. Although it's nice to that Agile appears to be lower risk than traditional approaches, a 71% success rate still implies a 29% failure rate. The point is that it behooves us to actively monitor development projects to determine if they're on track, and if not either help them to get back on track or cancel them as soon as we possibly can. Hence the importance of occasional milestone reviews where you make go/no-go decisions. If you're interested in the details behind the project, they can be found at http://www.ambysoft.com/surveys/success2007.html . More recent data can be found at ambysoft.com/surveys/ in general.
Done right, phases are critical to your project success, particularly at scale. Yes, the traditional community seems to have gone overboard with phase-based approaches, but that doesn't mean that we need to make the same mistakes. Let's keep the benefit without the cost of needless bureaucracy.
Comments (6)
I think you are right, and the agile people are also right. Reviews are good, risk management is good and phases are part of every developer's life. The matter of where best to place the milestone markers on the time scale is all a matter of project dynamics.<div> </div> Don't be fooled by the percentage of successful agile projects that only *seems* to be higher than the number of traditional projects. Studies have proven that there is a significant correlation between project size and project failure. It just happens to be that agile methods are more often applied to the smaller projects. That doesn't mean they are the reason for the small projects to be more successful. Causality may not have been proven.<div> </div> Small projects were more successful than large projects long before agile methods came into the picture. It's just that agile practitioners are more vocal in their (correct) claim that big projects should be cut into smaller pieces.
There are many reasons why agile projects have a higher success rate than traditional projects:- We have smaller teams- We focus on high value activities (allowing smaller teams)- We have a greater focus on quality techniques- We reduce the feedback cycle as much as possible- We work closely with stakeholders- We work as collaboratively as possible<div> </div> These are all great ideas, and there's nothing stopping traditional teams from adopting them, and they all seem to reduce project risk. Working smarter seems to be paying off for the agile community.
True, I too believe that each of these best practices contributes to better projects. I just think that comparisons in polls and surveys between "agile" and "traditional" approaches (at least the ones I have seen up to now) are meaningless, for two reasons:<div> </div> 1. Comparisons should only be made for projects of equal size. Because, by their very nature (complexity), big projects have a higher chance of failure than small projects, whatever best practices you throw at them. Sure, I believe that agile practices increase the chance of a project success, even for large projects. But that is not what these simple surveys are measuring. They just compare *all* traditional projects versus *all* agile projects. This is unfair, because research has shown that agile practices are still more often applied to small projects. Traditional approaches are more often used in lart projects. So the outcome of the survey is already skewed. It simply doesn't prove anything.<div> </div> 2. When is a project agile and when is it traditional? If I were to apply only half of the best practices you mentioned, in which category would my project fit then? I wouldn't know. So I find these polls and survey meaningless.
Jurgen, there's definitely limits to surveys and polls. But, they do provide some value as they can provide insight into what's going on out there in the wider world. To fully address the issues that you're interested in would require significant effort by researchers. I don't know of anything that's currently under way right now, although would hope that these sorts of issues are being looked into. <div> </div> One of the reasons why I share all of the data from the surveys that I do run is to help give researchers a step up on their own work. They can analyze the data for themselves to hopefully identify trends which could be explored deeper through other means.<div> </div> - Scott
thanks
thanks