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?