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.

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.