Agile Chronicles

The Evolution of a Project Schedule

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 Iteration

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!

Heading to Orlando for Agile Development Practices

Later today I am heading down to Orlando for the SQE Agile Development Practices Conference and the APLN Leadership Summit. Both should be fantastic events and I am looking forward to spending time with some of the industry's most influential thought leaders.

This is also a meaningful week for me, because after this trip, I have nothing else on the calendar for the remainder of the year. It has been a difficult past three months and I am glad that the ride is over. Some travel is just part of what I do, but these past few months have been really challenging for me personally. Normal work travel is beginning to look like pretty lightweight ;-)

So... in the absence of anything interesting or new this week, I wanted to point you guys to the abstract for my talk. I am following my passion with this one... helping non-agile types understand and make the switch to agility. If you are going to be in town, please come see me at my talk (I am on Wednesday afternoon). If you happen to miss my talk, make sure to stop by the VersionOne booth or even the Agile/PMI SIG discussion area. Hopefully by the time you find me at the VersionOne booth, I will know where the Agile/PMI SIG discussion area is located. I am looking forward to meeting you.

The Agile PMP: Teaching an Old Dog New Tricks

Agile methods put a great deal of emphasis on trust, empowerment, and collaboration. Agile moves us away from command and control project management towards an approach designed to harness the passion, creativity, and enthusiasm of the team. A successful transition to agile project management hinges largely on how well traditional project managers are able to adopt new ways of thinking about project structure and control. Building on the principles of PMI® and the Project Management Body of Knowledge (PMBOK), Mike will explore how a PMP can adapt their knowledge and experience to become an effective agile project leader. Mike will tackle the hidden assumptions behind the PMBOK and explore a more agile approach to managing time, cost, and scope. He will take an in-depth look at the PMI Processes and Knowledge areas and explore how to adapt them on agile projects. Project managers, business analysts, and other stakeholders will leave with new way of thinking about project management best practices and new tools for delivering value in the face of uncertainty.

Quick Bio:

Mike Cottmeyer is a product consultant and agile evangelist for VersionOne. Prior to joining VersionOne, Mike was a senior project manager for CheckFree Corporation where he managed a portfolio of projects for their online banking and bill payment business unit. Mike has a background in traditional project management but has worked primarily with agile methodologies for the past four years. Mike is a certified PMP Project Manager and a Certified ScrumMaster. Mike co-created the DSDM Agile Project Leader certification. He holds this certification at the Foundation, Practitioner, and Examiner levels and was recently named an honorary member of the DSDM consortium. Mike is currently on the board of APLN as Treasurer.

A clarifying thought on agile adoption patterns...

When it comes to agile adoption, I have been thinking about this as a binary equation. Do you start with agile project structure or agile culture. I tend to be in the camp of people that think putting in agile structure can help foster agile thinking and behaviors.

My main point has always been that you create an environment where teams are delivering software on short cycles, throw in some good leadership and a solid vision for the future, and the agile behaviors will follow. My problem, is that as a project manager, I tend to think about things at the project level.

The past few weeks I have been out talking with a bunch of traditional project managers who are working in organizations trying to make the switch to agile. After spending time with these folks, I have had a clarifying thought (not a new thought) because on many levels I have understood this the entire time.

It is not so much project structure that is important, it is organizational alignment that really matters.

There are simple things at play like silos of functional teams, too much specialization, and matrixing people across several projects. We are also dealing with HR policy, career paths, and how we incent and reward our employees. When we say that agile cannot survive without executive level sponsorship… we are not asking for permission and a pep rally, we are asking them to lead change.

We need our executives to drive the hard change that will actually align our business with our software development and project management processes. Our leaders need to remove the organizational impediments that cause agile adoption to fail. Unless we are willing to make those kinds of changes, what can we really expect our project teams to do?

So... I still fall into the structure before culture camp. We just need to think about agile structure at a much higher level, a level where we have the ability to effect significant organizational change.