If you happen to be down in Orlando this week, and are planning to come to my talk on the Agile PMP, hold off reading this post. I am revamping my talk based on some feedback I received last week in Vancouver. I may use some of the images and explanations contained in this post to help explain agile project planning and how it is different. I wanted to write this out to clarify some of my thinking and get a feel if this line of reasoning will work.
You are getting the benefit of my trying to develop a thought ;-) Nothing better than thinking out loud to a few hundred people. I'll let you know how it goes after the talk. If you have any suggestions before tomorrow, I might be able to get them into the talk. If you have a comment, now is the time to post it.
Before I get going I want to explain a few things and give a few disclaimers. I used MS Project to create a series of illustrations that describe how a traditional project schedule might evolve into an agile project schedule. Let's be clear, I am not recommending that you use MS Project to manage agile projects. I don't need anyone freaking out that some agile guy is recommending MS Project for agile projects. That is not the case.
The reason I chose to start with MS Project is because the Gantt chart is the language many project managers understand. When the agile community talks agile to traditional project managers, we need to start where people are with tools they currently understand. It is not impossible to manage an agile project with MS Project, it is just that the underlying paradigm of the Gantt chart does not really work. The tool itself is not designed for collaboration
Traditional Waterfall Project Plan
Many project managers start with this level of understanding of a software development project plan. It makes good sense... you understand what you are going to build... you decide how you are going to build it... you build it... you test it... you see if the customer likes it... and if they do, you deploy it. Simple, huh?
I have managed projects this way and have had some success. To make this kind of project successful you need to have a great deal of certainty around what you are going to build. Change is not the friend of the waterfall project. You also need a great deal of stability in your project team. You can't have people going on and off your project, getting pulled into other work.
This typically means that your project better be pretty high in the organizational priority queue.
Often, our reality is that requirements do change and people are working on other projects. This makes our projects late and unpredictable. What is even more troubling is that we often don't find out they are late and over budget until it is too late to do anything about it. We need drive up predictability, deliver on shorter cycles, and get product to market faster. We need to change how we are thinking about delivery and change our project management approach.
The first evolution of the waterfall project plan is to break the project into smaller phases.
Delivering in Phases
This approach is designed solely to make our projects smaller and get product to market faster. Smaller is almost always better, but the phased plan suffers from many of the same problems as the waterfall plan. To make this approach work, you still need very stable requirements and a very predictable project team. This approach does not fundamentally solve the problem but it does help you realize it faster.
One of the core problems with the phased approach, as with the full blown waterfall approach, is that people are specialized and their specialty is not required 100% during the life of the project. This results in matrixed project teams and matrixed management. When people start working on other projects, and those projects run late, this impacts your ability to get people back when you need them.
To solve the problems with the phased approach, we need to not only deliver in shorter cycles, we need to keep people dedicated to our projects longer.
Overlapping Project Phases
This is where the overlapping phased approach comes in. A smart project manager will try to take some of the wait time out of the projects and overlap many of the activities. This is a good move, it keeps people focused on our projects, they stay busy more often, and are less likely to get pulled into other initiatives.
You can also see from the illustration that this kind of overlapping can have a significant impact on your timeline. You can usually get the work done sooner. This approach is a step in the right direction (from a utilization perspective) but does not solve our problem with brittle project plans that are resistant to change.
Shorten Phases into Iterations
This next step is an evolution of our project planning model but does not solve any more of our fundamental scheduling problems. It does allow us more focus on delivery and learn from the process of delivering working software. The thinking goes, if shorter phases are better, and overlapping phases make work go faster, then let's put this approach on steroids.
This approach is where I came to know iterative and incremental development. Early in my time as a software project manager, I understood iterative and incremental delivery as a series of shorter, overlapping waterfall projects. As a project manager on these projects, one of my main jobs was to manage that overlap and make sure that people understood what we were working on and when they needed to be available.
Even with this level of sophistication in our project planning, even with the resource utilization and timeline gains we have realized, our projects are still going to suffer when requirements change and schedules do not go according to plan. We have solved some of our resource and prioritization issues, but in the process have created a web of interdependencies that only serve to decrease our ability to effectively deal with change. In some ways, our project schedules become even more brittle than they were before.
Make Iterations Cross Functional
Iterative and incremental development is not supposed to be a series of overlapping waterfalls. The purpose of iterations is to have all skillsets on deck working toward a common iteration objective. Each iteration has a goal and a set of functionality that it is supposed to deliver. By having everyone focused on the same set of deliverables, we are able to deal with changes within the iteration itself... no one has moved onto other work... no one has to backtrack.
Dependencies are contained and cascading impacts can be kept to a minimum.
The iterative timeboxes are fixed and do not overlap. The team develops the set of functionality planned for that iteration and reviews the outcome of the iteration as a team. There is opportunity to learn from our progress and take any corrective actions before the next iteration begins. If change is introduced into the project, it gets planned for in the next iteration, and the impact of that change cascades down the project.
Most teams that are adopting agile find themselves at this level of project maturity. They have introduced iterative and incremental development but have not embraced some of the other organizational changes that are necessary to make it work. At this point, we still have not solved the problem of people being pulled away from our projects. We are at risk of being impacted by competing priorities... we are not able to function as a cohesive team.
Also... there is nothing particularly agile about this approach. We might still be doing a big up front design, traditional change management, and predictive project control. We can acknowledge it is a step in the right direction, but it is not agile.
Shorten Iterations Further and Focus on Value
Moving from iterative and incremental, to something that begins to look agile, you need to shorten even further your delivery cycles and create cross functional teams that are allocated to your projects 100%.
By shortening delivery cycles, the project manager can focus less on how product gets delivered and more on what is getting delivered and how fast. The team becomes accountable for meeting delivery objectives, and has more ability to decide what gets done and when. The team can make decision on how to best use their time to meet the goals of the iteration. The project manager gets real empirical data about how the project is progressing in the form of working software.
By keeping people 100% allocated to our projects, project managers need to focus less on activity sequencing, this can be delegated to the team. Giving this responsibility to the team allows them to be more creative solving problems. They stop being accountable for doing tasks, they become accountable for delivering value and meeting objectives. Project managers become more focused on tracking the flow of value, removing obstacles that could get in the way, and communicating and collaborating with the rest of the organization.
At this level of maturity, project managers are often still thinking with a predictive mindset. They are still trying to predict the flow of value and schedule all the iterations in advance, but have moved to a value focused planning model rather than an activity based planning model.
The Agile Project Plan
The agile project schedule is really just the sequence of project releases and iterations. It is the basic cadence of delivery the team has decided to organize around to deliver product. Features are kept in a sequenced backlog and scheduled iteration by iteration based on what we have learned about the evolving product. Project managers measure the flow of feature delivery, iteration by iteration, to communicate to the organization how the team is making progress.
If a change needs to be introduced to the project, it can be added to the backlog just like any other feature. The team collaborates with the business to frequently reprioritize. Because we focus on delivering working software on incredibly short cycles, the business gets to decide exactly when it wants to take product to market.
Shameless plug for VersionOne...
From a purely structural perspective, a tool like MS Project can be used to manage an agile project. When teams try to do this, they are usually at a step just before full blown agile adoption. They are still in a place where they are trying to predict the build order of features rather than managing the flow of value in collaboration with the business.
An agile project management tool like VersionOne Enterprise is focused more on creating a space for teams to collaborate, plan on short cycles, measure and assess their progress. Agile tooling is focused much less on predictive project planning and more on enabling communication between the team and between the team and the business.
In Conclusion
Explaining agile to traditional project managers can often be pretty challenging. You might get the core ideas across, but chances are you are going to get some blank stares and glassy eyed looks. These are smart people, it is not that they don't understand your words... they are struggling to find out how to get from here to there. They don't fully get why the kinds of activities they have always done don't always apply.
I hope this helps you understand how and why fast changing projects are different from traditional projects and why they cannot be managed using traditional approaches. Again, don't think of agile as replacing what you know, but adding to it, adding additional tools to your toolkit to help you deliver reliably in the face of uncertainty.
After writing all this, I am actually reconsidering using it tomorrow. I am not sure I can pull off this many words in light of what else I need to say. And like they say, this is long because I don't have time to make it any shorter. Thanks as always for reading!
Subscribe to this blog
Subscribe to Leading Agile
If you missed my talk on the Agile PMP: Teaching an Old Dog New Tricks, the one I did down in Orlando a few weeks ago, you are going to get a second chance. I am doing a shortened version of the talk for the ASPE webinar series. The talk will be on December 18th at 12:00 PM Eastern time.
