Change. Chapter 7. Defining the scope for change: Building Real Teams

Back to contents

“The reasons why people believe that they need large numbers of bodies as though this was a ‘digging a ditch’ problem, are based upon a flawed understanding of the nature of software development and people as non-linear systems”

Craig Larman co-creator of Large Scale Scrum (LeSS) at an AWA meetup February 15th 2015

Back in 2013, I posed the question ‘how do we scale agility?’.

The answer to this question took me (and AWA) through a winding journey of discovery both about organisations and how people work together. What has become obvious over the last 8 years of helping hundreds of organisations move towards better ways of working is that it is not about scaling agile.

The best results come from creating teams that are able to work on problems with little dependencies with the rest of the organisation. In other words, the best results come from descaling the organisation — not scaling agile.

What not to do

“It’s a trap!” — Admiral Ackbar

When looking to implement agility across an organisation, it seems to be the norm to start with software development teams and make them all do Scrum or SAFe. This is a beginner’s mistake. I can understand why this happens; it is the same sort of rookie behaviour that makes me wince when I still find development teams who do not test first.

It happens because the people who make the decisions on what to implement usually do not have the Agile Mindset beliefs (see earlier chapters), or in other words, they have absolutely no training or background in complexity, organisational design, people development, or successful change programs.

This is a tragedy. It costs millions in lost opportunities as well as goodwill and training costs.

According to 5 different sources, around 70% of agile transformations fail. (Gartner group, McKinsey, Bain, IBM, and HBR).

The top 3 reasons for this failure are: Incorrect leadership style, lack of Agile Mindset, and organisational silos (Business Agility Institute).

I would argue that organisational silos are a historical effect of the first two: Incorrect leadership styles and lack of the Agile Mindset beliefs.

The playbook specifically starts with the customer (pressure from market) and then leadership. Do not start including other people until leaders are fully aligned on the business problem, the Agile Mindset, and a People-First approach. This is my biggest warning and takeaway of the book!

Start with the leadership team

This is the scope of change at the outset. Start with only the leadership team and work outwards. Leadership is covered in the chapter of the same name.

Including others

You are ready to include others when your leadership team have already adjusted their behaviours and not just their understanding. Understanding people and agility is easy, living it requires more work.

It is not enough to install a framework. The leadership must first change their behaviours and then they will be ready to include others. This chapter is about including others and defining who should be included and when. First, let’s look at what our ideal starting position is.

Target size for the real team

Your organisation most likely has a lot more people in it than can actually work together as a cross-functional team. Instead of trying to defy the laws of human capability and asking people to work closely with more than 150 people, we must reduce the team size to less than about 150 people. My personal favourite size of a team is about 80 people.

This is what descaling the organisation means. It is reducing the number of people that are required to deliver something useful and getting them to work together in the same team.

The process of descaling

Many years ago, when I used to teach agility foundations, there were teams who could not believe that their complex work could be split into stories that were less than 3 days of one person’s work effort. Most organisations at that time were working on large pieces of work that were several weeks long or more.

Nowadays, splitting product development work into smaller chunks is well documented. We have helped hundreds of teams to transition to smaller work items with a variety of different techniques depending on the type of work. It is now reasonably trivial to break work into smaller valuable deliverable items. If your teams are struggling with this, get in touch and we can organise a workshop for you.

I now find myself in the same position years later, but instead of talking about work, we are talking about organisational structure. You may be thinking the same thing as those early teams; that organisations can’t be broken down into smaller chunks. I am here to tell you that they can. You just need to know how.

A team is a building block in organisation design. Each team is an entrepreneurial unit.

I have defined the team as if we are in an idealised world. In practice, we often only get part of the way. This is an important point. We cannot use theoretical teams. We must build teams from real people and often we have constraints that don’t allow us to create the perfect team as defined here.

The theoretical Real Team is our guiding light of perfection. We experiment and iterate towards it using the Playbook.

The REAL team

