Many software development teams seem to treat “Agile” and “Project Planning” as if they were mutually exclusive concepts. The tendency, it seems, is to simply jump straight into Agile iterations – at best starting with an Iteration Zero – and then trust that things will sort themselves out strictly through a team-based Scrum-like approach.
In practice, though, teams seem to regularly run into trouble with this sort of naïve approach to starting up an Agile project – especially any sort of large, ambitious project operating within the context of a major enterprise.
Rather than proceeding blindly ahead with nothing more than faith in Agile iterations as a panacea, here are some of the planning considerations that I think projects should explicitly address at their outset, before their first sprint.
Make sure you have a well-defined vision to start with. What are you trying to accomplish? What are the key benefits to be delivered to stakeholders? Are there certain critical dates you must hit, in order to achieve benefits realization? Your vision should be succinct enough to be read in five minutes or so, but should be concrete enough to provide real guidance to the project team about what moves you towards the vision vs. what moves you away from it, or simply leaves you treading water.
Once you have a draft vision, interview key stakeholders individually and ask them what the project visions means to them. Make sure you receive consistent answers. If you don’t, then you need to get the group back together to iron out inconsistencies and sharpen your vision.
As you are defining your vision, consider its implications. There will likely be elements that will need to be considered as you work your way through the items below.
Are there key constraints that must be applied to your project, related to budget, resources, or schedule? Are there specific design constraints that must be respected? Make sure you understand these thoroughly and plan accordingly.
What is the Minimum Viable Product (MVP) that can usefully be released to your customers? How can additional functionality be added in an incremental fashion? What are the dependencies between various features, or groups of features? These are the sorts of considerations that will help you define your implementation strategy.
Your roadmap should show your planned releases, along with other key project milestones, laid out across an approximate timeline. The number of releases and the timeframe depicted should reflect known stakeholder agreements and negotiated expectations. The timeframe should not be arbitrarily shortened, if doing so would allow the team to lose sight of critical milestones farther in the future.
Agile depends on having a backlog that can be prioritized by your customer. However some projects – such as those trying to build a replacement for an existing system – may deliver none of their value until the entire project is completed, and so are not amenable to prioritization. If your customer sincerely believes that all requests are must-haves, then you will not be able to successfully leverage all the benefits of Agile. Perhaps the most critical items need to come first, or perhaps the most difficult items need to be addressed early on. But try to get agreement on some criteria for prioritizing your backlog.
Are there certain areas of the project where requirements are likely to be hard to define? Perhaps areas where different stakeholders have conflicting requirements? Or areas where important stakeholders will be difficult to meet with regularly?
Agile often stipulates that you will have a single Product Owner who is all-knowing and all-powerful, but in reality your situation may not be so simple and straightforward.
If you can anticipate areas where requirements definition will be challenging, then you should plan time and resources to work these issues before attempting to throw them into a coding iteration in the hope that things will work themselves out there.
Are there any areas of your system that will need concentrated design attention? These may be areas of UI design, or areas of database design, or areas of application architecture, or application integration, or some combination of these and perhaps other areas. They may need special attention because certain requirements do not have straightforward solutions, or because certain design elements represent opportunities for achieving fresh and innovative solutions that will deliver significant additional value to your customers.
In any of these cases, you should plan additional time and resources to work these design problems before throwing related user stories into a development iteration.
James and Suzanne Robertson have pointed out that a project can be classified as a rabbit, a horse, or an elephant, depending on the degree of formality needed for its requirements documentation. This need is often dictated by factors outside of the control of the project team, and simply waving your magic wand and saying “We’re Agile!” will not automatically mean that the only thing you will be writing are user stories.
Similarly, in any large enterprise, there will likely be some significant expectations for architecture documentation, and again, these documentation requirements will not easily be wished away.
Make sure you plan sufficient time and resources to produce all relevant and required documentation.
Be explicit and transparent about the technologies you intend to use, including application components and development tools. Be wary of any technical paths that may be candidates for severe disruption over the course of your project or over the intended life of your product. Lay out enough of your intended application architecture to show how these technologies will be used within the context of your solution. Ensure all key stakeholders, including those in Enterprise Architecture roles, endorse your decisions, and make sure someone records these decisions and approvals in some sort of permanent record.
Then assess the readiness of the technology for use by your development team. Is the stack already proven? Is the team already familiar with it? If you answer either of these questions in the negative, then be sure to factor additional time into your plan to allow for technical experimentation and/or training.
Your development team will spend most of its time developing new features. But over the long haul it will realistically also need to spend some of its time on defect correction, as well as refactoring, design improvements, and technology upgrades.
The best way to address the need to include these unlike things in your development work is by use of capacity allocation. You can renegotiate the percentages allocated to different types of work over time, but it’s best to introduce the concept early, establish some starting agreements, and then bake these into your planning assumptions so that you don’t over-estimate your development capacity.
Will you have one or more teams working semi-independently on different pieces of your system? If so, be sure to factor in time and resources for integration testing and hardening of the integrated solution. This may come in the form of a periodic hardening sprint, or additional integration work as part of each development sprint. However you incorporate it into your plan, though, such work will consume additional time that would otherwise be available for development of new features.
Agile generally recommends you focus on backlog prioritization and short-term commitments to get the most bang for your buck, without worrying too much about longer-term estimates and funding. However, if your project really has to accomplish certain long-term objectives in order to be successful, then you will need to do some level of estimating for the overall project, and will need to make sure you can secure funding to complete the entire job.
Of course, at this point, you will be doing rough-order-of-magnitude estimates, so you will want to make sure you have some reasonable amount of management reserve – in terms of both budget and schedule – available to cover risks that cannot be completely known to the project at this early stage of the game. You should also make sure you have a way of defending that reserve so that it is not squandered on non-essential items.
How will the project know if it’s on track to meet the key milestones identified on the roadmap? The team will need some sort of earned value measurement system to be able to assess its progress towards its larger goals.
If stakeholder expectations are unrealistic, then now is the time to confront that reality, rather than launching into Agile development hoping that things will work themselves out later. If time, money and patience are likely to run out before you reach key objectives, then better to adjust expectations now – or cancel the project outright – rather than launch out on an Agile death march.
So there you have it – a baker’s dozen of factors to be considered when doing initial planning for your agile project, before launching into your first iteration.
Of course, it may be more fun to start developing code right away, but a little bit of time spent planning your effort up-front can avoid major headaches later, and can pave the way for a series of iterations that will lead you smoothly to your ultimate goal.
June 11, 2015