Conformance to Plan
In preparing for battle I have always found that plans are useless, but planning is indispensable.
- Dwight David Eisenhower
Agile developers are planning addicts. We plan, and plan, and then plan again. We plan at the beginning of each week. We plan in the middle of each week. We plan for the week, and we plan for the next three months. We measure our velocity so that we can make better plans. We measure our rate of business value delivery. We measure how much business value remains to deliver the next release. We measure, and we plan; we plan and we measure. What we don't do is stress conformance to a plan.
Name some professional careers. Doctors? Lawyers? Soldiers? People in these professions plan constantly. Doctors make treatment plans. Lawyers make litigation plans. Soldiers make battle plans. And yet none of them are transfixed on conformance to those plans. Each proves his worth by adapting those plans to current exigencies. No doctor would continue a treatment plan that proved harmful to the patient. No lawyer would continue a litigation plan that the jury wasn't responding to. No soldier would continue a battle plan that the enemy had clearly divined. Instead, each of these professionals would replan to find a way to get to the best possible outcome.
Lately I have encountered a number of IT managers who are compulsive about conformance to plan. They want their developers to estimate an entire project up front, come up with a development plan, and then deliver against that plan. As reasonable and professional as that sounds, it's a failing strategy. History alone shows that the insistence on a single plan doesn't work. The rate of resultant project failure over the last several decades has been high enough to be dubbed "the software crisis". Consider the GUI for the american air traffic control system several years ago. The prime contractor had estimated it at $400 million dollars. After exceeding this budget (and schedule) by a factor of three or so, the project had to be scrapped.
Einstein once said that repeating the same actions over and over and expecting different results is the definition of insanity. The IT industry has been transfixed on conformance to plan for decades. The results have been dismal. Why do we continue to repeat what we know doesn't work?
I agree that it would solve a whole bunch of problems if we could find a way to conform to a single plan. Yes, it would make it easy for the business to know how much a software project would cost. Yes, it would tell the business when they would get the software. Yes, it would make it easy for IT management to know which projects to start and which ones to defer. Yes, yes, yes. The problem is, that the strategy doesn't work. The plans are wrong. The plans are disastrously wrong. And insisting on conformance simply leads to failure.
There are other ways for the business to manage the project portfolio. Indeed any successful business must already be adept in these skills. Businesses commonly manage non-software projects that have uncertain schedules and uncertain outcomes. One could say that business is the management of projects with uncertain outcomes and uncertain schedules. Consider the uncertainties of introducing a new product, or a new sales strategy, or a new marketing plan. Businesses manage these kinds of uncertainties all the time; and they do it by measuring and planning in very short cycles.
So businesses already have the skills to manage software in the agile manner. High level managers already know that plans are useless but planning is indispensible. They run their businesses that way.
It's time IT started running their departments like a business. Conformance to plan is a failing strategy. Adapting to change by measuring and planning in short cycles is the winning strategy.
!commentForm
The quality of the commentaries is really impressive. An assiduous reader
Demand for conformance to plan is simply an expression of a lack of trust in the team to deliver. Attacking the manager for asking for the plan is treating the wrong symptom. Criticism lies with the manager, yes, but for failing to address why he/she does not trust the team. Teams being asked for conformance to plan need to look inward to determine what they can do to restore trust with the management team on the ability to deliver. Only then will the flexibility to adjust be earned back.
It is an all too common and unfortunate story that agile teams state, "we don't do planning, we are agile," often citing the quote you use above. This is onerous not just in its ignorance, but in what it says about the teams attitude and relationship to the management and the customer. A team that cares about aligning to its delivery to its stakeholders, cares about communicating to them what to expect.
One of my favorite quotes recently is "those who ship get to speak." I think you'll find that teams that ship earn the ability to plan in the most effective way. Those that do not, have not earned the right to complain.
It is an all too common and unfortunate story that agile teams state, "we don't do planning, we are agile," often citing the quote you use above. This is onerous not just in its ignorance, but in what it says about the teams attitude and relationship to the management and the customer. A team that cares about aligning to its delivery to its stakeholders, cares about communicating to them what to expect.
One of my favorite quotes recently is "those who ship get to speak." I think you'll find that teams that ship earn the ability to plan in the most effective way. Those that do not, have not earned the right to complain.
I'm completely on board that credibility comes from delivery. I also agree that failure to deliver leads to distrust, which leads to mandated plans. What galls me about this is that it's a cul-de-sac. There's no good way out. Once managers lose trust and demand conformance to plan, the whole system is stuck in a dysfunctional loop with no exit condition.
To reverse the dysfunction, both management and development have to push the reset button on their relationship. Both have to agree to suspend distrust and try something new. Nothing is gained by turning up the volume on the demand for conformance to plan.
To reverse the dysfunction, both management and development have to push the reset button on their relationship. Both have to agree to suspend distrust and try something new. Nothing is gained by turning up the volume on the demand for conformance to plan.
Add Child Page to ConformanceToPlan