Just to be clear from the outset, this blog is about when you are 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?

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…

Thanks to Stephen Blackmore for taking time out to encourage, advise and contribute to this blog.

[1] https://less.works/less/framework/product-backlog.html

[2] Nexus Guide: Scrum.org 2015

[3] Note: Nexus recommends scaling with more than two teams. LeSS suggests you scale as soon as you have more than one team.

[4] https://less.works/less/principles/systems-thinking.html

[5] Scaling Lean and Agile Development; Larman and Vodde, Addison Wesley, 2008.

See their blog here

UX Camp Brighton is an ‘unconference’ for anyone involved or interested in user experience design, user research, interaction design, information architecture, usability, accessibility and other associated fields.

Attendees either run or participate in 20 minute sessions, such as talks, demos or discussions. No headliners, no product pitches, just a friendly (if intense) event focused on sharing, socialising and learning new stuff.

UX Camp Brighton 2017 will take place on Saturday 25 March 10am-10pm at The Skiff.

More information

Book tickets

Agile Women UK is a place for women working in agile environments to share success stories, challenges and opportunities.

Let’s get together regularly and swap ideas with other women who work in similar roles and can relate to shared experience.

Our first event was held at the Groucho Club with great feedback, there will be more to come very soon.

More information

It is 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 am assuming that there is already a team in place and they are 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 are rigourous 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.

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.

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:

… 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.

… 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.  For the others see the following links

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

Agile is more than a set of methods, practices and behaviours. Agile is an enabler for transforming organisations, as relevant in the public sector as it is in the lean start-up.

Agile transformation requires new approaches across a number of dimensions:
• Delivery (engineering): where the push for Agile normally starts, from practitioners influenced by education, social media, peers, pragmatism.
• Governance (management): once the delivery teams start doing things differently, ways of governing and assuring are challenged to remain fit for purpose
• Organisation (culture): the changes being driven from the Delivery and Governance dimensions will highlight issues with our organisation’s culture which need to be understood and addressed

Those of you in Delivery Teams using Agile to build products and services, will often feel frustrated, hamstrung by the mechanisms and structures that delay your progress. You should realise that the leaders in your organisation want the same thing as you – delivery of value early and often. They just want to protect their investment, and they look for assurance about that. You can help by explaining how iterative and incremental delivery, with frequent demonstration of product, protects their investment. Providing easy access to your information radiators, and inviting them to visit you often will help.

Those of you in Leadership positions want your organisations to be agile and adaptive, to react to the forces of change – reduced budgets, new legislation, and better informed customer and citizen needs. You may be frustrated by the pace and cost of change. You will be concerned about the risk of wasted investment, and the consequences of that in terms of investor, regulator and media scrutiny. So you look for assurance and appropriate governance to safeguard your investment. If you have good Agile delivery teams, their very approach is safeguarding your investment. They will ask you to empower your best, most visionary people to work with them to deliver what you really need. They will ask for time to explore, make mistakes, learn. They will ask for your patience – don’t expect the false certainty of a two year plan – let them know your desired outcome, give them space to figure it out. Visit them as often as you can – they’ll welcome you.

Those of you responsible for governing and assuring are caught in the middle of this drive for agility and adaptability. You are expected to be the brokers between the Sponsors and the Delivery Teams,
facilitating the means for ensuring that money is invested appropriately, and is being used effectively.
You will need to create the conditions whereby leaders can
• make decisions about the most important things to do
• allocate skilled, knowledgeable and empowered people to the delivery teams
• come and see the progress for themselves
Delivery teams will expect that the information they generate as they work should be sufficient to demonstrate progress and control.
And everyone will expect you to ensure that governance approaches add value and don’t slow down delivery (easy so).

In a nutshell, the potential for Agile to enable organisational transformation can only be fully realised when all of you (Leaders, Managers and Delivery Teams) align your behaviours as you mature from focusing on the Delivery dimension (using Agile practices to deliver a specific product or service) through to the Organisation dimension (harnessing agility to create an adaptive, learning evolving organisation). A challenging journey, but the potential rewards are great.

Ten years ago today the initial Beta of the National Packaging Waste Database (NPWD) went live for the first time.  It was a collaboration between the Packaging Federation, the Environment Agency (EA) and Oxford based software house Solution 7.  The beta was a ranging success with over 80% uptake and reducing the time to produce the key Q1 numbers by 6 weeks.  The full case study is here.

It was my first full cycle Agile project management gig and Ben Bradshaw’s endorsement of it in Parliament, “an unusual piece of government IT in that has been successfully delivered on-time and to budget”, still fills me with pride. What we didn’t know in 2006 is that NPWD would align so closely to Digital by Default (DbD) to the point of being a pre-cursor for it.

The key principle behind Digital by Default, focus on the user need, was at the heart of the project and the resultant service.  NPWD manages the evidence of recycling of packing waste and was initiated by, and largely directly paid for, by the industry users that had to prove that they had met their recycling obligations.  Users, both industry and EA, were represented on the board and the project team consulted with recyclers, exporters, compliance schemes, the regulators and the producers on every feature delivered.

DbD services must also be transformational.  NPWD was born out of the need to move away from a paper based process that was regularly the subject of fraud (the evidence of recycling was, almost literally, a blank cheque), requiring significant changes in the regulations e.g. moving to password based “electronic signatures” which were very radical at the time.

NPWD is still going strong; industry users rebelled against its planned replacement last year for not meeting their needs and being too expensive: the EA costs for running regimes like this are passed on to those being regulated.

At the time, we did an informal Digital by Default service assessment, NPWD came out quite well.  The only points where it might have failed is on the use of open source technology, as it uses MS .NET and SQL Server, use of GDS design patterns, as they didn’t exist at the time, and possibly point 12 about service that simple and intuitive enough so users can complete first time.   Our point here was that to make it simpler would need a change in the underpinning EU regulations and the users are professional and have to understand the regime.

Looking back to 2006, there were other pockets of what is now seen as good digital practice emerging across government at e.g. DVLA and Companies House.

So UK Government Digital is at least 10 years old.  When its history is written, as it surely will be, which will be the first service that could have been classed as DbD?  Was it the National Packaging Waste Database?  Perhaps we could generate a candidate list in the comments and ask the now sadly departed GDS visionary team to judge.