Disclaimer: no project management style is perfect — including scrum
As a scrum master and proud promoter of agile culture, I have found have found the following talks challenging.
Path to Agility 2011 – Ken Schwaber – Scrum and the Product Owner by Agile Toolkit podcast
http://agiletoolkit.libsyn.com/webpage/path-to-agility-2011-ken-schwaber-scrum-and-the-product-owner
Pluralcast #12 : The Future of Scrum with Ken Schwaber by Pluralcast
http://elegantcode.com/2010/03/29/pluralcast-12-the-future-of-scrum-with-ken-schwaber/
I greatly admire Ken Schwaber, the creator of Scrum, for trying to encourage our software industry to focus on creating value and doing so with transparency/quality. The act of executing work with transparency helps teams and organizations find issues and adapt.
So… what do I mean by challenging? These talks point to a realization that scrum, as implemented across our industry, has a few growing pains.
Growing pain #1: Who writes user stories? Across the industry, it appears that product owners are resisting ownership of writing down user stories and done conditions. Why is this a problem? The product owner, as mandated by the scrum process, is responsible for maximizing the value of the product under development. In many cases, the product owner is a “subject matter expert” in the domain of the product. If the subject matter expert is allowed to not write down their exact goals and “done conditions,” the risk is introduced that the team must interpret the intent and goals of the product owner.
Michael Cohn seems to provide a partial solution to this problem by observing that “who writes the user story” is less important than making sure there is open discussion of user stories and done conditions among the team, scrum master, and product owner. (http://www.mountaingoatsoftware.com/topics/user-stories)
Growing pain #2: Ken has pointed out several times that the rules of scrum are easy to learn. Implementing scrum, however, is still very hard to master. Many organizations are discovering that scrum uncovers faults in engineering practices, team collaboration, or organizational dynamics. In many cases, teams abandon scrum so that more disciplined engineering/organizational practices can be avoided. What’s the problem? Our industry needs the courage to keep promoting discipline and quality in our daily work. If scrum exposes organizational or engineering issues, are we facing those issues head on?
On a personal and an organizational level, challenges introduce the opportunity for innovation and adaptation. In my personal work, I will be searching for solutions to both growing pains. I look forward to see how the agile / scrum community responds.
To fellow agile leaders, I would enjoy hearing your strategies for documenting user stories. How do you foster courage on your team?
Leave a Reply