…you are not doing Scrum.  Recently, I had given a number of Scrum Lead classes to people interested in change.  Invariably when you get a bunch of people together who are dealing with the same organizational obstacles, they want to know why the organization has had so much difficulty in adopting Scrum.  After oberving a number of people who have attended my class apply Scrum, there is one consistent thread with all these Teams: no Product Owners.

The Product Owner is responsible for executing on the Vision for the product and this is manifested through the Product Backlog – the central planning artifact in Scrum.  The Product Backlog is simply a list of all the functional and non-functional requirements for the product.  It is just all the stuff that needs to be done to release the product.  It can have lots of structure or very little; it is up to your environment and how much process ceremony your organization requires\is comfortable with.  The Product Owner is also the gatekeeper of what goes into the Product Backlog and their priorities.  As Ken Schwaber likes to say, and I am paraphrasing here, “The Product Owner is the single wringable neck”.

So how does this relate to my observations?  Teams without Product Owners tend not to execute Scrum very well in a number of key ways:

1. Missing the Product Backlog - Teams will naturally focus on the Sprint Backlog since that is their artifact.  IME, no Product Backlog usually means Teams will lurch from Sprint-to-Sprint with little focus on strategy or the “big picture” in mind.
2. Low quality Sprint Reviews - Sprint Reviews will focus on completion of engineering tasks and not seen as a chance to gather meaningful feedback or re-prioritize.  I have seen a lot of “Atta boy”, back slapping reviews for completion of engineering tasks, but that is not the point of a Sprint Review.
3. Cursory Sprint Planning - the Product Owner helps the Team understand the business context of the work the Team commits to.  When the missing Product Owner is missing, the Team will only use Sprint Planning to assign\sign-up for work and not discuss the goals for the product.
4. Little thought about the Customer value - The Product Owner represents the Customer or gives voice to their needs.  Without this person at the table, literally & figuratively, Teams generally will not think about Customer value.
5. Lack of balance between business & engineering - Normally, when there is no person on the Team whose job is to think about the business, the engineers will make all the decisions.  Do you really want your engineers making business decisions?

Scrum is a very simple framework with clear roles.  Missing one of the key roles creates an imbalance in the system, a very serious imbalance.  I used to say that if you cannot find a Product Owner then maybe you should just cancel the project, i.e. if the organization cannot dedicate an individual to the product, then maybe the product is not that valuable to begin with (which is useful information to know).  I’ve changed my mind on that statement – maybe the work is still valuable, but Scrum is not the right vehicle for implementation.

[Alternatively, you could also title this post "Without a Customer it is not XP" and all the same concepts apply - CEN]

…where I have been, I just wanted to let all of you know I have been teaching.  One of my responsibilities is to train people on how to use Scrum.  During the past two weeks I have trained about 14 people on how to be an effective and useful Scrum Leads, our equivalent of a ScrumMaster.  To be a Scrum Lead, you need to complete my tailored, two-day course inspired by the Certified ScrumMaster (CSM) class I attended in February, 2005 and taught by Ken Schwaber, Tobias Mayer and Paul Hodgetts.  [Please note: I do not "mint" brand new ScrumMasters and I make it very clear to the participants in my course they are not CSM and they need to take the Scrum Alliance's course to become a CSM - CEN].  

When I began with the original outline, I used the CSM material as the basis for the “must have” topics, but over time I have added a number of topics, exercises and discussions around skills I have found people need in order to be a good Scrum Lead in large organizations.  In October, I will have taught this class six times this year!  The course agenda has morphed and flexed around what people in the class wanted to discuss and the exercises they found useful.   Some of the items in the original agenda are now separate, two-hour training sessions on a single topic or specific tools\techniques.  You just can’t do everything you want in two days, so I am always looking for ways to shorten the class and focus on the key elements of Scrum – quality, inspect-and-adpat, visibility, accountability, self-management and collaboration.

Day 1 Purpose: Learn the Scrum framework & how the various roles interact.

1. Why am I here?  How is this training going to work?
2. What is Scrum?  How is it related to Agile software development?
3. What does Scrum mean when it talks about collaborative, self-managing teams?
4. How do the pieces of Scrum work together to deliver value to the customer?
5. How do the various Scrum roles interact with each other?  What is the mandate of the Scrum Lead?

Day 2 Purpose: Practice using parts of Scrum & demonstrate your command of the material.

1. How do I ask questions for change?
2. Do I understand the workflow of Scrum?
3. Why are user stories useful for a Product Backlog?
4. How can I estimate items in the Product Backlog?
5. How do Scrum teams use the Product Backlog for short term & long term planning?
6. What are some techniques I can use at the Sprint Retrospective Meeting?
7. Do I appreciate the value of Scrum?  Can I use it on my project?

I agree this is a pretty ambitious agenda for two days and I like to divide the class into two high-level pieces: day one is more theoretical and thematic, while day two is more practical and ties together all the theoretical concepts into real activities.  My main goal of the course is to give each of the participants enough information about Scrum so they can decide if using the framework will work in their environment.  I consider a statement like this to be a success: “Thanks for taking the time to explain Scrum and I understand how the pieces fit together, but it ’s not for me.”

One of the main reasons for creating a tailored Scrum class was we had a lot of people being asked to run Scrum teams with little more than the standard “one-hour-this-is-Scrum-powerpoint-now-are-you-ready-to-do-it?” presentation.  I feel the lack of training and recognition that Scrum Leads need help and guidance was a main contributor to why we struggled so much with Scrum when I first got here.  Having poorly trained people execute a process they did not understand and were oh-so-quick to modify was how Scrum acquired a “bad reputation” with management and the engineers (for differing reasons, of course).

My motto for the Scrum Lead class: “No More Bad Scrum”.

A coworker of mine shared with me a great tool to help people know when it is time to come back from breaks during a training session - ZoomIt.  It is designed to allow you to zoom in on parts of your screen during a presentation and annotate the screen, but I find the reverse timer the best aspect of this tool.

Say you are doing a training and want to have a two minute break.  Instead of trying to synch up everyone’s watches, just use this simple tool and people can visually see how much time they have left until break is over.  I was a bit skeptical that this tool was valauble, but during a recent training engagement, I noticed I had lost a lot of time in my class waiting for people to come back from breaks.  With the addition of this simple, unobstrusive tool people came back on time from breaks.

ZoomIt is a must have for anyone who does a lot of trainings!

Just wanted to take note that Ted & I got married in a small, intimate ceremony downtown.  It was a beautiful, clear day and we are heading off to Palm Springs for a long weekend.  I am very happy today.