A Real Team has some important attributes that may differ from your team or how your organisation considers teams. Remember, this is a theoretical ideal.

  • Teams should not be larger than 150 and preferably a maximum of 80.
  • The team has a common purpose and business outcome.
  • A team has one and only one Product Backlog and one Entrepreneurial Product Owner.
  • A team always speaks directly to the stakeholders/customers.
  • They rely on each other to succeed.
  • They work on items together, rather than each person having an item each.
  • They are able to collaborate, sense, sense-make, and innovate together.
  • They iteratively deliver value to, and receive feedback from customers, so that they are able to take feedback into consideration when prioritising the next iteration’s work.
  • They have the necessary skills and tools mastery to do their job.
  • They have little or no dependency on other teams. Teams should contain everyone that is required to deliver the product or service. This includes marketing, sales, legal, compliance, and finance.
  • The whole team meets together at least once a month for a retrospective.

This is a diagram of the Real Team. The team is everyone, not just the smaller teams inside it.

An agile REAL Team
An agile REAL Team
An idealised model of a Real Team

Benefits of the Real Team

To remind you of the definition of agility, I have reprinted it here for ease of access.

It is a belief system that allows teams of people to collaborate effectively to innovate and deliver stakeholder-focused solutions in complex environments at lower risk using short increments, whilst maintaining consistent quality in a sustainable and exciting way.

The Real Team is the most efficient implementation to achieve agility because

  • it eliminates handoff delay and removes queues,
  • everyone who is needed to provide the solution to stakeholders is right there,
  • everyone works on the highest priority items,
  • there is no need to wait for any external teams for dependent work. This team works with stakeholders directly as is able to make the decisions needed to change direction,
  • creates systemic optimisation for flow and ownership
  • raises the quality of the product
  • provides sustainable deliver

A hidden phenomenon of the Real Team is that it creates a shift in identity of members from the small mini-team, silo team, or individual to the scope of the Real Team working on the whole solution. As we will discuss later in the book, people optimise to the scope of their identity. This shift to a larger identity is vital for removing sub-optimisation and creating systemic thinking.

I am not going to go deeper into cross functional teams and T-Shaped people because this has been covered in so many agile books and materials. I feel it is redundant to repeat here. Please review the Large Scale Scrum material on teams for more information.

Considerations before you begin

A heuristic is a guideline. Here are some that I have found useful.

1. Don’t shape teams around the work

2. Teams should be long-lived but not forever

3. Volunteers create more ownership than those who are drafted

Don’t shape the teams around the work

The shape of work changes frequently, however, we want our teams to be long-lived. It doesn’t make sense to bring people to the work. Instead, we must create teams that can work on anything and bring the work to them. This is the only way to remove dependencies.

Teams should be long-lived but not forever

People work best when they feel safe. Team dynamics take a while to settle and even longer for a team to be truly productive and innovative. One the one hand we want teams to be as long-lived as possible because the same people get to know the product really well and can support it better, but on the other hand, working with the same people for years is about the worst thing you can do for quality. Experience has shown that teams work well together for a few years, but Product Developers start to stagnate after three and their skills become stale.

Volunteers create more ownership than those who are drafted

As a general rule, if people choose to be a part of the team, they tend to have a more positive attitude and deeper ownership of improving the team’s ways of working. This of course is not a rule as does not speak for everyone. It is an observation with a relatively small dataset. I welcome your observations of this as you try this approach.

Steps to create Real Teams from silos

Every organisation I have worked with has taken a slightly different path to removing silo teams and building their own version of the Real Team.

In the vast majority of cases, it has been really obvious who needed to be a part of the Real Team. The business problems we were solving, the products they were building, and technology structures all played a part, but really it was so obvious, the formation was almost trivial.

In all of these cases, the teams were already trying different aspects of agility and already knew that they were moving towards wider agile ways of working. Discussing the Real Team with Team Leads, and then the whole team, was mostly met with enthusiasm and excitement. Anyone bringing concerns was made to feel listened to, and their concerns taken seriously. Together we found ways to overcome these issues until everyone felt safe enough to try the new structure.

What made it trivial is the Playbook. Starting with leadership is essential. Trying to do this from the bottom up or with only a part of the leadership team on board, creates resistance and a backdrop of stress with an overly stated and urgent need to succeed at all costs, often with less time than is required.

