Getting started with agile teams at scale: tip 1

1. One single backlog

Just to be clear from the outset, this blog is about when you’re dealing with more than one Scrum team. Let’s assume you’ve decided what product you are going to deliver (in an agile way), you are using Scrum as your empirical process framework and you now know you need to add to the single Scrum team that has forged the way ahead on the product.

Pretty soon you’ll get to the question of, ‘well, if we have more than one team won’t we need more than one backlog’? Wouldn’t it be sensible to think that each team will have one backlog and a product owner each?

Scaling Scrum teams – do we need more than one backlog?
Scaling Scrum teams – do we need more than one backlog?

The short answer is ‘no’. Let’s explore why.

Firstly, when scaling in a Scrum environment, the question of ‘how many backlogs?’ should be addressed from the very start – it will save you a lot of pain. Trust me.

There are many reasons why you might think having a single backlog for each team is a good thing. These may include:

  • Each team will have its own dynamic and should be empowered to deliver as independently as possible.
  • Each team needs to size and commit to things that only they are on the hook for getting to Done, as agreed with the PO.

All of these examples are relevant and very valid, particularly in one-team Scrum. However, and this is the key thing, having more than one team introduces more variability, complexity and inter-team dependencies. In fact, it introduces so much more complexity that you need fresh thinking to address multi-team Scrum.

Don’t just take my word for it; both Scrum organisations (Scrum Alliance and Scrum.Org) offer frameworks for dealing with Scrum at scale.

  • Scrum Alliance offers LeSS (Large Scale Scrum) as it’s chosen partner for scaling, which, as part of an initial set of scaling rules, recommends one backlog for each product ‘that defines all of the work to be done on the product’[1].
  • Scrum.org, with its Nexus framework advocates that ‘there is a single Product Backlog for the entire Nexus and all of its Scrum Teams’.[2]

So that’s grand – the two heavyweights of the Scrum community say you should have one backlog at scale.[3] So what? How will it help?

For me it helps on several levels.

It creates and consolidates a view that there is one product, and the items that are required to produce the product need to be prioritised within the same context for the appropriate team to build them. In the grand scheme of things this item is more valuable to the Product Owner than the next, so that is what is prioritised across the entire product (Systems Thinking in other words).

Scrum Masters may have encountered instances where some teams working on the same product with individual backlogs have prioritised lower priority product items because the backlogs are silos of functional items prioritised at the team level. That results in what Larman would call a ‘local optimisation’[4] and therefore not optimised for the system. Having one backlog for the product is a way to avoid this kind of issue.

Equally, when teams are refining backlog stories they will have a pretty good idea of which team will be picking up a given story as they get refined. If the ‘integrated increment’ (Nexus) is to be fully integrated and delivered by multiple teams, they need to understand any dependencies and co-ordinating activities that should happen during the two-week sprint. They have an opportunity to call this out in the cross-team planning session or, Planning One (LeSS) and Nexus Sprint Planning (Nexus).

Of course, having to integrate the code on a regular basis will reinforce the team dependencies and equally, Scrum Masters working across the teams will also enhance the co-ordination (at least this is how the LeSS framework does it).

Most importantly, there is a flow gain from the approach. As the teams are multi-skilled non-component based functional teams, we can reduce variability and increase flow ‘because a user story can flow to any one of several available teams.’[5]

Questions about sizing are really red herrings in this debate. It really is not the point here. The point is cross team collaboration/co-ordination, flow at scale and prioritisation of more valuable items in a scaled environment. One rule however, should be that team velocity is not compared in this approach. Furthermore you can add a short cross-team refinement session where items are sized by representatives from each of the teams, before being more fully refined by the team most likely to take the item on in the sprints.

Neither does the multiple Scrum team approach devalue the ‘empowered teams’ Scrum philosophy. There is nothing different here – they are still Scrum teams, however they now have sight of what other feature teams in the system are working on and can plan and agree inter-team product dependencies accordingly.

So, in summary, the tip for this month is have one backlog for each broad and wide product. How you plan for that also needs some adaption to single team Scrum ceremonies – but more about that next time…

Featured Post

Scaling agile: What can I do before adding more people / cost?

When scaling agile, it’s important to keep front of mind that we are spending other people’s money. We should always think about delivering value for money from outset and be transparent with ourselves and stakeholders about Value. A sponsor will ask the questions “Are we getting value for money?” and/or “Can’t we go faster?”. These are legitimate challenges and as responsible professionals we need to have explored the options before adding more people and therefore cost.

