Jeff Sutherland himself infected me with Scrum a year ago. We were using eXtreme Programming practices since years, and in my opinion Scrum was the ideal supplement to form an agile project management framework.
Since then we use Scrum in most of our projects in combination with eXtreme Programming and gradually certify all employees as Certified ScrumMaster. For me, Jeff has not promised too much: our customers enjoy a dramatic increase in productivity and quality. Especially the short release cycles (sprints), most often 2 weeks long, caused some excitement.
Even so, we have not always been able to fully implement Scrum together with our customers. During Jeff’s training, but also in Scrum Books by Ken Schwaber, it is always assumed, that Product Owner, Scrum Master and Team are from the same organisation. How does that fit into the working model of a service company as we are, and which roles are fulfilled by the customers and which roles are played by us? So far Scrum was not giving an answer to that.
Until now, our solution was to install the Product Owner at the customer. To us that was the consequence of the Product Owner’s responsibilities: Developing a product vision and create and prioritize the product Backlog. (Another humerous definition of a product owner was given by Henning Wolf in his session at our meet the experts: “Product Owners are like business analysts with balls“) We have then concentrated on being an expert on agile software development and provided the Team and the Scrum Master.
The challenge is to find a good Product Owner within the customer organisation – a goal that we rarely managed to reach. For this reason we created the “Product Owner Proxy”, who functioned as a Product Owner on our side and worked together with the customer to create and prioritizte the product backlog. This approach worked, but in my opinion was not “round” and here and there also problematic, because it leads to a conflict in the Product Owner Proxy role: he has to represent the customer towards the team but is also part of codecentric and has to ensure that the project is profitable.
On our meet the experts –agilität I discussed that problem as an Open Space together with customers and Scrum experts. The discussion lead to a point at which Boris Gloger took posession of the flipchart and outlined his ideas. At first I was doubting his theories, but during the discussion I realized, that he just drafted the solution to our problem:
Also in his Book Boris explains, that Scrum was simplifying when it only defined the three roles of Scrum Master, Product Owner and Team and forgot about the Manager, the customer and the user. Thus there are 3 + 3 roles in total. These new roles do not solve the conflict for Scrum as a service company, or do they?
The classic roles of Scrum are, according to Boris, all within the service company, since they are building the product. Especially the Product Owner takes on a role, that was lively discussed in the Open Space, but is just consequent in the end. He tries to generate business value – for the service company!? … but how does the customer then attain his vision and create his business value? And how does the service provider get the business information from the customer, who knows his business domain best?
Crucial fact is that the customer is providing the money for the development. That means by paying, the customer defines the value of a user story. The business input is delivered by the User, who can be recruited from the business department of the customer. In the best case, the User will be intregral part of the Team, and together they are creating the content of the Product Backlog. Alternatively, also a business analyst can be integrated into the Team, who captures the requirement from the user. In the end, Customer and Product Owner create the product vision together.
This approach has some key benefits:
- The roles Customer, User and Manager are just real, and now it is also clear which role they play in Scrum
- We can more easily implement Scrum with our customers, because we can provide the classic Scrum roles on our own, and the customer can more easily benefit from Scrum. Of course, in the not too distant future they can also implement Scrum on their own and establish the respective roles by getting coached.
- The Customer pays for business value, and by doing so can prioritize the features by using his budget.
- The Product Owner is not caught between two stools anymore.
For sure, we will continue that discussion internally, but I consider this a great expasion of the “classic” Scrum, and especially as a service company you have better and easier ways to work with your Customer – especially because there is now a Customer in Scrum