Agile Phases

Earlier this week I described my experience with Agile in pre-history (pre-Internet days). As I’m engaging again in SW development, I’ve been looking into how I would organize an Agile project if I had to come up with a methodology.

Jim Highsmith, in his book “Agile Project Management” (same book I mentioned in my prior post), describes the following phases:

  1. Envision – this is the dreaming phase, where the team defines the product vision and project scope, who would be involved, etc.
  2. Speculate – develop a plan to deliver the vision. Focus on features in each release, milestones, and how to iterate.
  3. Explore – deliver a tested release quickly
  4. Adapt – review the results, the situation, and the team’s performance and make adjustments
  5. Close – conclude the project.

There’s a cycle that repeats: 2-3-4, 2-3-4, 2-3-4, … until done. The emphasis in these cycles is to repeat them often and quickly. In other words, reduce your cycle time.

For those PMPers out there, you probably noticed that these phases sound very much like the process groups in the PMBOK, except with different names. PMI calls them Initiating, Planning, Executing, Monitoring and Controlling, and Closing groups.

So, what’s the real difference? Did Highsmith use different names to communicate something or did he just do it to distinguish his approach? If you remember, PMI clearly indicates that these groups are not project phases and that in large projects these groups would be repeated in each phase or subproject. There are some differences in the details. For example, PMI does the definition of the objectives in the Planning Group, not the Initiating Group. The Monitoring and Controlling Group is more formal than the Adapt phase that Agile calls for. In general, though, there are lots of similarity.

You could, easily, implement an Agile project and use the Process Groups defined by PMI and not Jim Highsmith’s phases. The process groups are generic, as PMI indicates, and can be applied to any product methodology. The key emphasis that Agile makes is the focus on fast and frequent delivery of products of value to the customer. For PMI, that is one of various different approaches.

So, don’t get confused with the Agile terminology. As a PM, you still need to get authorized and figure out what you are going to do; you need to plan your approach, execute it, monitor and adjust, and eventually close the project. In Agile you have to do it fast and frequent!

Note: not every project can use Agile. Agile requires low cycle costs, that is, conducting a cycle is relatively cheap when compared to the outcome of the project. In some projects, such as building a house or a ship, the cycle costs are very high and a more traditional approach would be better, unless you can substitute simulation for the actual product in the early cycles. Also, Agile is better suited for uncertain conditions, where the requirements or approach need to be investigated. Traditional approaches focus on efficiency and cost reduction. If you are building many of the same thing, such as houses in a development, a traditional approach is better suited for your efforts. Keep this in mind. You may need a slow and steady approach in some cases. dump-truck-toy.gif

Share

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top