*** Disclaimer: no project management style is perfect — including scrum ***
What is Scrum?
To introduce scrum project management, I would encourage you to review the following video. (Scrum in 10 minutes) While scrum was created for the benefit of the software industry, the ideas can be used in education, general leadership and many other industries. Since scrum provides a framework for building products, I believe that scrum can provide benefits to teachers who value project based learning. For other teachers, replace “building software” with the idea of building minds and person-hood. Please refer to our post “5 ways to get more results in your teaching environment.”
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?