To speed up development we decided to work with multiple teams on one of our bigger e-commerce platform projects. We usually work with one team on an Epic or project, so this was a first for us. The switch brought up a lot of questions like; how do we deal with a combined backlog? And how do we keep the teams aligned?
At Coolblue we do not want to spend too much time on making huge plans and way-of-working documents. Therefore as product owners we thought about the questions that arose and we looked into existing frameworks for answers. Based on a framework we created an outline on how we wanted to work with the teams and decided to start working, learn quickly and change our approach if needed.
Looking into frameworks
When we looked into scaled agile frameworks we bumped into the two most used frameworks; SAFe and LeSS. When looking at both frameworks and their visual representations you will see quite a difference. SAFe has quit a more layered and detailed overview. In the SAFe overview organisational topics have been addressed which makes the total process in the overview look bigger and more complex compared to LeSS. If you look at the LeSS overview you’ll immediately see components of a very familiar framework; Scrum. LeSS looks a lot less (pun intended) complex than SAFe, but that doesn’t mean organisational topics haven’t been addressed. There’s a lot of thought put into technical and organisational topics. In the visualisation this is resembled by the drawings surrounding the visualisation of the process which all stand for organisational, technical and other topics. Since this blog isn’t about the differences between the frameworks I won’t get into it to deep. There’s loads of information widely available online, and I found this blog to be a good starting point. At Nokia they have used both SAFE and LeSS and some experiences are shared online.
Choosing a framework
We wanted to start quickly and wanted the impact on the organisation to be as low as possible and as close to Scrum as possible, since we all know our way with Scrum. Therefore we decided to use the LeSS approach as a starting point. It felt easier to implement without changing too much in the organisation since it uses a lot of SCRUM elements we are already familiar with. We adjusted the LeSS framework a little to our liking, bringing it even closer to Scrum. Summarized you could say we use the well known Scrum meetings to organize the process of working with three teams. The process looks like this.
How do we work?
Managing the backlog:
Portfolio backlog: Two product owners are involved in this specific project. Both POs are responsible for the ‘portfolio backlog’, the backlog of the whole project. Together we create the epics and define the order in which we want to pick them up. Since the project we’re working on is quite big and has some technical challenges we want to be sure our prefered order is feasible. The epics should also be clear enough to be picked up by the teams. We ensure this in the ‘portfolio backlog refinement’.
Portfolio backlog refinement: During this refinement senior developers, Scrum Masters and POs come together to ensure epics are clear enough and ready to be picked up by one of the three teams The POs explain the epics and challenge the others on possible solutions, technical impact to find out if there are any dependencies. We want teams to be able to independently pick up epics. If an epic has been discussed we know if the epic is feasible and has one or more possible solutions which will fit within the technical vision of Coolblue.
Process within teams:
Each PO is responsible for the stories on the backlog of his/her team. After the Portfolio backlog refinement, epics transfer to the individual backlog of one of the teams. Teams refine these epics and slice them into smaller user stories which on their own deliver value and mostly can be released independently.
All teams work parallel in sprints of two weeks and follow the regular Scrum way of working. Except for the demo. Since everything our teams deliver is contributing to the same big project, we demo together.
Demo together: By demoïng together we have only one moment for stakeholders to attend the demo. This is very efficient and we see the attendance going up since the stakeholders get a big update every time instead of three small updates in separate demos. We strive to demo everything but we choose per story if we want to elaborate on it or not. We have limited the amount of time we spend on the demo (timebox everything!) to keep it fast and interesting enough. During the demo questions can be asked and even after demo there’s plenty of time to elaborate on specific stories. As a result, there’s still room for discussion even though the duration of the demo is shorter than three separate demos.
Meetings beside the regular Scrum meetings:
Process review standup: To keep everybody involved in the process, POs and Scrum masters meet halfway during the sprint. During a short standup we discuss progress and sometimes issues we bump into within our teams. This way we can anticipate on what happens in the sprint within other teams and help eachother out during the second half of the sprint.
Portfolio retrospective: The portfolio retrospective is being held every two sprints. The product owners and Scrum masters come together to discuss things that went well and things that can improve with regard to Portfolio, team work, dependencies et cetera. We use this input to improve the process.
We’re now working for a couple of months with this LeSS-like framework and we’ve learned quite a lot during these months. The process I explained above is still the same. But I’ll share a couple of lessons learned so you can use them to your advantage when scaling up teams.
Clear goals: We’ve learned that discussions need to be fed with information. Communicating about your roadmap and having a clear end goal, helps teams understand the bigger picture. It enables discussions during the portfolio refinements and helps to think about solutions which are sustainable for the future.
Terminology: A funny one that keeps popping up is that we as POs, teams and stakeholders use different terminology for the same things. It happens that within the commercial teams we use a word which from a technical point of view isn’t correct. But also the teams themselves use different terminology. This causes confusion during refinements, especially when part of the team members have embraced the commercial word and other people still use the technical terms. Our biggest lesson learned is that we need to first agree on the terminology used for a subject before we start refining it. But be aware, agreeing on terminology can be time consuming!
Details: Discussing details, both functional and technical, should take place within the correct meeting. When having a portfolio refinement, technical details of the solution don’t always need to be discussed, while during a backlog refinement with the team more details can be discussed to come to a valid estimation. The tough part about this is that it’s very tempting to fall into the trap of discussing details. And there are no real rules which tell what is detailed enough. As an example; sometimes the choice of a datastore is something that needs to be discussed thoroughly during portfolio refinement because it influences our abilities in the future. In a different situation the choice of the datastore is less important and doesn’t need to be discussed during portfolio refinement because the choice won’t impact our options in the future. Then the choice of datastore can be discussed during team refinement of even during the sprint.
As you can see in these lessons learned, communication proved to be the most difficult part of working together with multiple teams on one project. Above examples are specific examples on what we encountered. But as a rule of thumb you could say you can never communicate enough. Facilitate and promote (small) discussions between teams, it enables the feeling that all teams work together on a project. Challenge each other by asking if the other team agrees with a solution or knows about the issues you bumped into. Especially when two teams are working on connected epics where both create and work on the same codebase.