Article | 07 October 2020 | Jakub Milewski

Consultant's Corner: Scrum for Two

In this article, ProData Consultant and Scrum Master Jakub Milewski guides us through the process of creating a "scaling ready" setup with a solid foundation based on Scrum and its values that is flexible and open for cooperation.

Welcome to the Consultant’s Corner series, a blog for independent IT freelancers. Here you can find out what fellow high-end IT consultants are up to in their current or recent projects. Read about trending technologies, technological solutions and get inspiration from the freelance journey of other like-minded IT professionals.

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”, Gall’s Law

Introduction

I am a Scrum Master with seven years of experience in the role. During my professional journey as a Scrum Master I gained experience working in various contexts, and team configurations such as: single product teams, and teams being part of larger scaling efforts, distributed and colocated teams, small, medium-sized, and large organizations. What helps me to be a good Scrum Master is a curiosity about how things work and how to make them better. Right now, I serve as a Scrum Master for a team in one of the largest banks in Denmark.

Together with another team, my team is responsible for the development of services critical to the everyday work of the bank. Our domain is customers and products data as well as benefit systems. In this article, I will share with you how two Scrum teams inspired by Nexus Framework uncovered a better way of working together.

Team structure

The structure of the teams is aligned with the technology used. Over the years, the services for which our teams are responsible were developed in mainframe technology (Cobol, gen), and later in Java. Because of that, each team consists of Java, and Mainframe Developers, as well as an Architect, a Business Analyst, a Scrum Master and a Product Owner. The Product Owner, Business Analyst, and Architect share their time with both teams. Teams are small up to 6 developers. Also, we are working out of three locations in two countries - Denmark and Poland.

One year ago…

When I joined the bank one year ago, I found a team with a few years of history working together. During this time, they tried to find their way of using Scrum without any help or external guidance. It was not a surprise to me that there will be areas open to change. Here are some issues that attracted my attention at the very beginning of my journey with this particular client:

Lack of Sprint Review,
Not enough refined items in the Product Backlog,
Big focus on budgeting and counting “man days”,
Two teams working in the same domain, one overloaded with work, the other was struggling to find something to do,
Two developers (one from each team) delegated to work on maintenance tasks only during the Sprint.

Bright side was that the Development Team was (and still is) a group of smart, skilled people who seemed to be stuck with some problems. In this article, I will focus on how we changed the way we worked together in order to overcome these challenges.

Product Backlog

“There is a single Product Backlog for the entire Nexus and all of its Scrum Teams. The Product Owner is accountable for the Product Backlog, including its content, availability, and ordering.”, Nexus Guide

Creators of Scrum say Scrum is “simple to understand”, and “difficult to master”. In my current freelance assignment, we were challenged with managing two ordered lists of Product Backlog Items, one for each of the two teams. I learned that this is mainly for historical reasons which are not valid anymore. At some point, teams agreed on a split of responsibility and decided which team will own which services. It turned out that the changes needed to be done to deliver business value are mostly in scope of one team. The Product Owner was double challenged from one hand she could not meet requirements from the stakeholders, from the other hand she struggled to find any job for the second team.

It was clear that the solution for the problem had to be one Product Backlog for each team like in the Nexus Framework. It was quite easy to get support for this idea from the Product Owner. Together we saw many benefits of this, for example:

No more artificial split, and focus on what brings the most value by both teams,
maintaining one backlog is easier than two,
Better knowledge sharing between developers from two teams.

However, our Development Teams were concerned that before we move forward with this idea we have to understand:

When will we decide which team will work on which Product Backlog Item?
How should we approach estimation of the items in the Product Backlog?
How will we deal with dependencies in Sprint?

These were valid concerns. Working this out together took us some time, and triggered further improvements of how we worked. Fortunately we were not the first to struggle with such issues. We looked at Nexus Guide which turned out to be a great source of inspiration to find a good solution in our context.

Refinement

“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog”, Scrum Guide

“The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.”, Scrum Guide

Starting out on this assignment, refinement of Product Backlog Items was treated as something unimportant. Some team members thought about it as a waste of time since “everything” can be discussed during Sprint Planning. As a result, the forecast created during Sprint Planning was burdened with high uncertainty, and both teams were discovering during the Sprint that the tasks they needed to implement were much more complex than originally assumed. This caused the following problems:

Product Backlog Items leaked from one Sprint to another,
the Product Owner was challenged to make any reliable plan for releases, and communicate them with confidence,
stakeholders were disappointed about the teamwork,
in the end, all of this resulted in a lack of trust (stakeholders did not trust the Product Owner, the Product Owner did not trust the team, and even some team members did not trust their colleagues).

Seeing all of this, I started a dialogue with the Product Owner about the need for investing more time into a better understanding of work we are about to do. At first, she agreed that she would prepare the list of Product Backlog Items she sees as the focus for the next Sprint, and then send it to the team asking them to refine. We ended up in the situation of having ad-hoc meetings where we tried to understand what needed to be done. This was a step in the right direction, but we were not happy with the results. This triggered a good discussion about the way we do refinement during one of the Sprint Retrospectives I had the pleasure to facilitate. We decided that we would like to have one day in the Sprint where we will focus only on refinement.