So before you add people, what can you do to deliver more, faster?

To get to an effective delivery, here are the things I look at. After the first point, they are in no particular order as the priority will differ depending on the circumstances. I’m assuming there’s already a team in place and they’re already delivering.

Culture – Is there an open, supportive, learning culture?

If this isn’t in place, your team is neither as efficient or effective as it can be. Even hints of a closed, niggly culture will mean people are not looking to learn and motivation / productivity will wither.

What’s worse is that scaling even a mediocre culture will exaggerate the flaws exponentially and the negative traits will overwhelm anything positive. Your good people will leave, your initiative will start to fail.

User stories – Are your stories really ready to be played?

Particularly in the early days of delivery, there’s a tendency to underestimate the level of information needed to write the code and tests that deliver a user story.  The concept of a user story being the “invitation to a conversation” can also be used as an excuse for not writing down the key aspects of delivering a feature.

The dialogue triggered by writing acceptance criteria, producing designs, estimating, defining performance is critical to both effective and efficient delivery.

So create a “definition of ready”, make sure that all your stories meet it before they are played.  Then improve it as part of your regular retrospectives; there’s no such thing as a perfect story.

Prioritisation – Are you really working on the right things in the right order?

This is an interesting one as the simplistic Agile mantra is that you should be always working on the most valuable feature to the organisation at any time.  In theory this is focusing on being effective, however this mantra can drive inefficiencies.

From the perspective of a user,  there will often be groups of features that only make sense to deliver together or in a specific delivery order.  From a technical perspective there are usually a set of foundations that are better to be in place early to limit the amount of refactoring that would have to be done if they are implemented later.  In both cases the high value features might be more efficiently delivered later.

As usual, the key here is balance.  Use the high value features as a goal or mission and recognise that putting some foundations in place are important to minimise “throw away” work.  This requires careful facilitation of business, delivery and technical perspectives.

Frameworks – Have you got the right frameworks in place?

This is a relatively obvious one.  In any software delivery many of the concepts will have already been delivered by someone else as reusable components, creating these again is wasteful.  Most of the common ones will be already available in e.g. .NET and Java frameworks.

For the new features that you are developing, if you find common patterns build them into the frameworks so that the next time they are needed development is accelerated.

For a one team delivery switching technical framewoks might be managble, however once you have many teams there is a massive switching cost.

As part of your Discovery / Foundations, pick a framework that works for your product, stick to it and extend it as necessary.  Avoid mixing or switching  frameworks as this generates confusion and context switching.

This goes a little against the concept of emergent architecture but again balance / pragmatism is important.

Environments – Is your build, test and deploy pipeline mature?

Again this might seem like an obvious one but every large programme I’ve seen has problems getting continuous integration and continuous delivery sorted, mainly because it is complex and there are important (but unexciting) operational aspects, such as security, logging, audit, user support, back-up and recovery to get right.

There’s little more frustrating for delivery people than being able to demonstrate code to users that want to use it but can’t.  It’s one of those foundations mentioned earlier, you have to get your build and deploy pipeline in place before you can deliver working code.  In extremis, stop writing code and send everyone not involved in generating it on holiday until your pipeline works.

“Right-plating” – Do you have an appropriate definition of done for the product / service you are delivering?

In the drive to get software live, particularly for an alpha or pilot, it is very tempting to cut corners in non-functional and operational acceptance testing.  Conversely an operations function, typically coming from an ITIL mindset, will typically look to over-document from habit and training.

The phrase “an appropriate level of rigour” is key here.

Your definition of done must include non-functional requirements such as maintainability, performance and security, but have you created a cottage industry of operational acceptance documentation?  Can you automate production of the documentation that is really needed?

Delivery Organisation / Process –  Are you set up the right way for your product / service ?

Adhering evangelically to just one Agile/Lean methodology is a recipe for poor productivity.  The core of Agile is the same in all methods but, for anything other than the simplest deliveries, you need lean principles, the software engineering disciplines of XP, the management disciplines of DSDM, the focus on culture in Scrum.  The blend will depend on your circumstances but you will need some of all of them.  Note you don’t need SAFe at this stage (if at all)

Make sure the team completely focussed on delivery.  Minimise the number of people that are not dedicated to the team and make sure that when they are with the team they are not distracted by their other responsibilities.  This is particularly true of Product Owners given their key role in delivery.  I think that PO’s having some operational contact is good, as they stay up to date with the current user journeys and needs, the issues come when they are still responsible for operations because a business-as-usual problem can completely de-rail delivery.

