Saving teams from the failure culture

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

Mapping change:

• Old mapping: “Comic” mapped to “Toys”
• New mapping: “Comic” worth less than $100 mapped to “Toys”, “Comic” worth more than $100 mapped to “Investment”

Impact:

• “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.

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.