At the GOTO Berlin 2015 conference Stefan Roock talked about agile scaling without blueprints. InfoQ interviewed him about adding XP practices to Scrum, why using an agile framework as a blueprint for designing the organization is a premature optimization and why culture and principles are more important than practices when scaling agile. Roock also explains the agile scaling cycle and provides examples showing how it can be used, and talks about the benefits and pitfalls of this approach for agile scaling.
InfoQ: You talked about using Scrum together with XP at mobile.de. What was the benefit of adding XP practices?
Roock: In the beginning mobile.de was able to release once a month. That was sufficient for their way of working before Scrum. With more than 10 parallel Scrum teams the monthly release became a bottleneck. It was managed by organizing merge slots - predefined times per team when the team had the opportunity to merge their contributions into the release candidate.
Every team would try to put as much features as possible into the monthly release and therefore strife for a late merge slot. And of course unforeseen problems with merging occurred so that the merge would exceed the merge slots. We had arguments every now and then on what to do in such cases:
- Should we remove the team causing the problem from the release so that subsequent merge slot planning would stay intact.
- Should we allow the team to extend its merge slot and if so: Should we postpone the release until every team has merged successfully or should we remove the teams with the late merge slots from the release.
There was a release manager in charge of managing all this stuff.
Shortly after introducing Scrum we focused on Continuous Integration and automated tests (Unit Tests and UI Tests). That led to higher quality and less overhead. The teams made less use of branching and merge efforts dropped down dramatically. The merge hell disappeared and the role of the release manager became obsolete.
In parallel mobile.de started to use TDD, ATDD and Pair Programming.
Today mobile.de is able to release several times per day if neccessary. mobile.de developers have documented some of their experiences at the ebay dev blog.
InfoQ: You stated that using an agile framework as a blueprint for designing the organization is a premature optimization. Can you explain this?
Roock: In my experience there is a difference between a blueprint / framework in the small and in the large. Scrum is a kind of blueprint and it works. It helps people to make their first steps and gives guidelines while understanding what agile is and means.
When people have adopted the agile mindset they will come up with their own scaling approach. It will emerge iterative from practice - the team would inspect & adapt its way to the structure.
A scaling blueprint pre defines this structure. But what for? A mature agile team doesn’t need it and would be constrained unnecessarily. And an agile beginner team shouldn’t start scaling agile. They have to learn to walk before they can run.
InfoQ: Do you have examples of people doing practices without understanding the principles behind them?
Roock: In one of my Product Owner trainings I once had a participant who said he had several years of experience with agile. When we talked about the Product Backlog he asked about tool support. They had used Excel but had to resign it since the number of rows were exceeded. It turned out that the company did something very un-agile and put Scrum labels on the parts. The participant learned "Scrum" in the company and believed that he was really experienced with Scrum.
Another very common thing is the Sprint Review. 80% of my training participants use the Sprint Review as a approval meeting: did we do what we had planned? Only very few companies use the Sprint Review for discussing the return of investment (ROI) of the Sprint and gather feedback to improve the product.
And when I am invited to assess a Scrum implementation the Daily Scrum is almost every time a boring status meeting and not the intended high energy team building and planning event.
InfoQ: Can you elaborate why you consider culture and principles to be important than practices when scaling agile?
Roock: All agile approaches are very lightweight. There are only few rules, roles, meetings etc. That leaves a lot of room for adapting to the situation at hand as well as for improvement. And it leaves a lot of room for mistakes.
Without adopting the culture and principles of agile people with mistake agile practices. They will interpret the practices with their existing frame of reference. The Product Backlog will be seen as just another form of requirements specification document. The Sprint Review will be used as an approval meeting. The Daily Scrum will be used status reporting. The Scrum Master will act as a project manager and the Product Owner will be a kind of bureaucrat who asks stakeholders for requirements.
The agile principles help to detect these mistakes.
"Welcome changing requirements, even late in development." tells us that a fixed "Product Backlog" is definitely not in sync with agile thinking.
"The best architectures, requirements, and designs emerge from self-organizing teams." tells us that there is something wrong with just asking stakeholders for their requirements.
For scaling there are some aspects where it is not obvious how to apply the agile manifesto. Therefore some coaches including me set up scaling principles (see http://scaledprinciples.org). These are not really new inventions but just a collecting of existing principles with a focus on scaling.
InfoQ: Can you describe the steps in the agile scaling cycle? Why do you propose these steps in this order?
Roock: The Agile Scaling Cycle is a simple three-step cyclic model. In the first step we reduce dependencies between teams. Autonomous teams are a high good in agile. Then teams have to coordinate with respect to the remaining dependencies. During the work organizational dysfunctions will become visible and the Scrum Masters of the teams won’t be able to remove every dysfunctions (some might need reorganizations of the company). Scrum Masters would find a work around for their current situation and the underlying organizational dysfunction would be addressed in step three: develop the organization.
This model emerged during an agile scaling training that I gave together with Peter Beck. We asked the participants to write scaling practices that they know of on post its. While we observed the participants writing we realized that there would be an immense output and we would need a structure to organize the practices. We found three clusters: reducing dependencies, coordinating teams, developing the organization. These clusters seemed to be useful and we started to use them in presentations and after some time the Name "Agile Scaling Cycle" emerged.
As every other model the Agile Scaling Cycle is wrong. But sometimes it is useful. The Agile Scaling Cycle is useful to cluster scaling practices and it is useful to focus on two important points:
- Autonomous teams are important.
- Improving the organization with inspect & adapt is inevitable.
Where the Agile Scaling Cycle is wrong is the sequence. In fact every three steps are done in parallel. You wouldn’t work for months in step 2 (coordinate teams), then stop working and then go with a large batch of organizational dysfunctions to step 3.
InfoQ: Do you have examples which show how organizations can use this agile scaling cycle?
Roock: We are often asked to "repair" agile implementations with multiple teams. The number one problem clients mention is planning and coordination of teams. Therefore they are searching for more powerful planning and coordination practices.
In these situations with start with step 1 of the Agile Scaling Cycle: Reducing dependencies. In almost every case the problems disappear after real cross-functional teams were created.
The second aspect is related to step 3 of the Agile Scaling Cycle. Companies have to realize that there needs to be a continuous improvement process not only on the team level. We try to establish this understanding by our coaching.
InfoQ: What are the benefits and pitfalls of the agile scaling cycle?
Roock: One benefit is that you don’t need to start with the perfect structure. I like LeSS very much but it might be to hard for companies to install LeSS completely from day one. The Agile Scaling Cycle tells us to work hard to reduce dependencies and then work with the remaining dependencies. The problematic dependencies with become visible and can be addressed then.
One pitfall is that one could misunderstand the Agile Scaling Cycle as a sequential process and postpone the removal of organizational dysfunctions. Another pitfall is that it needs experience to choose the appropriate practices for dependency reduction and team coordination. And of course people could be tempted to use a much scaling practices as possible - just to be sure. Therefore I created "Stefans Agile Scaling Maturity Model": the number of coordination practices you don’t need (any longer). Less is more.