Five years ago, it was not difficult to find companies willing to experiment with Agile on their low-priority, low-visibility initiatives. In my experience, most customers were happy with the transparency and predictability they gained, but where left wondering whether the planning and estimation practices could hold up under the fire of fixed-time, fixed-cost, and fixed-scope initiatives. In other words, was the methodology really ready for real-world complexity and delivery pressures?
Traditional agile proponents will state that it is unfair and unrealistic to expect a development team to accurately estimate delivery on projects spanning a year or more. While I sympathize with their sentiment, it does not change the fact that business stakeholders are increasingly pushed by market commitments, competitive markets, internal demands, annual budget processes, rigid staffing plans and other real-world forces to ask for such commitments. I see this tension most often at product companies or large organizations with significant inter-dependencies across teams. For example, a product company does not build market value with shareholders and customer interest by saying, our next release of the product will deliver whatever scope we have time and money to build. Successful product companies, in fact, provide a high-level road-map of features scoped into each upcoming release. Because of this reality, the business is required to define a large set of requirements, and is afforded little wiggle room to later de-prioritize or eliminate features without potentially significant business impact.
I’ve provided a handful of tips (plus one!) that agile teams should consider when faced with the realities of a set scope, time and cost. Following these guidelines may not make the project painless, but it certainly should give the team confidence that it is well positioned to make commitments to its business stakeholders.
- Conduct an Envision Session: An Envision is a 2-4 week, highly-interactive requirements definition activity that prepares the team to conduct the upcoming project. During the Envision, the team should work with business stakeholders to create a prioritized backlog of features (stories). Though the business may firmly state that all features are critical, there are generally threads of functionality that represent the core purpose of the system. Often, focus on these core processes will reveal the most significant underlying technical challenges and risks.
- Perform Technical Spikes: Research and solve the highest technical risks known for the project early in the projects lifecycle. Concurrent with the business-focus of the Envision, the technical team should begin technical spikes on those technologies, tools or features which present the greatest challenges to estimate (a.k.a., risk!). Technical spiking is just another way to say performing time-boxed research or prototyping in a particular area. The goal of the spike is to develop enough of an understanding of the risk item that the team can plan the work required without attaching an uninformed risk tax to the estimate. All spike work should be throw- away by design so that the team can focus on learning what it will take to overcome the risk and not to solve it completely during the spike.
- Build several Core Threads of Functionality: After the Envision and technical spikes, let the team get to work in their typical agile iterations. I find that shorter cycles work best during this time, and tend to impose 2 week iterations. At this stage, the team should build a couple of the steel threads of the application. The goal of this effort is to tackle the neœscary jobs first and generate some metrics regarding the velocity of the team.
- Revise Estimates: Revisit the prioritized backlog, and revise estimates based upon the learning gained during the Envision and first several iterations. The team should remember to account for complexity and risk at the use-case level and build that into their estimates. Don’t focus myopically on each story in a vacuum!
- Agree to Negotiate: Because the look-and-feel of every feature in the application can’t be known up front, it is imperative that the development team and business stakeholders agree to negotiate on the details of each requirement when it comes time to develop each one. This may result in the business not having every bell and whistle desired, but will ensure the appropriate level of feature robustness required to meet the business objective and commitments. Should time permit, the team can always circle back and improve upon the feature in subsequent iterations.
- Reserve Time for Testing: Agile veterans will often talk about the ability to move from development on Friday into production on Monday. This is due to the level of testing and test automation that is maintained and run continuously during the development cycle. While I’ve seen this work on very mature agile teams, it should not be counted on as teams begin to use agile methods. System, Performance, Security and Integration testing are critical, and should be budgeted in the schedule.
While there is still risk involved with entering a project with a fixed time, price and scope, there are ways to mitigate risk and still stay true to the intent of agile; developing software in a way to improve business results!
Good luck!
