Think about the concept of a feature team – all of the skills you need to deliver features in a single team. This comes from software / IT teams predominantly – I first came across the concept from the Vodde / Larmann books on scaling agile. Furthermore, if you add the scrum ideas, usually this is limited to 7+/-2 people. So, everything you need to continually deliver features within no more than 9 people. To scale, you need many more groups just like this, all delivering features.

I have never seen this actually work in practice because eventually, particularly in medium to large organisations, you need many more services to deliver features. It might be OK in a start up, but eventually you will need to scale and once you do, this ideal breaks.

There are a few examples of this, let’s start with a product company. Imagine that you’re delivering a product to market, think of all of the things that you need to make this happen. You might have a product manager determining which features to target in particular markets. There may be quite a bit of research that helps start this journey – they might even call in some customer / user experience experts to help them with this research. They’ll need to understand if the feature will be financially viable, so they consult with the sales and finance departments to figure out if it will even be profitable. There may be legal issues involved with introducing this, so they may also consult with their legal department or external lawyers. I think I’ve already hit the 5-9 limit there and we haven’t even started to build the feature yet.

Let’s look at a company with a technology department supporting the larger organisation. Generally, teams are organised into domain groups or technology based groups or mixtures of both. Often when you get to a certain sized organisation, trying to keep all of the skills together for features is difficult. Granted, there might be a large number of features that can go through this team without touching any other interdependencies. However, eventually you’ll get to a point where you’ll need a skill that’s not contained within that smaller group. Oftentimes, you may get a group of 25-50 people who are formed in several “feature” teams, but often there’s some kind of specialist in each one. In that case the teams are always going to call on each other’s help to complete a feature.

I have heard some people mention that you can move people in and out of teams on demand – for example if you need some legal advice on an item, that lawyer becomes part of the team or even “solution/release train”. This is not a realistic option as that lawyer is likely simultaneously providing advice to different areas of the business, they’re really not part of the team. This is once again an example of trying to move “people to the work” rather than understanding how work flows through the network and the interactions involved.

In either case, by creating feature teams you’re assuming that you’re going to continue to get the same kind of demand, over and over. Herein lies the trap – if you create feature teams you could potentially create a fragile kind of environment that may be resistant to other kinds of demand – and those kinds of demand may prove to create new, highly valuable revenue streams. In manufacturing, you may be trying to do this kind of thing where you have to repeatedly create the same widgets over and over again, however in knowledge work it’s quite different. You need to be optimising for change and adaptability as the nature of demand will change.

Your organisation is a network of interdependent services, it’s not a mass of groups making widgets. What is important is to optimise the way different kinds of demand can flow through that network and to ensure that it continues to evolve and adapt in response to the different kinds of demand. Creating feature teams can work against this kind of agility as the teams focus internally to produce things and don’t strengthen and create new linkages in the network overall. This problem won’t necessarily be avoided with component teams, however component teams by their nature have to interact with other teams and groups to produce an outcome so they naturally create and use those connections.

When creating feature teams, you’re looking to optimise the creation of those features with small teams to cut down communications lines and enable more rapidly and cost effective delivery. This may work in the short to medium term where you’ve continually got the same kind of demand. Ultimately, you may be moving people around more regularly to keep features within a team or group. You might even find, particularly in organisations that are not small, that you’ll inevitably need additional services to complete features – too much to contain within one team. Strategically thinking, you might want to consider whether you want to optimise for creating the same things over and over or optimise to adapt and change with different kinds of demand.

In this way, feature teams really are an idealistic state that you’ll never effectively reach. In most organisations you’ll have to scale differently with different kinds of demand that will call on services from across the organisational network. Please consider feature teams and ask yourself what really is the best way to optimise and scale for your organisation?


Earlier in my journey as a coach / delivery consultant, I thought that agility can be achieved through a “high performing team”. Many agile coaches, scrum masters, delivery leads / managers etc have tried to achieve this kind of thing through making a great team. This might work really well in a small organisation, but once you get to medium to large size organisations, this is not necessarily where the key problem is.

In more recent years, I’ve observed how critical it is to bring various groups together to achieve an outcome. The solutions to some problems are larger than just one or two teams and create interdependencies for delivery. Often, the points of waiting and even friction occur where these interactions are necessary.

Problems with “High Performing” teams

A high performing team works great when all of the dependencies are contained within the group. This could be a single team or a “Service Team” which I see as a larger group or “team of teams” providing a service (eg five 10 person teams working together). Often this team have optimised the interactions within the group and have a fairly well known way of working.

Where this group needs to interact with others in the organisation, it can run into problems. Other groups may have their own way of working which may be similar but is often times different. Relationships between members of the different groups may not be very deep or perhaps non-existent.

Additionally, I’ve seen in the past where teams are “high performing” this can increase the silo mentality and start to create a blame culture. That is, they don’t want to be seen as a non high-performer and become insular and in some cases arrogant. They can call blockers out up and downstream, but don’t want to spend their time being “unproductive” by relieving the blockers. If it goes unmanaged, you can see them pull in more WiP in this circumstance while they wait , which creates further problems.

It may be that they don’t have the skills to go upstream / downstream to help relieve the overall system. Thus they continue on with solving “their part of the problem”, but the overall tends to suffer.

Take, for example, a mobile development service team. They may make regular (eg monthly) improvements to the mobile application / device for your organisation which they can do entirely by themselves. Then at some point your organisation wants to launch a whole new feature not previously seen. You want to showcase this at an upcoming trade fair to generate the largest possible market interest in a short amount of time. Your mobile team will need to work with the marketing team and sales teams to ensure you can maximise the revenue opportunity at the trade fair. They may have rarely done this before, thus the interaction is unusual but critical for the overall business success.