When the situation is less obvious, or there are impediments to making the change, you might try some of the following suggestions.

Make sure you try to follow the Playbook: Starting with the business problems and outcomes

The business outcomes should be clear by now because you will already have worked with the leadership team to align around the problems and their desired outcomes. They should have a working alliance for the outcome and now be answering the question:

Who is it, who needs to change their way of working for us to achieve this outcome?

The people to include is usually self-evident and easy to find out. If leaders are not aligned; don’t try and create the teams. You are not ready yet.

The value stream experiment

Many of you may have experimented with Value Stream Mapping. In fact, Kanban is a value stream map. If you map the whole process the organisation uses for creating products, you effectively uncover not only who is involved but also where the current work is. This is a ‘start with now’ sensemaking activity you can use with the Playbook.

Value Stream Mapping provides a real-time view of bottlenecks. It uncovers the hidden queues between teams. It also highlights gateways. Gateways or checking points are events in the process where the flow of value stops until some criteria is tested. These checks are usually made to test a) quality, b) regulatory compliance, c) risk compliance, or d) appropriate use of budget.
Each of these checks stops the flow of value and increases delay and cost.

We don’t want to stop value flow to the customer and so wherever there is a check gateway, we have a place in the process we can improve. The improvement we make is getting people to work together in parallel and not in series. We put people together and start to form our Real Team.

Quality is probably the most well-known example. Lean manufacturing brought in the idea of testing at the point of creation, not afterwards. With test-driven development, engineers write the tests (quality checks) before the code, thus eliminating the test gateway.

With regulatory and risk checks, the process is similar. The people checking the product can join earlier in the development cycle. The checks happen as the product is developed. Risks or deviations from regulatory compliance are caught earlier. With risk, especially in medical or financial services, working in real-time with professional risk specialists allows the product to be built around lowering risk from the outset, rather than as an after-thought. This results not only in a more robust and safer product but also improves quality, cost, and speed because products need to be refactored less later on.

Before the change

The above diagram is an example simple Kanban or Value Stream board showing that Team 4 acts as a check gate for the work done by at least Team 3, and possibly Teams 1 and 2 as well.

Instead of Team 4 operating as a serial check gate, they can get involved earlier and assess carry out their checks as the work is being done. By the time the work gets to the gateway, the checks have already been completed and there is no delay. The simplest way to achieve this, is to combine Teams 4 and 3 together, and perhaps all the Teams 1, 2, 3, and 4 if required.

After the change

In an idealised situation, this results in 4 new small teams inside one large Real Team with members of the old teams 1,2,3 and 4 in it. The new Real Team is able to deliver work in parallel via the four new cross-functional teams to Team 5 without any hand-off or delays. The 4 new teams work off one backlog for all four teams.

Often Real Teams go through an intermediate step where inside the new teams there are hand-offs and delays. This step is usually temporary as the following diagram shows.

Steps to build cross-functional Real teams

If this experiment is continued, then eventually there are not silo or specialist teams and the result is the Real Team. Team 5 would also be absorbed into the new Real Team.

Removing gateways and combining teams can actually deliver work 4 times faster.

Some of the common challenges that must be overcome when forming Real teams are detailed in this AWA graphic which was loosely derived from Scott Amber’s work on forming teams from Disciplined Agile.

Factors affecting team building

In reality, there are often many obstacles to overcome such as the number of people for each skills specialism may be different, the duration that each specialist takes on work might be different, and also different teams may require different physical surroundings. Usually, all of these challenges can be overcome with collaboration, investment, or time.

The systemic coaching experiment

My favourite approach to use when it is not obvious who will be in which Real Team is to use Systemic Coaching and Facilitation. This is done through a series of workshops that allow the existing teams to uncover their existing situation and emerge the right Real Teams themselves.

This can be an incredibly fast way to create Real Teams and has the added advantage that staff choose how and who they want to work with. This is usually very exciting and creates high levels of motivation and ownership. Most importantly with this approach, many little details that coaches or managers would have overlooked are taken into account, making it much more likely to succeed.

