At times, seemingly inexplicable situations are simple to understand once you wrap your head around them. For example, I’m often astonished at how long simple software changes take from the time the change is proposed by the business to the time it’s deployed. Here’s a scenario I see a lot at company after company. Hard to believe at first but simple to understand.
- The business folks identify a software need. Meeting the need requires changes to an existing application.
- They prepare a change request and submit it for approval (Elapsed time: 1 calendar week).
- A business analyst evaluates the need and lays out a high-level plan (2 calendar weeks).
- A lead developer assesses the plan and lays out the implementation details (2 calendar weeks).
- Everyone approves the implementation (1 calendar week).
- The work effort is prioritized and scheduled (1 calendar week).
- The software is developed and tested in a staging environment (2 calendar weeks).
- QA tests and approves the software (2 calendar weeks).
- The software is deployed into production. (1 calendar week).
Total elapsed time: 12 calendar weeks
Actual development and test time: ~2.5 weeks
So it took 12 weeks to deliver something that could have been done in ~2.5 weeks — four to five times longer! Does that seem right to you? Why would any reasonable, rational person find this scenario acceptable?
The reason is simple and it comes down to one word — risk.
A reasonable, rational person who is afraid to take risks, that is, afraid to fail, will find the above scenario perfectly acceptable. It’s a matter of “due diligence”, that is, doing all the little things that you’re supposed to do to minimize risk. And, of course, getting sign-off from all the parties with a vested interest in the outcome so that if failure happens, there are plenty of people to share the blame.
“Failure is not an option!”
These organizations are extremely risk-averse. They avoid failures, even small ones, at almost any cost. They’d rather do nothing than risk failing. If they think they might fail, they buy time. After all, time is cheap, right?
Agile development approaches like Scrum cannot succeed in these environments. When you move quickly — minimizing assessments, reviews and approvals — you will fail. Failure is not only an option, it’s a requirement!
It’s the small, frequent failures that lead to big, successful outcomes. This takes a major cultural shift — everyone needs to learn to think differently. It’s not an easy transition. Everyone wants to be agile but few are willing to fail to achieve it.
Why is this important? Because you can’t reuse or recycle wasted time. How does your organization feel about failure?
photo credit: hmcotterill via photopin cc