“Responding to Change over Following a Plan”
If you read the Agile Manifesto, it is right there as the 4th, and final value of Agile Software Development. Normally when I think about this value, or explain it to others, I usually talk about it meaning that we should make sure we respect reality, and be more focused on responding to empirical feedback over adhering to a plan. This is all true, but I’d like to pose that it could be interpreted in another entirely different way. By increasing a project team’s flexibility, we can reduce the amount of planning required. Let me offer you an analogy. Imagine you are going on vacation tomorrow and need to catch a flight in the morning. Chances are, you have carefully selected your flight time. By the time you reach the day before your flight, chances are that you have made travel arrangements to get to the airport such as scheduling a taxi or shuttle. Of course I need to arrive two hours early, so chances are I am planning to get up extra early to get to the airport with enough time that I don’t risk missing the flight because of lines for bag check or security. All of these plans must be carefully laid out and choreographed because the stakes for missing my flight are quite high. Chances are I will face a steep financial penalty, possibly missed connections, long delays and stress. If I miss that plane, it’s a big deal with serious consequences. Now compare that experience to taking a subway or bus somewhere. I may review a schedule, but chances are I will simply go to the stop and wait. I don’t need to precisely plan timings, rather I have a general heuristic of how much time I should set aside to get from one place to the next. Even if I come around the corner to the station in order to see my train departing, chances are this will not delay me more than 10 minutes. That is a frustration, but by no means the stakes of missing a plane.
This contract between the pressure of making a plane and the pressure to catch a subway train represent the two poles on a spectrum representing a team’s capability to deliver. Teams that have very limited capacity to do given tasks – a team that has several specialized skills only one person can do, for example – are very fragile, one unplanned absence, resource contention, or other problem and the team will be unable to complete their work in a timely manner. Like in the case of making a plane, being just a little late can carry a steep penalty. We can compensate for this fragility by robust planning and time buffers, but these carry their own costs. If I were to fly from my home airport in Boston to Florida, that flight would take about 3 hours, but current travel guidelines would recommend I get to the airport 2 hours early. Assuming transportation to the airport is not a factor, this buffer represents 40% of my travel time, all because of the uncertainty of airport lines and the high stakes of missing a flight. This is not to mention the actual cost of planning as well.
Capabilities are an Asset to Avoid the Expense of Planning
Rather than teams investing more energy in planning to manage their limitations, they should look to improve their resiliency. We do this by building up cross training in team members so that they can work in multiple capacities, engineering our products to be modular, and using a common shared language for requirements, allowing people to swarm around a problem with a common context. These sort of techniques at first blush may sound sound like waste, until we take into account the high cost of making plans. This cost is more than just the effort of a project manager to put together a complex gantt chart. Sophisticated plans increase dependency and risk, people may not realize that obscure items are on the critical path and could impact the schedule. The increased risk may also make team members more risk adverse and less willing to experiment, which is precisely the opposite of what we want when working in a complex adaptive system. Let me offer some real examples.
A team that is dependent upon one person shared across teams, faces a dual risk. If they are not ready for the specialist on the agreed upon date, they may face a delay until the next scheduled window they have with that person. Even if they meet their deliverables on time, there is a risk that another group using that specialist may be running late and end up overriding the agreed upon schedule.
A team which is limited in its ability to deploy code across environments must carefully plan deployments. The longer time lag between these, then the more interdependencies are introduced, increasing the sophistication of the deployment and ironically slowing it down further.
A team that must execute a carefully choreographed set of activities to have any chance of completing its work according to the planned time horizon will never experiment or take risks to learn new things, as they can’t risk breaking their plan.
Planning is Still Invaluable
None of this is to say that our goal should be to eliminate plans entirely, or even that planning is always unnecessary expense. Indeed,my view has generally aligned with Dwight Eisenhower when he famously said, “Plans are useless, but planning is essential.”
The key thing we need to remember when we are doing that planning is that when we are faced with a situation requiring quite a bit of sophisticated planning to manage, that perhaps we should look closer at the system and see if we need to change the nature of how our team is working so that we can succeed with a simpler plan.