Nature of work in large organisations

Your organisation is a network of interdependent services that act together to serve your customers. This is really an adapting, changing, organic ecosystem if it’s running effectively. External stimuli (customers, markets, competitors) will place new demands on the ecosystem and it’s long term success is based on it’s ability to adapt to that stimuli.

In larger organisations, there may be some interactions between groups that are consistent / regular (work together on many / most initiatives), others may be occasional (eg once or twice a year) and others may be a “one off”. For those that are consistent or occasional, you may be able to predict this to a certain extent. Even if you can predict the frequency of the interactions, the nature of the individual interactions may be quite different.

Oftentimes, the really high value work will mean that this kind of work likely doesn’t have much / any connection to previous work so you’ll need to establish some relationships from scratch.

Possible Solutions

Understand the network

Sometimes to get this understanding you may need to visualise the work and “how work works” as it traverses the organisation.

Where it is at all possible, it would be worth gathering some data about the network to understand the interactions. You can see where the common links are that you want to strengthen and how you may wish to make changes. You may also wish to gather data on where wait states and blockers are in the overall workflow. You may wish to introduce a cadence like Kanban’s “Operation’s Review” to continually monitor and adjust.


The internet is a classic example of a network that grows and changes over time, but the fundamentals of how nodes communicate with one another is governed by some simple protocols. You can set this up as basic systemic policies to allow for simpler communication and coordination around the network.


Sometimes cadences can work to help with synchronising groups. However, beware of this becomes sometime they can be a source of waiting / waste. For example, if you have a quarterly planning cycle, you may not want to wait that long for a new, urgent piece of work.

Reorganise teams

This really isn’t really viable in the short term – with different work coming from different sources it often doesn’t make sense to continually reorganise. Furthermore, there are costs associated with doing so – there will be a period of inactivity, plus you’ll lose the benefit of previous metrics for that team as it establishes it’s new identity / way of working. If in the longer term you see a continuing pattern of teams working together, you may want to take action at that point – just wait until the reason is compelling enough to justify the cost.

Remove dependencies

This is something that you should always consider, however in larger more complicated work, this is not always practical or possible. You may achieve this by slicing work into more narrow / succinct areas of scope to avoid the immediate need for a dependency. This can also be achieved by changing a technical need for the dependency.

Coordination specialists

Some people are natural connectors in organisations, knowing who to contact / bring together to help solve problems. You can use these folks to help guide work through the network, facilitating the creation and maintenance of connections where required.

Team Member Swap / injection

While complete reorganisation of teams may be too disruptive, you may wish to consider injecting a member from one service team to another to act as a bridge for a particular initiative. This could also take form of a swap where team members are exchanged from each group. This will help build a deeper understanding of the other groups context which will make this and future interactions smoother.

Stimulating the organisational network

There are a couple of spins to this from my perspective – one is the effect you get from large group events where there is lots of interaction. Meeting new people and understanding who is who can help to start to bridge the gaps of connectedness – this can often occur as part of a regular planning or other similar cadence. The other way is a deeper understanding is through other techniques like Cognitive Edge’s Social network stimulation.


As your organisation grows, the complexity of how it solves problems will likely also change. When you get to a certain size, having a “high performing team” will not necessarily be enough – you will need to tune the entire network of services to be able to adapt appropriately.

This is not a simple problem to solve, so it’s best that you don’t act too simplistically. Furthermore, as the organisation and environment continually evolves you will never be “done” with this – you’ll always need to monitor and make continuing adjustments.

As I mentioned in my recent post on Kanban books, I would recommend Klaus Leopold’s book on this topic: “Rethinking Agile: Why agile teams have nothing to do with business agility”.


Everyone has probably seen a job ad for a “rockstar” team member, or perhaps it’s come under a different name like “ninja”, or you may just know them as “heroes”. How would you define something like this? Usually people are looking for the expert / saviour that will help get things over the line even when things are tough.

In reality, what this often manifests in are individuals who are working for their own purpose, rather than that of the organisation. Oftentimes, these individuals tend not to share knowledge and often work alone since the sharing of knowledge would threaten their position as the “rockstar”.

The effect that this kind of behaviour can have includes sub-optimising the system and creating a bottleneck – since only one person can solve all of the tough problems they quickly get overwhelmed with work. Since they won’t reach out for help it becomes an escalating problem as more and more work get’s backed up in front of the bottleneck.

It can also have problems on team morale – when team members see people acting as individuals, then they will start to either resent those people pushing them further from the group and / or give others permission to act for their personal interest rather than the organisation’s interest.

You can start to see how one policy of hiring “rockstars” can have multiple impacts on the overall system of work. Is it really the rockstar who is to blame here, or is it the system of work and the leaders that allow this behaviour to continue?

In discussion at our local lean coffee group, one of the members used the example of a football (soccer) team. In which, he said he wants those superstars on his team because they convert those rare opportunities into goals that win matches. However, they often have rules in place to ensure that the star players don’t get ahead of the team – with systemic solutions such as dropping a player for a week if they act in their personal interest rather than the team / clubs interest (for example by not passing the ball in certain situations).

I think therein lies the solution – you can have great people in your teams so long as the system is set up so they continue to work in the organisation / team’s best interest, rather than their own. Set up the system so that great people can work together to achieve great outcomes and put in place measure that allow this to happen and prevent the need for heroes.