One of the biggest problems that we encounter in software development is change. Change comes in many forms and from any sources, but any work that we have done will be degraded over time by change. The world is going to change.
The traditional approach of trying to plan the project in detail before starting is not immune to this degradation. This approach also has an implicit assumption that the team knows everything it needs to know to plan the project before starting the project, when they know the least about the problem they are trying to solve.
The goal of complete up-front planning, analysis and specification is to understand the cost, delivery date and features to be delivered by the project. While this is a valuable goal, often times the cost of the effort to deliver such a plan and specification is not appropriate for the value delivered. This is true for three main reasons.
- The first is the impact of change on the project. Even if the team could deliver an accurate plan and specification at the beginning of the project, any project that takes more than a few days will almost certainly be impacted by change.
- The second reason is even more significant. Traditionally project managers, subject matter experts, business analysts and sometimes designers and architects do the up-front planning. The people that are expected to do the work often have little input at this phase. The schedule is created with functional dependencies mitigated by a complex project plan. Then the team members doing the work are managed against the plan and schedule that they had little, if any, input into.
- Thirdly, if the goal of the organization is to deliver business value quickly, the question becomes what real business value is delivered by a plan that is most likely fundamentally flawed due to lack of knowledge and understanding of the problem domain and will become more inaccurate as time passes? The answer is commonly, very little. So let’s get started!
This does not mean that we don’t do any planning, analysis and specification, just that we do what we need to get on to the next steps in the project.
It does not mean that we don’t do any long range road mapping or release planning, just that we recognize that these plans will become more accurate and valuable over time.
The goal of agile analysis is to deliver just enough planning, analysis and specification, just before it is needed to do the work of delivering the business value.
Nor does it mean that we do not estimate the effort involved in delivering the business value, but we do it in a way that will help us estimate the effort more consistently in the future. That means teams should use a system of planning and estimation that creates the learning that will over time lead to more consistent results. The first step is involving the developers in that planning. Using an estimating system that is not based on hours for project planning focuses the team on the work and allows the growth of a tribal-knowledge based system that will lead to more consistent and predictable results.