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. )