Rediscovering the Basics of Technology Planning
We are approaching the 20th anniversary of the birth of the Agile Manifesto. Teams of technologists all over the globe have been working with Agility for some time. Some have started their journey recently or plan to start in the near future. The principals of the manifesto have enjoyed such widespread adoption that the adjective “agile” is now a noun in its own right. We just say “Agile”. It can now be bought, taught, and certified but still few people understand, or can explain, why it is so effective.
The Basics: Demand and Capacity
Let’s explore two topics key to planning: demand and capacity. Then we will examine the two most common planning strategies, waterfall and Agile.
Demand
Demand is a way of expressing the needs that must be met to achieve a desired outcome. In traditional waterfall projects we capture the demand in the form of requirements. In the world of Agile, demand is expressed in the form of a prioritized list of needs known as a “backlog.” “Backlogs” typically consist of a style of requirements called “user stories.” Demand is fluid, it grows and shrinks and changes directions without warning. The desired outcomes that drive the demand evolve as markets, experiences and technologies evolve. We can influence the direction of demand with the experiences we create but ultimately we are powerless to control demand. Our best option is to become as fluid as the demand that drives us.
Capacity
Capacity, unlike demand, is far more constrained. Capacity is simply the number of meaningful hours a group of people can commit to addressing demand within a given period. Given that there are only so many hours in a day we are constrained by the clock as to how much latitude we have to impact the demand. Additionally, human experience has taught us that there is a limit to the number of people that we can bring together for a common purpose before we start to have a detrimental impact on progress. Too many cooks spoil the broth.
Planning: Waterfall and Agile
The goal of project planning is to strike a balance between the capacity we are constrained to work within and the demand that needs to be met.
Waterfall
One approach to planning is a phased planning approach, often referred to as “waterfall planning.” The first phase focuses on defining the details of how you expect to deliver against the demand and then subsequent phases follow in a commonsense progression. The subsequent phases are expected to execute the project plan with the belief that if we execute the meticulously thought out plan, we will achieve the desired outcome. Frequently, waterfall projects have processes in place to accommodate changes throughout the phases, but they are largely designed to protect the plan from change rather than adapt the plan to change. In other words, in Waterfall planning, the plan becomes the priority. In Waterfall planning the people that make up the capacity are borrowed from teams within your organization and often have multiple priorities. The project is funded for a prescribed scope of work described in the requirements gathered in the early phase of planning. It is expected that when the completion date identified in the plan is reached all scoped work will be completed and will meet the sponsor’s expectations. Waterfall projects often span months, sometimes even years, and require a significant effort to maintain good communications. Larger organizations have project management offices (PMO). The purpose of the PMO is to provide oversight and support to ensure that:
- The plan is executed as outlined
- Spending is managed
- The people executing the plan are not bogged down in distractions
The PMO has a variety of reports it uses to both track progress against expectation and to communicate to the sponsor and stakeholders the status of work in progress. Waterfall planning has been used for decades to deliver technology projects and is widely accepted as the standard for planning.
Agile
Agile planning was born from a desire for a different “tactical” approach to technology delivery, especially software, and derived from the thoughts captured in the Agile Manifesto. Agile focuses on teams of people doing work who have direct connections to those the work is being done for. The teams are intended to be fully capable of doing all the work necessary to meet the demand of their customer. Agile is planned in small iterations, often fewer than four weeks, to frequently deliver small increments of high-quality working software that meets the needs of the customer. Agile takes a data-driven approach to ensure that work being done is valuable. Agile ensures that the project can accommodate change. Change is inevitable and because of short delivery cycles Agile is well positioned to adapt to changes on the scale ranging from very minor to “stop and try something different.”
We live in a time when the pace of technology delivery is constantly accelerating. Organizations all across the globe are finding ways of innovating rapidly to stay ahead of the rate of change. For those who are not evolving to the new pace the runway for takeoff is getting short. If you get to the end and your wheels are not up you will likely crash and join the likes of Blockbuster and others who thought they could simply weather the storm.
Agile’s approach to balancing capacity against demand starts from the principal of embracing change. Adaptability is Agile’s superpower. Waterfall projects will have a place for the foreseeable future. The most important thing that an organization can do is define when and how to apply each of the strategies. Once the decision is made, commit everything to following all aspects of the chosen strategy. But you have to choose one or the other. Blending Waterfall and Agile has proven to be an ineffective, confusing, and stressful approach that often leads an organization to a false conclusion that Agile does not work.
JoeBrown 