Monthly Archives: January 2022

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?

Photo by Randy Fath on Unsplash

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.

EpicMetric ImpactInput TeamLogic TeamOutput Team
Regulatory changeRevenue at riskYYY
Accounting rules changeRevenue at riskYYY
New mappingsRetain customersYYY
Ads from third partner serviceNew RevenueNNY
PerformanceRetain customersYYY
New customer on-boardingNew RevenueYNN
Migrate to CloudReduce CostYYY

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.


How the failureship destroys teams

The unit of delivery in agile is the long lived cross functional team. Rather than individuals struggling to perform their allocated tasks, a team takes responsibility for delivery of work items that deliver value. The team work together to deliver value for the customer, supporting each other to perform tasks, and learning new skills to become “T” shaped. Each team contains between five and nine people. The failureship, especially the frozen middle, act as a serious impediment to the formation of teams, and will destroy teams if they form.

Photo by Shane Devlin on Unsplash

The most common organisational design to support a single system in a failure culture is shown below. It arises out of a desire to reduce costs and use expensive low cost developers that can quickly come up to speed. There are separate “teams” who look after Input, Logic, and Output (ILO). Similar anti-patterns include the Front End, Back End, and Database (FBD), Business Value, Support and Refactoring (BS Refactoring), or Development, Operations, and Testing (DOT). The net effect is that several teams are required to deliver anything of value to the customer. Each of the “teams” will contain any number of people from one to one hundred and beyond.

Each sub-system has a individual shown in Grey who acts as technical lead / architect / component lead / sub-system manager (line manager). This person is normally from a developer background rather than a project management background. Their power comes from having a holistic understanding of the component that they lead, especially an understanding of where the technical debt is hidden or “where the bodies are buried” as it is also known. In effect they have a skills matrix inside their heads where no one else can access it. In order to deliver anything of value, several teams are always needed.

This is not considered a problem because a Project Manager pulls it all together into a deliverable. They take named individuals from the team and form a short lived team (called a project) to make the deliverable happen. The individuals are not part of a real team and are solely responsible for making their part of the deliverable happen. The Project Manager works closely with the Grey who allocates the “resources” to the project manager.

The good news for the organisation is a dog eat dog hero culture will emerge, but the bad news is there are a lot of key man dependency (poor skill liquidity). In reality, apart from the Grey, the developers in each of the teams are not skilled in all aspects of the sub-system and each developer has part of the sub-system that is “theirs” which maximises job security.

Where the delivery of value involves more than one system, a program manager is required to manage the deliverable from the project managers.

A shift to a team based culture would result in an organisation design as shown below. Each team has all the skills necessary to deliver end to end value. ( How to form the teams will be discussed in a later blog post. ) The “Grey” roles would disappear, as would the project manager role as teams took responsibility for their own work. Long lived teams teams of five to nine people would work together and collaborate, sharing knowledge and skills. Although the long term team size is five to nine people, during the formation of the teams, larger teams may form to facilitate the transfer of skills and knowledge (possibly using a skills matrix to assist) before splitting into more appropriately sized teams.

Where more than one system/team is required, the teams would form a scrum of scrums to facilitate the delivery of the value. Where the same teams are coming together in a scrum of scrum over and over again, the teams may merge for a period and then split into two or more teams as appropriate.

In addition to this delivery structure, the organisation may implement the chapter from the Spotify model. The chapter lead acts as line manager for the individuals with a particular skill set to ensure personal development and alignment of skills. Historically this need for personal development lead to the development of departments and silos (Source: Marc Burgauer).

We need to talk about Kevin

One of the biggest challenges for an organisation looking to move to a team based model is what to do about the frozen middle failureship… the Project Management Organisation (Project Managers, Program Managers, Portfolio Managers and PMO) and the “Grey” role. In order for the new organisational design to emerge, the frozen middle failureship must disappear. Whilst they exist, the project based model will persist. The frozen middle has more power than any other group to make things happen, or prevent them from happening. They can easily force any transformation into failure, and they often do. Simply put, the transformation shifts power and responsibility from the frozen middle failureship to the teams. The frozen middle often resent the loss of power, and the teams are often fearful of taking up the responsibility.

The frozen middle anti-pattern

