You know how it goes: the consultants turn up with the new team structure, based on that thing the music streaming startup did that one time, over a decade ago. They reorg everyone into interchangeable ‘squads’ or ‘crews’ of 7±2 people, and tell them they are all in an agile value stream now.
To ‘scale’ these cookie-cutter teams you simply gather a few of them into a programme team, tell them all to work the same way, slice up the work and then give them a list of items to deliver by the end of the quarter.
Or maybe not.
Beyond the cookie cutter
At , we know that this approach does not work. Or rather, that it can only work if all the delivery work is the same—and happens to fit the profile of the teams—so that any team can pick up any work, and if the type of work does not change—so the same teams can be doing the same kind of work in a year’s time.
Your organization is not like that. You have a whole mix of business processes, applications and vendor products, even within the same department. Some require deep domain or technical knowledge, others involve arcane legacy technologies. Only a handful of people know how they work. Some are five-9s business critical, some can be down for days with no one noticing. Some are only needed at month-end or year-end, but they absolutely have to run.
Then alongside new product development is all the boring-but-critical work to ‘keep the lights on’: security reviews and updates; reporting and audit; hardware and software maintenance; platform and product upgrades; ad hoc business queries and data processing; incident response and follow-up.
None of this seems to fit the brave new world.
Start where you are
Your organization structure may not even be the bottleneck, so a reorg is hardly going to improve things! So where should you start?
There is surely nothing quite so useless as doing with great efficiency what should not be done at all.
— Peter Drucker
Often, small changes can have a big payoff if you know where to look, so we ‘seek first to understand’. We listen, observe and measure before proposing any changes.
Here are some examples, based on real case studies, that show the impact of starting in the right place.
Getting 90 people facing the same way
How can we ensure all the work is aligned across a business-critical programme of 12 teams?
The web and mobile teams for a major retailer had grown to 90 people and their work was fragmenting. They were critical to the success of a £10bn business which now had 40% of its revenue coming through these digital channels!
The initial challenge was that no one knew what was going on, with a dozen teams doing different things in different ways. No one knew who was working on what or where the work was getting stuck.
When we arrived, the teams were sure we would tell them all to work the same way, but we did not. Instead, we said to carry on doing whatever works for you!
We just asked each team to report three metrics every fortnight: how long did each completed work item take; how many items did you finish; and how many are you working on right now? These are the flow metrics of lead time, throughput and work-in-process respectively.
We did not even specify what a ‘work item’ was! Each team decided for themselves; a work item for a mobile app team was likely to be different from that of a platform service team.
This data, along with asking what each team was working on, provided a consistent programme-level dashboard that they could start using to make decisions. Only then were they ready to take on programme-scale prioritization and planning, which is what we did next.
Doubling throughput, twice
How can 400 people go faster, deliver more, without new investment?
A large bank had rolled out a cookie-cutter scaling framework for 400 people across two sites. In one location, everything was going fine. In the other, the delivery rate had tanked, morale was low, key systems were at risk. What was going wrong?
We started with two days of Initial Assessment, to listen to people and understand their context. We learned that the teams in one location were working on greenfield applications that any of the teams could pick up. In the other location, there were dozens of legacy systems, with decades of technologies, data models, business rules and other quirks.
They had been arranged into ‘feature teams’, so the key people who understood these systems were now in arbitrary teams, each with its own backlog of work. For any work that needed specialist knowledge, the team would be blocked, waiting on a specialist in another team. Meanwhile that team would also be blocked, waiting on a different specialist, and so on. They had built an elaborate deadlock of key knowledge! No wonder nothing was getting done.
To rectify this, we identified the likely work for the next few quarters and used this to run a Demand-Led Planning session for each of three programme teams of 60-80 people, in which they self-organized around the anticipated demand. This meant that the key people were in the right places so they could transfer critical knowledge to other team members.
Get in touch and we can explore how to work together