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
- Pluralcast #12 : The Future of Scrum with Ken Schwaber by Pluralcast
I greatly admire Ken Schwaber and Jeff Sutherland, the creators 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: Scrum is not perfection. It is a reflector.
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?
Scrum defines just enough rules so that teams expose their disfunctions early. Through the process of inspection, reflection, and adaptation, teams and organizations should grow a learning culture to increase their value.
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