Being agile is not about responding to change. It’s about enabling change. I know; it sounds like a semantic debate. What’s the difference and why should you care?
There’s a world of difference between responding and enabling.
When you enable someone you give them the means or the power to do something. When you simply respond, you are reacting to something.
We think about software development teams responding to change. Change comes from the business stakeholders. As their needs change, as the competition changes, as the business evolves, changes are imposed on the developers. They must respond. But responding is no longer enough. The business needs to know that they can affect change at any time in the development process — and without warning.
Consider a scenario like this. A business stakeholder says, “… We needed feature X but now we don’t. We need feature Y instead and in the same timeframe we’ve discussed”. If the team is following a variant of waterfall development, this change will have to be vetted; a change request will be written, submitted and approved; an impact analysis will occur; finally, the change will get incorporated into the project plan.
Conversely, if the team is following an agile development variant like Scrum, Kanban, XP or Lean, the change will be added to the backlog and incorporated into the next cycle (sprint or iteration). If the team happens to be implementing “X” in the current sprint, the sprint could be cancelled immediately, but this is rarely required.
Don’t protect the process; protect the business.
In both cases, the teams are responding to change in a manner consistent with their development processes. However, in the waterfall case, the change process is cumbersome, lengthy and designed to protect the development process. In the agile case, the change process is integrated into the development process and operates seamlessly.
The agile team has enabled the business to change anything at any time and have the change incorporated into the next development cycle. If the cycles are short (I always recommend 2-week cycles at most and 1 week is better), the business may see some aspect of “Y” within a few weeks. (Waterfall teams often require a few weeks just to process the change request.)
Beware the downside
Be aware that there is a potential downside to enabling change. The development team may find itself handling many more change requests. If the business folks embrace agile development and actively participate, they will change their minds or even envision functionality that they never would have thought about prior to seeing the software in action.
Is that bad? I think not. Henry Ford once said “If I had asked people what they wanted, they would have said faster horses.” Of course they would. People can only envision what they know. Once they see something new and better, they want more of it. It’s our job as technologists to give it to them!