Scrum is fairly simple from practices point of view (and claimed to be powerful, when applied correctly). You work in timeboxed iterations with a team, Product Owner and ScrumMaster. You apply certain ceremonies (Daily Scrum, Groomings/Sprint Planning, Retrospectives, Sprint Reviews). This is added with a couple of artifacts (Product/Sprint Backlog) and continued until end of the world. Unfortunately, when this approach is only applied on a practice level, the real promise is not met. Agile values and systems thinking are vital part of Scrum introduction, even in small scale. How about when you have multiple teams and complex business environment? One of the initial questions we faced was: Does it scale and if it does how should we plan? Scaling has actually many aspects that are not evident in the early phases of any Agile transformation. We made initial team scaling exercises but missed the understanding what end-to-end flow optimization means in terms of scaling Agile (and Scrum). It is hard to understand that we should focus only on work instead of workers. If you have too static structures that do not allow self-organization, easy self-selection and self-ordering you will have a mountain to climb. In our exercise many of the issues were and are accumulated in the Product Ownership function and inspecting that provided us many vital lessons and deeper understanding.
PO structure and scaling
There are some alternatives when scaling Product Owner role. One thumb rule is that one Product Owner can handle two-three teams (when applying by-the-book Scrum). On the other hand Scrum says that there is only one PO. With these guidelines we did the following: there was one PO and a bunch of Proxy-Product Owners matching the number of teams (one PO, two teams). When considering that we had 20+ teams the amount of POs was around 15. Our aim was to have also PO team work as a real team but without boundaries and structure this was not achieved.
In practice this also lead to a situation where lack of common goals resulted to sub-optimization on enterprise level: a feature/proxy PO was driving own features to “done” and common problems were someone else`s problem. As we were facing initial transformation challenges at the same time there were a lot of impediments that needed teams attention and effort. We tried to overcome this with adding management attention, which was really hard when considering management role within Agile: to support and help, leaving responsibility to teams. We even heard comments (from external consultants) that managers are not needed in Scrum… What we did not understand was that proxies are not a tool for scaling but a shortcut for bringing the business closer to the teams. So in reality teams felt that they were left alone and too much was asked from them. A common question that time was: “should every team do and be responsible of everything?”.
Lack of common vision and goals leads to unhealthy balance within an organization. In our case this resulted to feature focused approach where product and legacy aspects where down-prioritized and often neglected. This is violating against the purpose of any organization: satisfy/delight the customer with continuous delivery of valuable software and solutions.
A good example of this challenge was when we introduced Continuous Integration: feature POs only had interest on improving the items that directly provided value for their feature. It was again someone else`s problem to put focus and business priority on the items that were connected to product or solution level. Not a very food approach in terms of “see the whole!”
When we understood that this approach was not fully working the decision was to get coaching towards the PO. I believe this was a good decision, but the coaching that was really needed was not answered. It is more important to address values and and behaviors instead of User Story writing techniques. Or learn how to work with the people instead how different items are handled in the backlog. I have asked from different organizations have they seen POs more on the operational dimension (execution) or change agents. The answer has always been on the operational side. When we realized all this we decided to apply a deeper change: introduce initial boundaries and structures into PO function to help the organization scale up and continue with the change. More of this in the next part of this series…