The unit of delivery in a risk managed culture is a cross functional team. How do you create value delivering cross functional teams?
The diagram below displays the most common organisation I have encountered for a system. Teams focused on one part of a system are referred to as component teams. Each valuable delivery requires work from the input, logic and output team, and a project manager is needed to allocate and track the work. Although the output team may be able to deliver business value independently, it is likely that any change involving the logic and input team will also require work in the output team, even if it is only testing.
A shift from Inward Looking to Outward Looking
A common pattern for this structure is that each team contains one or more business analysts who are assigned functionality to deliver. The business analysts in the input team of an accounting system asked me to review some stories they had written for a change to the mapping logic. The mapping determined where values contribute to the line on the output report. The new mapping meant that values on one line were being split, with some of the values being moved to another place. For example, comic books are currently mapped into “Toys” but going forward any comic books worth more than $100 are mapped into “Investments”. The business analysts had created stories to explain how mapping values needed to be changed, and the functional changes. They described the changes in the rules. It is rare to find stories that clearly describe the business value and these stories were no exception. As always we start by understanding how the change is perceived by the user in the output of the system.
With comics worth $1500 of which $500 worth are worth $100 or more, and bonds worth $2000, the system would currently display:
- Investments: $2000
- Toys: $1500
With the new rules, the system would display:
- Investments: $2500
- Toys: $1000
Now that we were looking at the requirement from the perspective of what the user would see rather than simply the functionality to change, we could ask what needs the user would have. The users were accountants and one of their key needs is the ability to evidence any changes to the accounts. Simply changing the rules would not satisfy that need. Either the accountants need to run the rules, take a hard copy of accounts, change the mapping and rerun the rules, OR they needed a report that showed the accounts before and after the rule change. For example:
Date of mapping change: 1/1/2022
- Old mapping: “Comic” mapped to “Toys”
- New mapping: “Comic” worth less than $100 mapped to “Toys”, “Comic” worth more than $100 mapped to “Investment”
- “Toys”: $1500 changed to $1000 <Click here for detail>
- “Investments”: $2000 changed to $2500 <Click here for detail>
By considering the “requirement” from the perspective of the accountants, we discovered that the proposed solution to be implemented did not meet their needs and was incomplete. In order to deliver something of value, not only did the logic and output teams need to do testing, they also needed to add significant functionality. The business analysts admitted that they had already made the change and it had been stuck in user acceptance testing for months as the users would not sign it off.
The first rule of creating teams is that they should be cross functional. The team should contain all the people needed to deliver value as perceived by the user. These teams are referred to as feature teams. This indicates a shift from a failure culture delivering functionality to a risk managed culture where the team takes responsibility for delivering value.
The second rule is that each team needs a product owner. A product owner is someone who understands the needs of their customers, whether those customers are external or internal, human or another computer system. Product owners need to understand customer value and how that leads to business value, and as such they are outward looking (h/t to Scott Zebedee). Traditional roles like business analyst tend to be inward looking with an understanding what needs to be done to produce output but not necessarily understand the value of the output to the customer and the business. This also indicates a shift from a failure culture delivering functionality to a risk managed culture where the team takes responsibility for delivering value.
Typically each product owner will work with one team. Occasionally an experienced product owner may work with two teams but this is such a demanding role that an individual adopting the role for the first time should never work with more than one team.
Teams that deliver value rather than functionality?
When forming teams, we need to consider the VALUE that they are going to be delivering over the long term. To understand the value to be delivered, we look at the book of work (which will eventually be replaced by a roadmap based on metrics) and identify which teams will need to do work for each piece of value delivered, not which teams will need to make code changes.
|Epic||Metric Impact||Input Team||Logic Team||Output Team|
|Regulatory change||Revenue at risk||Y||Y||Y|
|Accounting rules change||Revenue at risk||Y||Y||Y|
|New mappings||Retain customers||Y||Y||Y|
|Ads from third partner service||New Revenue||N||N||Y|
|New customer on-boarding||New Revenue||Y||N||N|
|Migrate to Cloud||Reduce Cost||Y||Y||Y|
It is clear that most of the work requires a team that can work on all three components. The work with Ads integration may not need work on all three components but if its a small piece of work there is no justification in having a separate team. The new customer on-boarding may justify a focused team if there is a lot of on-boarding work. The performance and cloud migration may justify a separate team if a lot of work is to be done over a long period of time that does not require work from the other teams.
The result shown in the diagram below would be several feature teams that cover all three components, an on-boarding team that has specialist client handling skills (purple man) and a specialist performance team to improve the performance metrics of the system. The goal is to form the teams so that about 80%-90% of the work they do can be done as a single team without having to work with another team on this system. The key point is that they are stable long term teams with a stable long term mission. The stable long term mission in this case might be business value, performance or on-boarding. The product owners for the performance and on-boarding teams may be people in the “grey” technical lead or project manger role.
At Skype, this group of cross functional teams was called a release vehicle or RV, something that could release value independently of other teams. The number of teams depended on the amount of work that the executives expected they needed to achieve strategic goals. Mark Gillett told us the unit of investment is the team. The quarterly capacity planning was used to refine the number of teams in each RV, with the creation of a new team, moving a team to a new RV or temporarily shifting of a team to a different mission. The teams were moved rather than individuals ( Note that the Skype model only had feature teams, not the specialist on-boarding and performance teams mentioned in this example. )
Anti-Patterns of team formation.
There are a number of anti-patterns that mean the team is not a not fully cross functional team that can independently deliver value.
- Missing skills – The team is formed with only some of the skills that are needed to deliver value. Most commonly, the testing capability is missing from the team and is provided by a central testing team.
- Missing parts of the Value Stream – As mentioned above, the teams are formed around a component of functionality rather than the entire system.
- Non-diverse teams – Jim Coplien has done research that shows diverse teams out-perform non-diverse teams, especially if there is a mixture of men and women on the team.
Another common mistake is to split the teams so that some focus on the delivery of customer value (business facing) and some who focus on code quality (Automated Test Coverage, Clean Code, DevOps). This creates a culture where the customer value teams do not care about code quality. As the teams are funded rather than the projects, the code quality teams are the ones most likely to be unfunded in a review by the business investors.
If you have experienced other anti-patterns, please share in the comments.
So the conclusion is to form teams based on value rather than functionality, with product owners that are outward looking at customers and business value rather than individuals that are inward looking at functionality. The next blog will describe how to get the teams to the right size using a skills matrix.
Thank you to Scott Zebedee for helping me with the inward looking / outward looking concept to explain the ideas in this post.
January 17th, 2022 at 11:37 am
Thanks Chris, another insightful post.
I’ve been encouraging folks in Government to invest in teams (rather than projects or functions) aligned to the value stream. Do you have any tips for working with Finance people to help them understand how their approach to investment funding might have to change when the organisation goes down that route?
January 17th, 2022 at 2:09 pm
Probably worth cross-referencing Team Topologies here. They have a nice taxonomy.
January 19th, 2022 at 12:36 pm
Another fine article in your Failureship series Chris, they are an invaluable set and one that I’ve returned to a lot.
Having said that I am worried that you have still not seen many good examples of Business Analysts adding value to cross functional teams and that the role tends to be inward looking.
“Traditional roles like business analyst tend to be inward looking with an understanding what needs to be done to produce output but not necessarily understand the value of the output to the customer and the business.”
There is a risk that this over-emphasises the name of a role but I have always believed that Business Analysts have the skillset to be a vital part of cross functional agile teams. On a recent government project I led the business analysis for the business (acting like a proxy product owner for the business) we had 4 newly formed cross functional teams, delivering features, and two more traditional teams used to working to waterfall delivery.
The Business Analysts in all the teams were focused on both discovery and supporting current work. They would continuously challenge me on the business value and priority of particular features and would collectively regularly meet to look ahead and discuss what impact a feature could have on both the different systems build developed and the impact on different stakeholders.
The way we worked meant the Business Analysts were able to keep ahead of the work so by the time the wider cross functional teams were ready to get into the detail of specific features the BAs had a good understanding of the value to be delivered, the details of the feature, alternative ways to tackle the problem and how it fitted into the overall solution. We then held workshops with more members of the relevant cross-functional teams and business stakeholders.
The context we were working is was interesting because we effectively had dual power. The ‘frozen middle’ weren’t frozen and were used to detailed planning and controlling the communications with the delivery teams. The official model was for the business side to hand over written requirements to technology who would convert them into technical requirements and give them to the relevant delivery team.
It was clear this approach wouldn’t suit our large complex project so an agile coach ran some helpful ways of working sessions. They weren’t enough to shift the centre but gave enough confidence for some key people to develop our unofficial ways of working which meant the Business Analysts were central to being able to start delivering real value to key stakeholders and business were closely involved on an ongoing basis. I would not recommend this approach! Incidentally I don’t think we ever worked out who any of the product owners were!
January 21st, 2022 at 11:00 am
I enjoyed reading about structuring teams in release vehicle(s). Aligns very nicely with the “team of teams”. I think another problem with only inward looking, is silo thinking and getting stuck in the rut of developing software. Majority of (component) teams don’t get a chance to see the outcome of their work. How, what they do, is being utilised in the real world by real people is unknown, as all they may be focusing on is to change the mapping based on a new business rule.