The easiest way to spot the resistance of the frozen middle is in the organisation structures. The frozen middle suggest an intermediate step to the formation of teams as shown below.

The executive failureship cave in to their suggestion because any changes they want to happen either happen through them, or the failureship need to lead the teams to do something that some of them do not want to do. This structure reinforces the roles of the frozen middle failureship, retaining their power base, and prevents the need for the teams to step up and take responsibility. Project managers and “Greys” continue to allocate individuals to projects and nothing significant changes as the teams are not really acting as teams.

All that happens is a cosmetic change of the organisation hierarchy at the bottom of the organisation, possibly with the introduction of addition layers of management (more frozen middle)

I have experienced this failure to remove the frozen middle failureship in several organisations. Normally because executive failureship was either too scared of the frozen middle failureship or because they were not really committed to improvements in the organisation.

An alternative to this structure is the adoption of the SAFE framework with its roles that preserve the frozen middle failureship.

Dealing with the Frozen Middle Failureship.

Removing the frozen middle failureship roles does not necessarily mean removing the individuals from the organisation. Often the individuals in the frozen middle failureship are some of the most effective individuals in the organisation at doing things and getting things done.

It is important for individuals to choose a new role based on invitation rather than be assigned a new role. People who are assigned a new role will almost certainly continue to behave as they did in the old role. Asking a project manager to manage in an agile way will result in no change in behaviour.

This is likely to need an organisation wide change. If the technology group make this change but the “business change” group do not, it is likely that a rival organisation will emerge to manage the new way of working during the period of uncertainty and change. The leadership will need to build alliances across the organisation to shift the organisation from one controlled by the frozen middle failureship to one based on self discipline and teams with lightweight (Scrum of Scrum) coordination.

At one organisation the transformation started with the leader of the company sacking all forty project managers in one go. I joined shortly after and the stories told lead me to believe that sacking the project managers en-masse was a mistake. In that organisation, a healthy product owner organisation emerged that truly lead the development of the product based on customer focused metrics. The development teams took responsibility and pride in their work. We eventually re-introduced the project manager responsibilities as a scrum of scrum master responsible for facilitating cross team development, and with none of the power. It was one of the most impressive organisations I ever worked in.

At another organisation the project managers were given the choice of either becoming a developer, a scrum master or leaving the organisation. Combined with other changes, the result was a 50% increase in productivity.

Subsequently I have worked in several organisations where the frozen middle failureship was allowed to remain intact. The project managers played lip service to change, with agile theatre, and an appropriation of agile terminology but no change in behaviour, and no real improvement.

For many years I thought the wholesale sacking of the frozen middle or forcing them to chose between a new role or leaving damaged the organisation was wrong. I WAS WRONG. I now believe that any transformation that does not actively dismantle the power base of the frozen middle failureship is doomed to fail, It will simply introduce agile theater. The leaders in the two companies above were courageous in the changes they made but that is because they did the research and built their own experience rather simply rely on the recommendations of experts. They owned the changes and ensured their success.

Where do the frozen middle go?

As I mentioned, many of the individuals in the frozen middle failureship are brilliant. They just need to do a different role. They need to give up control of the allocation of work to individuals and making commitments on behalf of other people.

So what are the roles that they could move to?

The “Grey” role has many options due to their deep technical knowledge:

  1. Product Owner – They could become a product owner who focuses on delivering value against technical business value metrics ( Performance, Lead Time, Through put, MTTR etc. ).
  2. Lead Developer / Developer – Nuff said.
  3. Chapter Lead – Line managers responsible for the development of other developers.
  4. Architect – Trusted advisor to the product owners, writing technical user stories.

The project managers similarly have many options:

  1. Product Owner – They often have the closest relationship with the customers.
  2. Scrum Master – Nuff Said
  3. Scrum of Scrum Master – More in a later post.
  4. Developer
  5. Chapter Lead for Scrum Masters

Most of the agile roles are based on facilitation rather than command and control. They require relationships that are adult-adult rather than parent-child. Some people find that idea scary and they may chose to leave the organisation for that reason, or for some other reason.

If your organisation claims to want to be team based, look at the structure of the teams and the behaviour of the middle management. If you see the anti-patterns mentioned above, know that it will be theater rather than genuine change.