An example of this approach from a real case study

Just before the Covid lockdown, AWA was asked to help a bank move from a mix of product and project teams to a Real Team structure. It was not obvious who would be in which Real Team because of uneven skills distribution, large banking workflows that spanned many teams, and joining teams would impact the financial budgeting system and reporting lines right up to the board level.

The scope of the work was 900 people in about 120 teams.

Five AWA Enterprise Coaches were assigned to the organisation to work through the Playbook to enable the bank to build the right teams and to make sure they were working on the right things.

We worked first with the board of directors to make sure that everyone was aligned on the purpose of the change (the WHY), and the underlying Mindset beliefs and the Playbook approach (the WHAT).

We spent the first week running workshops with the board as a team and interviewing each member separately. We also met and ran workshops with the Senior Leadership Team and their extended Product Owner and Team leads. This was the very top 3 levels of the hierarchy.

By the end of the second week, the team was aligned on the WHY and the WHAT, and we started to work on who would be in each Real Team (the WHO). We felt it was not up to us to decide who would be in the teams. The workshops would enable everyone to figure this out for themselves and at the same time uncover the real challenges that they would need to overcome (the HOW).

We had participants create a sense-making model of their current situation and the desired outcomes they wanted to see. We used different workshop techniques including the edge model from Arnold and Amy Mindell, Systemic Causal Loop diagramming, Systemic Coaching techniques, and Future Search.

Each workshop with the different teams enhanced and built upon a single global model. The model allowed the participants to discover their own resistance, fear, and other obstacles to overcome as well as likely affinities and skillsets needed to form their new teams. Everyone remained very customer focused.

In just four weeks we ran workshops with most parts of the organisation to uncover dependencies, work in progress, and skills gaps.

At the end of the first few weeks, the board, senior leadership team, all the product owners and technical team leads, as well as over half the 900 staff, had been able to add their thoughts, insights, emotions, and detailed knowledge of their roles into the shared model. Out of the workshops emerged many experiments they wished to try that would overcome obstacles and form Real Teams.

The organisation was buzzing with excitement and enthusiasm for real change and the new Real Teams. Many impediments were uncovered, and the real issues surfaced. The biggest resistance to change was not the original budgets or line manager changes as expected, but the fears of working with new people, making sure the existing work was not abandoned, and what their new roles would be.

It took six months before the Real Teams started to form, and when they did, much of the challenges had been worked out. It was very exciting to see people step up to the challenges and uncover new ones. Always working together to find solutions. This is the beauty of a coaching approach. The organisation and those in it, move at their own pace, they do not feel rushed, pushed, or coerced into doing things they don’t believe in.

Your organisation may be destined not to adapt! A hard reality to face.

There are a few reasons why an organisation may not be able to adapt using these techniques.

Nearly always, the root cause is a lack of leadership ability. Leaders often have enjoyed success using techniques that are linear and controlled in areas of low complexity. As complexity has increased many leaders are unable to grow and adopt the mindset beliefs and resulting behaviour changes. This produces actions that create a culture that is unable to take advantage of any new agile structure or process.

Sometimes, the organisation has optimised around the wrong things for so long, they are in a place where it is simply not viable to change the structure quickly enough to survive. This is rare, but I have seen it. The organisation has become so reactive and so low on cash, that nothing short of starting again will save it, and often that is not legally or financially possible.

In other cases, the domain, supply chain, or geographical location of key skill sets creates multiple backlogs, hand-offs, and delays. In these situations, it is essential that a shift in leadership perspective and investment over time moves towards Real Teams to achieve the level of adaptability required. This might mean relocating staff, training people in different locations, or re-evaluating labour costs versus opportunity-lost costs.

Even though the pressure to remain in the status quo is large, I would repeat Craig Larman’s advice to anyone considering scaling agile.

Large: DON’T!

Multisite: DON’T!

Offshore: DON’T!

Scaling Agile means more of the same things you have already got. That includes the bad things too.

Real Teams are a much better approach.

Here is a real case study example of an organisation that was not ready to adapt. The story is set six years ago when I was working as an independent coach and did not yet have the AWA Playbook.

