PM Articles > Alan S. Koch > What Makes a Project "Agile"? Part 7: Iterative Planning

What Makes a Project "Agile"? Part 7: Iterative Planning

The Essence of Agility
What makes a project "Agile"?
Part 7: Iterative Planning

by Alan S. Koch, PMP

Is it Agile? Or is it lack of discipline? How can we know for sure? The Essence of Agility consists of those sets of observable behaviors that distinguish a truly Agile team from a bunch of undisciplined programmers.

In my six prior columns I addressed seven of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, customer focus, small self-directed teams, embracing Lean principles, Progressive Requirements Elaboration, Incremental Delivery. In this last article of the series, I will address the final key characteristic: Iterative Planning.

Can "Plan" and "Agile" Coexist?

With all that we have discussed so far in this series, you may be wondering how it can even be possible to plan an Agile project. In the first installment, Learning and Adaptation, Collaboration, we talked about expecting surprises and making allowances for them when they happen. In the second, Customer Focus, we said that the customer is so important to the success of our project that when they change their minds (or discover their own surprises), we need to go along with them. Next, in Small Self-Directed Teams, we discussed letting the team self-manage. (Can we really expect them to plan?) In Embracing Lean Principles we discussed the value of making decisions as late as we possibly can. (How is that a plan?) In Progressive Requirements Elaboration we described starting the project with only a rough picture of the requirements. (How can you plan?) And last time, in Incremental Delivery, we noted that the customer is likely to change their minds when they see the delivered increments, and we called that a good thing!

Yes, we can plan in the face of all of these things. But the way we go about planning, and the form the plan takes, will necessarily be significantly different from our traditional plans. Like everything else on an Agile project, planning will be iterative and incremental. Let's see how that plays out.

Initial Planning

Every project begins with planning, and Agile projects are no different. There is no point in pressing forward until we set everyone's expectations about what will be going on.

Traditionally, this planning activity is the planning for the project, and it is expected to be complete, and to be the basis for managing the project through its duration. If the project runs into problems, we do everything in our power to bring it back into conformance with the plan. And if all else fails, as a last resort, we re-plan.

Initial planning activity on an Agile project is quite different. It is not intended to be complete. In fact, an Agile plan intentionally leaves many things unexplored and undefined. This plan is broad-brush, predicated on only a rough list of the requirements (with no detail), and based on rough order-of-magnitude (ROM) estimates. The intent of an Agile plan is to establish the boundaries and expectations within which the project stakeholders will collaborate to drive the project to success.

Embracing the plan for an Agile project is an exercise in embracing ambiguity! We don't pretend to be able to predict all that will happen, so it makes no sense to speculate about the details we can only guess about. What we do is to document what is known (or believed to be true) at the time, forecast how the project will play out if those things prove to be true, and commit to work together to bend those expectations to whatever realities we discover throughout the project.

The Agile project's plan is not a way for the customer to hold our feet to the fire, nor is it a way for management to hold the team's collective feet to the fire. It is a basis for all of these players to collaborate to drive the project to a successful conclusion.

Iteration Planning

Of course, a broad-brush plan that is full of ambiguity naturally lacks the information needed to manage the day-to-day work. For that reason, planning is not considered complete when an Agile project's initial plan is complete. The planning continues in step with the iterative nature of the work.

Agile projects follow an iterative lifecycle, and we call each time through the loop one "iteration." Each iteration of work begins with planning the details of what will go on. This task-level plan is very much like the plans that we put together on traditional projects. The big difference is that this plan is for only a very short period of time. (Each Agile iteration represents only a few weeks of work.)

Of course, it is easy to produce a detailed plan for such a short time period. But we don't do it because it is easy. We do it because we need a detailed plan to help us to successfully finish each iteration and produce a sliver of working software. This task-level plan is what the team refers to in their daily stand-up meetings, and it is their basis for tracking their status.

Re-planning

The final piece of Agile planning relates directly to our expectation of change. In spite of the ambiguity and lack of detail in an Agile team's top-level plan, it will still be affected by changes and surprises on the project. For that reason, re-planning is an integral part of every Agile project.

Unlike traditional methods (where re-planning is considered to be a bad thing, and is avoided at all costs), the Agile approach includes re-planning as a normal and natural part of the process. At the end of each iteration of development, the team does not assume that the plan they embraced before is still valid. They explicitly investigate what has changed in the meantime, and discuss how those changes may affect their top-level plan.

We hope that the project's broad-brush plan is not changing continuously. But if we find that it is, then all of the stakeholders engage in a regular reassessment of the plan to keep it in sync with reality. This is the whole reason why the Agile approach is the best way to manage projects with many unknowns. The more unpredictable the project will be, the more important it is for us to admit that we don't know everything up front, and to actively collaborate to deal with the surprises that arise.

Becoming More Agile

With this last piece of the Essence of Agility (Iterative Planning), we have investigated all of the key behaviors that Agile teams display. If your "Agile" teams display all of them, congratulations! Support them and trust them to deliver the greatest possible customer value that they can within their constraints.

If, on the other hand, some discipline is lacking, you have some ideas about how their Agile processes are breaking down. In this case, you can support them by helping them to learn what they lack so they can become a well-honed, productive Agile team.



Related Links
Our Technique Brief covers some of the major approaches to agile planning. Kent McDonald previously answered the question of what an agile project plan actually looks like. If you're thinking of trying out Agile methodologies, use our checklist for trying a first Agile project.



Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.