A Scrum Story
Scrum failed here. The development teams in this company built products that market did not want. How can the process/framework be successful if end result is failure. The reason there were some productivity gains with Scrum was because the company went from no process to some process. Because of Scrum, management got day to day visibility into what engineers were doing. Earlier that visibility and control was missing.
Company had remarkable technical talent, trust, self organizing team and a great work culture even before they adopted Scrum. Company had top notch Scrum Coaches and Scrum Masters and used the best agile tool. It was as perfect a Scrum as it could be. Scrum was inconsequential to the end result.
If you are going to fail, Scrum can make you fail faster. Even that did not happen here. It took years before company realized its products had failed.
So what was the missing piece. Why did not company realize till very late that their products failed? After all they were Agile and doing Scrum so very perfectly.
Scrum development teams builds what product owner and management asks them to build. Scrum Teams are only self organizing to the level that they can decide on “How to build it. And who will work on which task.” Detailed requirements are often given to the Scrum development team. Requirements may or may not be documented. Scrum teams often do not do much upfront architecture and design and take on a lot of technical debt. But technical debt is a topic for a different story. Here the products did not fail because of technical debt nor did they fail for lack of quality.
NHL great Wayne Gretzky stated: “A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.”
Scrum can you help you run faster but cannot tell you where the puck is going to be. Also scrum or agile is only as good as the people that work on the team. You need to know where are you going.
Wait, you say, what about all the Agile and adaptive thing we have been hearing about. What about review meetings and Retrospective, you ask. After all Agile and Scrum are based on Deming’s PDCA cycle. It is supposed to be adaptive. Why did not review meetings and retrospectives catch these issues sooner?
Because the same Product Owner who gave the requirements was the one sitting in the demo/ review meeting and he got what he had asked for. He was not the final end user of the product. He was only a representative. And product owner did not go out and showed it to the end user soon enough.
So when do the real end user sees and gets to use the product?
Even if you are doing scrum or agile, consider showing to end user and have real end user test drive the working prototype as soon as possible and get feedback. If you can do it end of every iteration very good else do it as soon as you have a reasonable prototype ready. In many cases end user is external and it may not be possible. Then get them to come to your usability lab and test drive the product or provide a limited beta.
I have even seen one case where end users said they are fine with product when they played with prototype or saw demo. When exactly the same thing showed up as finished product and they had to use it for their work they hated it. Our Scrum Master said ” We have been demonstrating it to you every month and you just had cosmetic changes. And now how can you hate the end product?”
Invite end users to use beta product as soon as possible and get their feedback.
Sooner and more frequently we get the feedback from the right people the sooner we can fix it. Sometimes the right person to give quality feedback is product owner but many times he is not.
(This story is based on real life experiences and a real life company. Conclusion is mine. )
Update: As solution to the problem I raised above – I have two new posts – Quality of Feedback is important and Building Software that users want
Sounds like scrum didn’t fail, but the product owner failed. The product owner is a very underestimated role. I blogged about that yesterday: http://www.andrejkoelewijn.com/wp/2011/09/29/scrum-it-all-starts-with-the-product-owner/
The right vision for the product is extremely important, being a user yourself can help tremendously (scratching your own itch). Many successful companies were created trying to solve their own problems. (http://www.andrejkoelewijn.com/wp/2011/07/22/scratch-your-own-itch/)
Andrej, You are right PO failed. But in end we were not much better off than what we would have achieved from waterfall so Scrum also failed in that sense. I read your blog posts. Both make very good points.
Agile techniques like Scrum are terrific on the delivery side of the product. They are NOT a replacement for strong product management.
The product owner responsibilities defined within scrum represent only a small piece of the product management picture. If your product owner’s vision does not incorporate things like ROI, voice of the customer research (this is more than just showing demos to focus groups), and competitive analysis, they will be little help in building the right product for the marketplace.
Hi Diana, I agree. All very good points. We need an Agile framework/process for whole end to end product development and not just the delivery side of it. New product development is sweet spot of Agile. In my opinion for Agile techniques to be really successful we need to have an holistic view of new product development. We are working on thinking through such a framework/process.
It sounds to me like Scrum worked just fine.
Implicit in Scrum is that you have a paying customer and that you feed that paying customer until he stops paying.
The PO is the single person accountable for the direction of the product.
When you fail, it is often convenient to place the blame someplace else. “We are brilliant. We did Scrum. Scrum failed. Who? us? Fail? No, we didn’t fail! We’re great!”
Tell that to the bankruptcy judge, or your next employer, or your next investor…
The whole point of Scrum is to look at reality frequently, warts and all, recognize your problems and correct them as quickly as possible. You didn’t do that and you failed. While I am sorry to hear that, I don’t buy your explanation.
I would suggest you start by saying ‘we failed’ and then think honestly about what you can do better next time.
I find Steve Denning’s Radical Management provides a useful ‘navigation star’: the purpose of a company is to delight the customer. The best results (and the most motivating environment) occur when the people delivering the solution have a clear line of sight to those needing and using the solution. In Scrum, I think it is the Product Owner’s to make that happen. Maybe that will help next time…
Good luck!
Scrum is a development framework, not a business management framework. I think that saying “Scrum failed” is somewhat disingenuous sensationalism.
In the description above, the development team tested their assumptions and work by showing the result to the Product Owner. The PO did not test his assumptions and work with real users. This is a common enough problem that people have gathered under the banner of “Lean Startup” to address it for fledgling companies where the failure will not just be of the product, but of the company itself. Larger companies can take advantage of the same techniques, of course. They just have to get out of their comfortable bureaucracies and base their decisions on experiments.
Yes, any version of scrum where the Product Owner is the outer bound of input is bound to fail. That is why this version of scrum is not current – it is very 2005. Now that the Product Owner is on the Team and the Team does its reviews for external Stakeholders the probability of this happening decreases. The PO’s primary job is to make sure the ‘right’ stakeholders are available for Reviews, and this clearly did not happen here.
This story shows why scrum is constantly changing, and why understanding why scrum exists is much more important than following the practices of scrum.
A sad story. The organization didn’t understand Scrum, so they implemented it in a way that failed them. Sad…
Scrum didn’t fail your company. Your company failed at Scrum.
Specifically, your Sprint Review, as you described it, was not correct, and is a Scrum Worst Practice. I have documented the Worst Practice here:
http://www.scrumcrazy.com/Worst+Practice+-+The+Sprint+Review+as+a+Signoff+Meeting
Having said that, you can still have a product failure if the PO and stakeholder roles are played poorly. However, having the PO and at least a few stakeholders present and contributing/collaborating at a Sprint Review greatly reduces the chances of total catastrophic failure.
Ashish,
I also noticed from your story that you did a big bang delivery, which is a poor habit in Scrum. In your defense, though, I think this is a weak spot in the Scrum Guide. The Scrum Guide speaks of software as being “releasable”, but doesn’t say that it should be released fairly frequently.
IMO, the SG should state something like:
“Releases(new increments of functionality available for use by users) should occur at least a few times a year, and it should be well noted that for every month that goes by where a product is not released, transparency decreases, and thus, inspection and adaptation opportunities are missed.”
“The development teams in this company built products that market did not want”. How can Scrum be blamed for that? That just seems like nobody took the time to Envision the product, or to continually validate and verify the product as it was being developed. What happened to the ‘demonstrate & recview’ part of the Scrum thinking? That’s not Scrum … that’s foolishness … unfortunately a common practice in many IT & development shops.
“Scrum failed here.” Did it? What about your other comment that “Scrum was inconsequential to the end result.”. You can’t have it both ways … either Scrum was inconsequential to the result, or Scrum was so consequential that it was the cause of the failure.
The plain fact is, you can build the wrong product using any development approach, if you don’t have a clear vision of the outcome, and a clear understanding of the value of the product to the organisation. In this case, it seems that nobody bothered to find out what customers wanted … an essential part of product development process.
OR … another view is that this was an experimental development that failed. There is a lot of value in failure. It helps you understand what success might look like. The trick is not to let the failure cost too much, which is where ‘proper’ Scrum rather helps, by revealing the potential failure at an early stage of development.
Actually, scrum didn´t failed, it succeed if you implemented it right, scrum is a framework that help every kind of problems to show very early, didnt in you early launch got some feedback about customers, its not even a PO problem in my opinion, ideas do suck sometimes, agile and scrum process help you find this early and spend your budget somewhere else instead of a big bang launch after building the whole stuff, and if you do it right scrum actually succeed even with sucky ideas
Saying SCRUM failed in this case is like saying Eclipse or the IDE they were using failed. The tool isn’t responsible for the failure.
You can use a hammer to paint your walls, when the walls fail to be aesthetically pleasing it isn’t the fault of the hammer.