Scrum Can Save and Destroy You
Scrum can save and destroy you. And sometime it does both in that order. Only those unaware or unafraid will admit that they are not “agile” converts these days, running “scrum” teams to build what matters. And there is no doubt that more integrated and continuously improving teams achieve more than their rigidly structured ancestors who went from gate to gate.
But why are so many teams unhappy and building unlovable software? We might all be moving faster, but so fast that we are simply creating random acts of software.
A random act of software is usable new functionality that has no real reason to exist.
There are many reasons for our inability to slow down and think deeply and sprint at the same time. Let’s admit up front that it is hard and most people gravitate towards staring at the next group of trees — especially technical product managers and engineers. But I think the real reason is that we are making poor prioritization decisions because we are listening to too many voices with no way to reconcile the truth. The good news is that product development teams are wicked smart and can learn to see and hear the warning signs that they are headed astray.
I have now interacted with well over 500 product and engineering leaders in the last six months at Aha! and this is what I have learned.
When I ask how they innovate and build great product, 90 percent of them proudly answer, “We are agile and organize around scrum teams.” (You may wonder about the other 10 percent — do not worry — they sheepishly say they are transitioning to agile.) This is not totally surprising since the benefits of a more iterative approach to software development have become well documented. It is practically a religion at this point.
But here is what’s concerning — it’s not clear that customers are benefiting from these more lean approaches. Product managers and engineers also seem to be struggling. They are consumed with the mechanics of their agility, while sacrificing planning and prioritization. They are sprinting fast — but often in the wrong direction. And that is a shame.
Most product folks know that something is not right, but they have not been able to do anything about it. They keep trying to follow the formula, stay heads down, attend every stand-up, and work harder. But their product does not get better and customers are no more excited. And often times, when they finally figure it out, they are out of time, money, or engineering attentiveness.
The real issue is that most product managers don’t recognize that they must spend more time on big thinking and careful feature prioritization than they do on grooming the backlog.
After another customer told me about how they were going to pivot again, I started jotting down all of the arguments that product managers hear (and make themselves) to prioritize the roadmap. And then it struck me — if you listen closely to the arguments being made for FEATURE X vs. FEATURE Y prioritization, you will know if you are on track strategically or spinning out of control. Beware the following demands:
The sales guy needs FEATURE X to close the deal.
Here are all the FEATURE X, Y, Z we must do first to clean up the “technical debt.”
The CTO thinks FEATURE X is a game changer.
Our competitor has FEATURE X.
FEATURE X is in the industry analyst report.
We could really penetrate this vertical if we had FEATURE X.
Our partner really thinks FEATURE X is what their customers want.
The CEO thinks we should add FEATURE X.
FEATURE X would give us the ability to charge more.
Support says FEATURE X is required or the customer will cancel.
Any one of these arguments might be a wise or a disastrous reason to prioritize FEATURE X. But it is impossible to know unless there is a thoughtful strategy in place that everyone has agreed on. For example, if channel expansion is fundamental to your product strategy in 2014, prioritizing the demands of a partner might make sense. Or if reducing support costs is a strategic initiative, great customer service should be a key driver of your roadmap.
The reason that product teams go wrong and create random acts of software is that they do not take the time to set a differentiated product strategy and then align the roadmap against it.
And it is not enough to simply say that creating customer value drives everything. Your product vision, goals, and initiatives must come first and provide a decision framework. And you need an easy and objective way to rate FEATURE X against what is strategic and, as importantly, ignore FEATURE Y because it is not.
Otherwise, you will be busy hopping from one stand-up to the next. You will be sprinting faster than ever — with no guarantee that customers will care or, even if they do, that you will build a sustainable business.