Here is how we organize the “Refinement Day”:

In the morning Product Owner is sharing Product Backlog Items to refine to both teams (everyone is present)
After having the overview of all items, it is decided who will refine which items. We create refinement workgroups which are cross-team (we assume at this point that given item could be implemented by one of two teams)
By the end of the day we gather again, and each group present their findings to the rest
Scrum Masters help with the facilitation of that process if needed
Refinement workgroups self-organize during the day on how they will do refinement

By focusing more on refinement, we started to have more accurate forecasts after Sprint Planning. We planned our refinement on the first day of the second week of our 2-week long Sprint, which created more order, and helped with keeping focus during the Sprint (less ad-hoc meetings which distract developers during the Sprint).

Sprint Planning

“The purpose of Nexus Sprint Planning is to coordinate the activities of all Scrum Teams in a Nexus for a single Sprint. The Product Owner provides domain knowledge and guides selection and priority decisions.”, The Nexus Guide

“Once the overall work for the Nexus is understood, Nexus Sprint Planning continues with each Scrum Team performing their own separate Sprint Planning.”, The Nexus Guide

The decision about sharing one Product Backlog between two teams triggered further changes in the way we work now. We had to adapt the way we do the Sprint Planning. The Sprint Planning starts with the teams’ representatives cooperating together with the Product Owner about what we should accomplish by the end of the Sprint, which Product Backlog Items support that, and how to divide the work between two teams to minimize dependencies. After this part of Sprint Planning, each team goes ahead with its own detailed discussion about Product Backlog Items selected for the Sprint. During the second part of the Sprint Planning, the Product Owner, Business Analyst, and our Architect are available for questions. Scrum Masters support this process as facilitators.

Definition of Done (DoD)

“When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means.”, Scrum Guide

Since both teams are working on the same Product Backlog, the alignment on what it means for both of them that the Product Backlog Item is done must be reached. This was one of the key things that I helped to achieve in order to make cooperation between two teams work. The plan to reach alignment was simple:

Review Definitions of Done with both teams, and share them in common space (wiki),
prepare one version of Definition of Done, and call for comments,
discuss the aligned version of DoD with both teams during retrospectives.

During this process, we discovered that some of the things stated in previous versions of DoD were outdated, and in some cases, we interpreted them in different ways. Thanks to this, we now have the same understanding of “Done”, and we have added more points related to the quality of our solutions.

Sprint Review

We practice having one Sprint Review with both teams where we share the outcomes of the Sprint. Our Product Owner also shares the vision about the foreseeable future, with emphasis on the next Sprint. We are still improving the way our Sprint Reviews are conducted, e.g. in the area of getting better feedback from our stakeholders.

Sprint Retrospective

After the Sprint Review, there is a time to retrospect about the last Sprint. The way we are doing retrospective has evolved over time. We started by having Sprint Retrospective individually with both teams. It quickly turned out that after having one Product Backlog there are things that are worth discussing together (e.g. mentioned earlier Definition of Done). So as a next step, we decided that we will start Sprint Retrospective together with both teams with everyone present. And later we will continue separately (in a similar way we do Sprint Plannings). This worked for some time.

After dealing with initial issues related to cooperation between the teams we decided to switch the order - we start with individual teams, and then we join common events to share findings from both retrospectives and address issues related to cooperation.

Daily Scrum

Each team has its own Daily Scrum, however, we keep these events open for colleagues from the other team. This gives the opportunity to coordinate between teams during the Sprint when needed.

Summary

As you could see above the way we are working together is a matter of constant improvement. We do not follow any particular scaling approach, but when introducing new elements to our work we keep in mind that Scrum is our foundation and we look for inspiration from scaling approaches close to Scrum like Nexus. As a result, we are able to introduce a lightweight process to coordinate the efforts of two teams. Furthermore, we created a setup that I like to call “scaling ready”. We have proven it works for two teams, and if we need to grow, then we are ready to add new team(s) to this setup. Not because we invented the perfect process, but we created an environment with a strong foundation based on Scrum, its values, and open for cooperation.

None of this would be possible without the effort of the people who care about their teams, and the inspiration of a skilled Scrum Master. Knowing the history of your team, understanding why things are the way they are is key to enable positive change in your team and influence the environment in which the team operates.

Who

Jakub Milewski is a Scrum Master with more than 10 years of professional experience in IT and a solid technical background in programming and application development. With excellent practical knowledge of Agile Project Management, he is well-versed in the Agile Methods: Scrum and Kanban. He is experienced in code-reviewing, Continuous Integration tools, as well as XP practices: Test-driven Development (TDD), Pair-Programming, and Behavior Driven Development (BDD).

As a Scrum Master he has helped implement Scrum frameworks from scratch, organizing the work of the development teams in accordance with Scrum rules, managing organizational change, coaching managers and developers. Most recently he has lead multiple Scrum teams, as well as a community for Scrum Masters, and has helped implement DevOps and Product Discovery.

JM is familiar with the following technologies: Atlassian JIRA, Trello, VSTS (Visual Studio Team System), Bash, Git, SVN, Gerrit, Jenkins, Microsoft Office.

< Back to newsroom