Develop and maintain a disciplined rhythm

Context switching ruins productivity.  Unregulated feedback is just noise.

The issue is that a delivery team cannot just focus on the current context i.e. the next one or two sprints.  The team has to also listen to and act on feedback from users and users need a forward view of what will be delivered when so that they can plan business change.  At a minimum, key members of the team, such as the Product Owner and Tech Lead, need to be in all these conversations, ideally you want everyone to contribute.

To minimise the productivity hit of context switching, each context needs its own forum, these forums need to be prepared and run well and everyone, particularly senior stakeholders, need to understand where their input contributes rather than generating noise.  See Davina’s blog on setting an analysis rhythm to see what we mean by this in a practical way.

Governance

As we are spending someone else’s money, some governance is needed but excessive bureaucracy is not.  Effective decision making, particularly about spending, is critical to efficient delivery.

Talk to the sponsor about applying the GDS governance principles:

  1. Don’t slow down delivery
  2. Decisions when they’re needed, at the right level
  3. Do it with the right people
  4. Go see for yourself
  5. Only do it if it adds value
  6. Trust and verify

Make sure that your team can be trusted by them “demonstrating control”.  By this I mean that are transparently demonstrating full Agile disciplines and are able to evidence that they are spending the budget wisely.  If you are trustworthy you will be trusted.

Capability – Do you have people with the right skills, attitude and experience?

This an area that many Agilists find difficult because they believe, as I do, that the retrospective prime directive applies in nearly all cases; no-one sets out to do a bad job and everyone is doing the best they can in their circumstances.

However this can’t gloss over the fact that there are some people who are more productive in their role than others.  It is also a fact that many good delivery people dislike “free-riders” who tend to be productivity hoovers and an organisation tolerating this will tend to lose good people to those that don’t.

A brutal hire and fire culture also kills productivity, so a balance has to be struck.

My balance on this is that if you have a weaker member of the team who acknowledges that they need to learn, they should be given the opportunity and encouragement to do so.  If they don’t recognise it or aren’t prepared to learn then they need to be managed out.

For me attitude to feedback and willingness to learn is key for both contractors and permanent staff but clearly the level of tolerance of poor productivity should be lower for contractors.

In all circumstances as a leader in Agile delivery you have to be actively monitoring and managing the capability of the team.  All the research into the success or failure of programmes and projects, no matter which methodology is used, highlights that the key success factor is good people.

Do the hard work at the beginning to get the right people with the right attitude.  Make sure that your hiring processes is rigorous and repeatable. Get candidates to prove their skills at interview through relevant exercises e.g. you want to see developers code and user researchers electing feedback from users.

Scale to make the organisation resilient and able to manage the complexities.
Scale to make the organisation resilient and able to manage the complexities.

Mature the first team first, then add people

So in summary make sure that your first team is optimal before adding to it. You may find that you don’t need another one.

If you do need more than one team, getting the first one productive first means you have also defined what “good” looks like in your context and can scale with some confidence.

Thanks to my colleagues Praveen Karadiguddi, Ciaran Ryan, Rudiger Wolf, Davina Sirisena and Hugh Ivory for feedback on the draft.

Featured Post

Why scale agile?

I’ve just googled why scale agile. All the higher ranked entries focus on “how” and “what” of scaling agile and are typically trying to sell SAF – highlighting the marketing genius that is Dean Leffingwell.

The highest ranked answer that is relevant is a 3-part blog from “Adventures with Agile” that is erudite but doesn’t really answer the question. For balance, my last public foray into this topic, with the GDS governance team, wasn’t as simple and to the point as it could have been either.

So, let me be as clear and as simple as possible:

Why scale agile? To deliver more (product) faster.  

This is the primary answer, if you can deliver the outcome you are looking for with one team in an acceptable timescale then you don’t need to scale. Even if you can’t deliver the outcome in the timescales, throwing more people at the problem won’t necessarily reduce the time to deliver but will increase cost, probably significantly.

Why scale agile? To transform the organisation.

The secondary answer to the question, to fully transform the organisation’s ways of working, follows on from the first because you won’t be able to transform into a digital/agile/lean organisation without proving that Agile is the only way to achieve their strategic aims, it delivers significant benefits and Agile delivers in their context.

This is the first in a series of blog entries on practical scaling of Digital/Agile initiatives based on the author’s experience of running and coaching large Agile programmes in both the public and private sectors. Take a look at the second:

Scaling Agile: What can I do before adding more people / teams / cost?

 

Featured Post