In Scrum there is a concept of canceling the sprint. This is not done often. I suspect many people would see it as failing in some fashion, an indicator of problems. I posit that this action, or a similar one in a different framework, is a sign of a strong team that is very fluent in their Agile practices.
The modern business world is fairly harsh on failures. The problem is, success rises from failure. Sure, we’ve all heard of Edison’s success in proving how not to create a lightbulb before he finally landed on a process that worked. Even in nature, we see massive new growth in areas devastated by wildfire – something many would see as a failure to protect those areas.
The same concepts apply to agile product teams and organizational agile transformations. Sometimes, things don’t work. We can learn from those times and discover something even better on the other side.
A classic product team will bring a product all the way to the market before allowing for a large change in course. Sure, there may be small adjustments along the way, but since Mr. Jobs gave us permission to tell the customer what they want the core idea will be held sacred. The problem here is that it is very difficult to get a customer to buy something they have no idea they want. Usually, the company ends up with a product that fails, not one that changes customer behavior. This isn’t the end for a company. They can learn from the situation and build a new, better product.
What if there’s a better way? What if they allow the core product to change earlier on? What if the product failure looks more like a meadow or copse of trees burned down than a whole mountainside? You may argue the re-birth won’t be as dramatic. While I’d suggest you’re taking the analogy too far, the answer is that each iteration of the product is like a new section of the mountainside being burned out and re-born. In the end both approaches result in a whole new mountainside, but in one the majority of the land was available for use at all times. In the other massive devastation caused mudslides and greater damage downhill.
Allowing the product team to iterate smaller parts more often will almost always result in products that are more aligned with the customer needs at a faster pace. Disruptions of changing products are minimized while benefits are maximized.
In a similar fashion, trying to change the product development process of an entire organization in one fell swoop versus a little at a time can be devastating. (Though I do reserve the right to define “little at a time,” I am a consultant and we love “it depends.” 😉 )
There are times pulling of a band-aid is better than peeling it back. For modern businesses in the largely unforgiving climate we now find ourselves in, this may not be as often as we think. While Agile processes are all about embracing change, successful ones do it responsibly. This applies to the process of becoming agile, or executing on the promise to deliver products.
If your team is struggling to find the right balance between large and small changes contact me. I work with teams and organizations to help them do better where they are at.
More
In Scrum there is a concept of canceling the sprint. This is not done often. I suspect many people would see it as failing in some fashion, an indicator of problems. I posit that this action, or a similar one in a different framework, is a sign of a strong team that is very fluent in their Agile practices.