True story — Lessons from when it goes wrong

Moral of the story: Don’t try and do agility from the bottom up — follow the Playbook.

A few years back, I was asked to help a credit card organisation to implement a new feature for their customers. The feature would involve a third-party supplier, require sophisticated technical implementation including customer data transfer from one company to another, and was subject to financial regulation.

The implementation would require 16 internal teams to collaborate to create the solution, some of which were in different time zones.

I met with a business architect who had spoken to most of the team’s managers. He had spent 3 months working on his own, creating a detailed specification of what the functionality should be and had managed to get a quote from most of the teams but not all. His quote for the project was around two years of work to complete.

I started to speak with the teams to see if we could create a cross-functional team. This was harder than I first thought because each team had a different engagement model. One team refused to speak with me unless I filled out a form. They couldn’t tell me where the form was because I needed to engage with them first.

It took me 9 months before I got an agreement to get a single person from each team to attend a 1-day agile training course to bring them up to speed with the basics. They could not spare any more time than one day. The sponsor also attended the course.

During the training, the sponsor spent the entire time on his phone. None of the people on the course felt like they could commit to the new project because they would never be allowed to work on only one project at a time with utilisations of 25% per project being typical. At the end of the course, the sponsors first comment after looking up from his phone, was ‘So, when will it be ready then?’. I thought he was joking, but sadly he was not.

I decided to change my approach. Surely creating agile teams must be easier than this I thought.

I managed to get someone from marketing, legal, the technical architect, and someone from infrastructure to attend a workshop. Surprisingly, this only took a couple of days to arrange. I held a workshop for us to clarify the purpose and value to the customer, and a story map of the high-level customer journey.

We identified the main risks and decided to work on those. The big risks were:

  • Would the customers want it?
  • Was it even legal to move customer data from one place to another?
  • Could we physically get the data we needed through the various security systems and firewalls?

We created three short experiments to answer these three questions. We didn’t need the other teams for that.

With the marketing person, we created a single web page with a sign up for customers who wanted to know more about the product. Our hypothesis was that, if no one asked, it probably wasn’t worth building. The legal person went off to find out about regulations and how we might proceed legally, and the tech guy and I designed a ‘Hello World’ application that would need to go through the firewalls to say Hello. We figured if the teams could build that we would have engaged them with real work and proved out the security feasibility.

Two weeks later we got the results.

Less than 100 people had completed the form for interest out of 300,000 informed about it, no one wanted the feature! The legal person said there was absolutely no way this was going to pass regulatory checks and it could even open the bank up for huge penalties. The tech guy said security had also said no way to opening the firewall.

The project was cancelled. I considered these two weeks a complete success. I had saved the bank millions and two years of development work that no customer wanted and would never have been signed off by the legal team.

The only person who literally cried was the Business Analyst. His three months of work went in the bin as everyone realised that is not how business works. I did feel sorry for him, but hopefully he won’t do that again.

In retrospect, with an organisation like this, with no access to senior leadership, this situation was a non-starter to begin with. If I had this exact same situation again, I would not take the job. I managed to hack around the situation to start the project, but if it had been viable, I’m not sure where I would have gone next. I can imagine it would have perhaps taken a year or two to get a Real Team together. How many more willing organisations could I have helped instead of taking all this time on one that is nowhere near ready for real agility?

Summary of the chapter

Real Teams are the main building block of an agile organisation.

A Real Team is able to deliver real value to stakeholders and customers without any dependencies on other parts of the organisation. Real Teams do not face off to other parts of the organisation as their customer. Customers are people who consume or pay money for the organisation’s services.

A Real Team increases flow, decreases time to customers, and is the primary method of achieving agility. Real Teams are formed by breaking apart silo or specialist teams and reforming with all the skills needed to deliver products.

Remove silo teams and replace with a REAL Team

There are many ways to go about forming Real Teams, if it is not obvious, then the most effective approach is through systemic coaching and facilitation exercises that result in experiments that iteratively change the way people work. This is what following the Playbook does.

CEO and Founder of the community of practice, training, and coaching company: Adventures with Agile.