Search
  • alper gurbuz

Scaling Tips


I find one of the hardest but most fun and challenging part of Scrum is the scaling. When it comes to how multiple teams need to work on a single product things start getting messy. There are many scaling approaches and practises out in the market but as always you can create your own or adapt the known frameworks to your own organisation. I like using Nexus & LeSS with some Kanban practises so far but implementation and challenges have never been the same for me.



Challenges and some tips I think of:


Dealing with the beast - Dependencies: One of the most difficult dependency to deal with is the dependency on scarce people. Pressure from business doesn't allow teams to always invest on spreading the know-how to manage this risk unfortunately. Other dependencies such as integration, working on the same code base, common Database etc are also some of the well known dependencies to deal with. Exploiting a Kanban board to make such dependencies visible can help you to find out what you need to do and when by whom. Transparency will allow you to inspect and adapt (empiricism).


More transparent Backlog Management: This can be a hard cookie when it comes to scaling. Again one remedy is to make your portfolio/refinement flow transparent . If your backlog is at an excel or a tool, it is highly possible that you will hard to get your head around which items to refine when by whom and you might struggle with optimising the flow, planning and so on. So I highly recommend you to make your backlog transparent to collaborate over it. Transparency can again allow you to address what kind of feedback loops or/and refinement activities, decisions you need with the pre-mature items in your backlog.




Multi level physical board showing up- stream work as well as the work in progress





It takes two to tango : Joint planning , review, retrospective meetings are quite common in scaled frameworks. Difficulty is the facilitation. In such meetings, if you open up an excel file and start going through it with such high number of people, you are likely to lose people's interest and curiosity within a very short time. Use post its, create an environment for collaboration, maybe create sub teams for parallel sessions in the room who might share their outputs with others later on. Facilitation is a key success factor here.


Roles: Who is going to be "The Product Owner". PO role is already a difficult role to fill in in a single team Scrum. In scaled Scrum this difficulty usually gets amplified. Some organisations have the right single person for that role but most I've worked for struggles with it. Power wars to become the final decision maker on the backlog can sometimes get fierce. We approached to this problem by creating backlog committees(still with one PO at the centre of the committee) that collaborate more often and work on a transparent backlog with clear goals to order the backlog and open space for and speed up team refinements. This committee model nicely work for some organisations but not for some. It may not be the ideal but it is one of the options you can experiment. To reiterate those committees need clear policies, transparent backlogs and some objectives (such as reduced "Customer Lead Time") to become effective I reckon.


Portfolio Thingy: Large enterprises and maybe even smaller organisations tend to work through a portfolio of projects that are aligned with the strategy. Portfolio gets created annually or quarterly what so ever. Quarterly portfolio planning seems to be more Agile. A portfolio initiative usually need more than one team to work on it. Lots of different teams depending each other can be a nightmare. This becomes an optimisation problem. When managers retain a utilisation anxiety, the road gets quickly jammed. Then you need a policeman to open up the traffic , i.e work by escalations and politics. There are few things that we did successfully to overcome some of these challenges. Creating a portfolio team to order items without focusing on sub-optimisation can jump start you. That team need to collaborate more often - maybe have their own Kanban board too-, a cadence to meet for feedback, can have their own metrics and so on. They need to be accountable for the ordering and can ensure not too many projects start at the same time. Limiting WIP at portfolio level can greatly increase your Enterprise level throughput and higher chance to deliver greater value. Having an all teams planning, review can also help. Something like a lighter SAFe PI planning event - I am not in favour of multiple sprint planning in such big room planning events.



Experience I have with these meetings is they are great, can be very effective if well prepared. If you can have your all decision makers there, such fast decisions are incredibly valuable and priceless. On the left you see a draft, ordered, short listed enterprise backlog for the whole IT organisation.





A board template we used for a big room planning event we facilitated is at the right.






Frameworks/Methods: Nexus proposes a centralised integration team to focus on integration tasks unlike LeSS which leaves that to the teams. Both approach have advantages or disadvantages. LeSS might require more maturity and better self organisation capabilities. You can try both, I don't think there is a huge difference. I like the refinement structure in LeSS - separate overall refinement and team refinements. Nexus sandwich model retrospective can be quite exhausting - try your self. About SAFe, I don't have much experience but I am using some practises of it such as PI planning (much diluted version without Sprint planning), WSJF to quantify expected value etc. Although I see the underlying reason why some organisations prefer such a defined framework, I am not yet convinced with it. I need to explore it further.


Portfolio Kanban: Pretty much all 6 practises of Kanban can be used when you scale Scrum. Limiting WIP at portfolio level, visualising work, making your portfolio level policies explicit, managing your flow particularly at upstream, and improving using portfolio metrics is a great use of Kanban at portfolio level. Some examples are already mentioned earlier in this blog.


There is much more to share about scaling as it is a very deep and broad subject. I might write a second blog about it in the future. Hope this helps for the time being.

4 views