I’ve seen a lot of product teams botch Scrum to the point that it’s unrecognizable. Even now in 2015. I think the issues Adam Pisoni, co-founder and former CTO of Yammer, discusses are due to the misuse of Scrum, not flaws inherent in the method itself.
Used properly, management should not be calling the shots on the priorities. The product owner should make these decisions. A savvy product owner works closely with the team and knows when to give them a voice on the priorities given various technical factors, such as work effort, risk, dependencies, technical debt, etc.
The product owner should also provide the big picture during the release planning. Explaining the vision and goals of the release. And why it’s important for customers. A savvy product owner works closely with the engineers, and involves them in discussions with customers. So there should be no surprises at the release planning.
A real Scrum team is self-organizing and autonomous. The team has complete authority over how it gets its work done. A savvy product owner will protect the team’s independence and will not interfere.
Your turn. Are the issues Adam outlines due to the misuse of Scrum or flaws inherent in the Scrum methodology? I go with the former.
I’m Sorry, But Agile Won’t Fix Your Products
“Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.”
~ Steve Jobs
A product stuffed with features that are barely used is indicative of a broken process, flawed thinking, or laziness. Often it’s best to do one thing well – better than anyone else.
It takes focus and discipline to discover what’s most crucial to your customers. And guts to stand-up and make the difficult decisions about what gets left out or is less important.
Figuring out what matters most is hard work, but it’s your responsibility to do it. And remember to use this answer when you need it, “It just doesn’t matter.”
Don’t be one of those companies that builds a product in search of a problem. Understand the problem you want to solve before you do any work on your product. Testing the problem you want to solve is the most important activity in product development. Get this wrong and everything that follows is all for naught. You will have built a product that no one uses.
What will your customers say when they see your new product or features for the first time? “Wow, this is exactly what we needed!” “This is not what we were expecting.” Or maybe the dreaded, “This won’t work for us; we can’t use it.”
Congratulations, your potential customers have confirmed that they want your product. That they can’t live without it! Your next step is to define your product in more detail. Which you will need in order to get input and feedback from your customers about what you plan to build.
In the beginning you have an idea for your new product or capability. But will it really solve your customers’ problem? Before you start building it you need to test the idea with your target market. You want to do this early – before you spend time and effort building it. Keep the process lightweight so it can be done fast and for a low cost.
Has your company ever released new software products or capabilities that ended up not being used by your customers? Never, right? Unfortunately, I’ve seen it happen, a few times too many. Untested assumptions and guesswork can be costly and tragic.