Cross-functional teams are the ideal of Agile cross-functional teams because of their ability to deliver high value continuously. Dependencies outside the team are proven to be the number one impediment to value creation1. Today we don’t just define cross-functionality as developers with different skills: the DevOps movement has brought operations into the teams, and BizDevOps is a common term for bringing business into the teams as well. I am a big believer in fully cross-functional teams, and I believe they can take direct responsibility for business development2.
However, it’s not enough that teams are cross-functional if we desire to create as much value as possible with the resources we have available. It’s not enough that they are efficient within their bubble (e.g. project); portfolio management should make sure that they have the optimal responsibility. We must avoid the vicious cycle of portfolio management. The teams should not only be able to do all the necessary tasks. They should have full lifecycle responsibility for the product; they are developing to maximise their value creation from a holistic perspective.
At the team level, this means that all teams should be Quad-coloured. This article will explain the concept of Quad-coloured teams, which is derived from The Portfolio Circle3. If you’re not familiar with The Portfolio Circle, you should read that article first.
This article will also make it clear how the Portfolio Circle and Quad-coloured teams have a significant impact on how we must think about Portfolio Management in the future.
The Portfolio Circle at Team Level
The Portfolio Circle can describe all development work in an organisation, and similarly, it can represent the different kinds of tasks that are solved by a single team. Traditional portfolio management favours project teams, i.e., teams that focus entirely on a Strategic initiative, because from a local perspective of finishing the project, that is optimal.
As a consequence, other teams in the organisation similarly focus on one type of task in the Portfolio Circle. Again this optimises locally – one kind of task and one decision-maker seems efficient.
Therefore the teams in an organisation are typical:
- project teams who are supposed to focus on the Strategic initiatives.
- maintenance teams that solve Improvements and Support tasks (and is used as a buffer when strategic initiatives suffer).
- pure Support teams, who answers the phone when users are in trouble. They mostly compensate for suboptimal systems with workarounds or pass bugs on to a development team.
- technical component teams who are supposed to maintain a system/component which mainly are Upgrades. If the team is handling a business system like ERP/CRM etc. most configuration and development work is Improvements.
A traditional portfolio consists of teams like illustrated above: A majority of teams working on Strategic initiatives, some that handle Improvements and Upgrades, and some only handle Upgrades on systems. Let’s take a closer look at each type of team.
Red teams
When project-teams are formed to initiate a Strategic initiative, in most organisations, it is with the assumption that they can work 100% on Strategic initiative(s). In reality, everybody in the team brings their part of support into the team derived from the initiatives, which they were part of previously. Even teams that are formed by all new employees will only remain purely RED until their first release.
As soon as they have released, they will have a little and growing Support on the released part, different parts of business start to wish for Improvements and as soon as a component, they use, release a new version, they will also have Upgrade work – see figure below.
This notion of RED teams makes a little more sense for traditional waterfall development where the expectations of management and customers are that the team delivers as specified at the end. But there is still support, improvements, and upgrading to do after the delivery, and how is that handled? Typically organisations will invest in handing over knowledge about the new stuff to Improvement and Support teams. Asides from being an expensive non-value adding activity, it is not possible to do it thoroughly. There will always be a need to go back to the people who made it originally. There is another rarely considered drawback in handing over the result of the project to someone else: The original team never gets feedback on the quality of their work, which is stealing their chance to learn from their mistakes. Research shows that from 60% to more than 90% of the total software cost is maintenance, i.e., after project delivery 4 which puts the issue in perspective.
There are more reasons why RED teams tend to deliver lower quality than they could. I am not saying that these people are dumb and lazy, but it’s a well-known fact that the pressure to deliver at the end of the project can be high, and therefore quality-corners are cut. I have also seen many times that when people know that they must clean up after themselves, they leave the product in better shape. The behavior of the teams is very human, but it generates debt, which gradually pulls more and more capacity to Support and therefore reduces the capacity for future strategic initiatives.
Blue and green teams
In traditional portfolio management, a BLUE team will be called a maintenance team and can be more GREEN than BLUE because its capacity just allows keeping the system(s) floating and not much more.
These teams exist even though strategic development is happening in the same systems, at the same time. The arguments I have heard for this parallel organisation is that “the red teams must be able to focus on delivering on time,” “real developers will leave if they have to do maintenance,” etc. These are true under traditional portfolio management: RED is considered better and more valuable than the rest, despite that high quality and continuous improvements are an integral part of the user’s experience of the product. Developers want to be where their work is valued, so when the organisation has a more holistic value perspective, developers also want to deliver a whole solution – not only the strategic stuff.
Leaving the Improvements and Support to others than the original developers will always be much more expensive because they have to use more time to understand the solution.
You may also have pure green teams. You probably call these teams helpdesk. As valuable as they might seem to the users, I argue that they compensate for shortcomings in your systems: either bugs or insufficient/poor support for the users’ needs or poor implementation. Am I too harsh when I claim this is the cost of poor previous choices? Try to think about the systems you use every day delivered by Facebook, Google, etc. – how often du you call their helpdesk? Right, there are None!
Another positive intention of the helpdesk is to protect developers from the noise from user calls. The helpdesk likes helping people and spread workarounds in the organisation to enable users to continue their works. A helpdesk creates an effective filter that prevents the issue from reaching those who could fix a bug or make a small improvement, which could remove it permanently. Instead, many users continue to waste valuable time, and the developers are not learning from their mistakes.
Grey teams
Do you have grey teams in your organisation? I guess you have teams who set up servers, databases, etc., teams who maintain the development platform, teams who upgrade systems, etc. From a business perspective, these teams generate little business value. It can, however, make good sense to create a team around a shared resource to reuse it in more teams.
Grey teams often show a superior rather than a servant attitude towards the other teams. They know their stuff, they “know best” what is needed and they do it their way and when they want to. The other teams cannot deliver when they, for example, need a change to the shared resource to fulfill the needs of their customers. The grey team has their list of priorities, so the other team must wait.
Is that a problem? Not necessarily. It depends upon the capacity of the grey team and how customer-centric they are. If they can respond within a week or two, it is probably not a problem, but if they prevent teams from doing what is best for the users, the grey team is effectively overruling strategic and business decisions, which reduces value creation.
When it comes to upgrading business systems, this mostly handled in Strategic initiatives with the upgrade and a collection of improvements because the systems are left untouched in-between the upgrades.
Mono-Coloured teams
Portfolio management with mono-coloured teams appears to be homogeneous from an internal view, from a local point view, but not from a user’s perspective. The changes that the users desire, e.g., to their work processes, will be distributed across several teams with different entry points, different priorities, etc. Priorities are not transparent to them, and it makes it much harder for them to optimise their changes according to value.
A consequence of a portfolio of mono-coloured teams is that there is no mechanism for prioritising in the dimension where you earn money. How do you know you create the most value for the user, when there is no way to compare value and cost of a feature in a Strategic initiative, with an Improvement, an Upgrade or a bug? You may be locally efficient, but that doesn’t guarantee you make much value to the customer.
I am not claiming that traditional portfolio management completely loses
the view of the user, but we have made it hard to have a holistic view of the value and cost along the value streams where we make money. Even harder, it is to optimise the value creation, which I suppose is the purpose of portfolio management.
Having mono-coloured teams for whatever reason comes at a cost. These are summarised in the table below.
Quad-Coloured teams
If mono-coloured teams are not optimal from a value perspective, what is? Let’s look at the other end of the specter – the Quad-Coloured team.
What does it mean to be a quad-coloured team? It means that the team is responsible for the whole lifecycle of a product (or sub-product) and create all changes: large or small, to that product, from Strategic initiatives to Support.
Since they have lifecycle responsibility, they will exist as long as the product. Teams can deliver what is most valuable for the users continuously, and while they do that, they can learn from user feedback what they appreciated and balance Strategy, Improvements, Upgrades, etc. better.
The team will probably have what they call a product backlog with all the changes they could do to their product in prioritised order: Strategic new features, Improvements to existing features, Upgrading the components they use, and eliminate the debt that prevents them from delivering maximum value to their users. Not necessarily in that order – definitively not in that order. The different types of work are mixed according to value pr effort.
Does a backlog sound like an unmanageable pile of inhomogeneous incomparable stuff? Typically the Improvements, Upgrades, and Support are small chunks by nature, so to have all work in comparable size, the Strategic initiatives must be broken down to similar-sized independent valuable pieces. Agile teams call the pieces User Stories because the individual pieces are valuable to the user.
How does the team know what is most valuable to the user, and therefore should be done first? They are in the center of the value stream, and they are continuously learning about the users’ needs from all the changes they make.2
A quad-coloured team has all chances to outperform any other team type because they don’t experience the challenges in the table above. They do not waste time making handovers, they learn from their mistakes, they are in control of their platform, and they know that everything they do is valuable to the user. All components of high motivation are present: autonomy, mastery, and purpose.
Quad-Coloured teams in traditional organisations
Quad-Coloured teams seem attractive, but they are hard to implement in a traditional organisation with a project mindset. The challenge to most traditional organisations in doing that is the level of delegation of power and trust it requires. Traditional product managers, marketing managers, IT managers, etc. etc. will know less about the value of user stories than the team and will be more or less a surplus if not directly an obstacle to value creation.
Higher levels in the organisations will feel that they lose control when the team prioritise Strategic initiatives, Improvements, Upgrades, and Support. They have to persuade themselves that happy users are more important for the organisation than their control over everything. If teams release in small increments, rapid and transparent feedback from users becomes the safety belt against poor decisions, that the organisation never had before – and never will have, if they do not delegate.
A third obstacle for implementing Quad-Coloured teams is that internal users are trained in the project mindset. They are so used to large implementations with questionable quality that they prefer not to have valuable functionality until what they perceive as everything is ready. Yes, they refuse valuable, high-quality increments, when asked. My best advice here is “just do it”: Don’t spend your time trying to convince them with words, persuade them with action. Deliver the first increments with extremely high quality, and they will start loving you.
Quad-coloured teams in your portfolio management
Turning from mono-coloured to quad-coloured teams also affect your portfolio management.
First of all, it is a shift from project thinking to product or value stream thinking. From thinking in terms of prioritising different changes to allocating capacity to the products/value streams, you want to invest in, because your customer is prepared to pay. You must shift your focus from prioritising based on the cost of projects to allocating capacity based on the value of your products because your teams handle the full lifecycle.
It will be much easier to match the revenue generated from each product to your investment, which means your priorities at the enterprise level will be better as each quad-coloured team optimises short and longterm value. The teams can create transparency around their value creation almost in real-time.2
The shift to Quad-coloured teams doesn’t exclude other types of teams, because there will be some shared work/resources which are valuable for the quad-coloured teams to have handled by support/component-teams. But the majority of teams will be quad-coloured as illustrated below.
The figure gives the impression that there is the same capacity for all products, which, of course, is wrong. Some teams are larger than others, and some products are handled by several teams, as illustrated with the full line above. It is the whole point in portfolio management with products to be able to turn the capacity up and down according to how much you want to invest in a specific product.
Portfolio management means that when you decide to invest less in some products, you will have to merge them into a combined product, for it to make sense to have a team working on it. Likewise, when you decide to invest more in a product, you will have to have more team collaborating around that product. Preferably you will split the product into more independent sub-products to minimise the amount coordination and maximise the ownership in the teams instead of creating mono-coloured teams with dependencies.
How do we get there?
Now that you have seen the potential of using The Portfolio Circle to understand how to manage a portfolio of Quad-Coloured Teams, you are probably wondering how to get there.
For organisations with a project mindset and a majority of mono-coloured teams, all parts of the organisation and the systems have taken shape according to that. Therefore it will be a significant organisational and technical endeavor to shift to a product mindset.
There is a lot of advice to give in that regard, probably for several longer articles, but my first advice is to start talking to your users. How do they perceive your systems? How would they split it up into sub-products, if they had to?
Try to understand them and stick to this as you progress to match your organisational capabilities and system architecture to quad-coloured product teams, which ain’t going to be easy.
But your rewards in value creation, customer, and employee satisfaction will outweigh your struggles – I promise!