The Team-Centered Organization

It took us a long time to make the move to hybrid vehicles, and even longer to electric powered. For decades, the major automobile manufacturers seemed to be ok with the existing state of affairs. Some accused them (and the oil companies) of inhibiting any efforts that moved us away from gasoline-powered vehicles and toward more fuel efficient or alternative technologies. But to their credit, the car companies eventually came around.

Today we’re seeing more and more hybrid and electric cars on the roads than at any other time. You could attribute this to the rising cost of gasoline, the green movement, a desire to be free of the grip of OPEC, a general sense of technological progress and efficiency, or – if you’re like me – all the above.

At the end of the day, it’s a game of survival. Adapt or die.

Tesla

If you’ve been involved in an agile transition at a large organization, you’ve likely faced a similar fight. Not everyone is so receptive to change. Transitioning to agile methods requires us to evolve. As we look to do so, I believe one of the first areas to examine is the way our organization is structured.

The emphasis on projects has become huge, and as a result, we’ve seen an almost wholesale shift to the ‘balanced matrix’ structure. This is where departments (like Development, QA, User Experience, et al), and project teams work together. The authority sits predominantly with the functional managers of those departments, and to a lesser extent with the project managers (who typically work as part of a PMO department, reporting to another functional manager).  The projects are run by project managers who have limited authority. These project teams are ‘assigned’ folks ‘temporarily’ from the various functional managers for the duration of the project. Once the project is completed, everybody goes back to their safe, little functional silo, or gets assigned out to another project team. This is how most software organizations have been working for the past decade or two. And this is considered by many to be a major improvement.

But this structure doesn’t fit well in an agile organization. In an agile ‘team-centered’ organization, the team is the crucial element, not the project. The teams are assigned projects. This is a fundamental shift to how we’re organized in the balanced matrix structure, where projects were assigned people.

The idea here is that when we allow teams to stay together and gel, they get really good at delivering. This team development takes time, and is necessary and inevitable in order for the team to grow, to face challenges, to tackle problems, to find solutions, to plan work, and to deliver results. Well-gelled teams know their strengths and their weaknesses. They have learned how to communicate with one another and to be more productive. The last thing we want to do is break up what has perhaps taken months or longer to create.

So, in a team-centered structure, Team 1 might have a product owner, scrummaster, a few programmers and a tester. Other teams could have a similar makeup depending on the size of the effort they’re working on. Many larger organizations have the additional roles of chief scrummaster, chief product owner, chief technical owner, and chief QA, but they sit outside the teams – mainly for support purposes.

You’re probably thinking to yourself, “This all sounds good, but where did the functional manager and project manager roles go?”

The project manager role no longer exists as it once did. Many PMs become scrummasters or product owners on scrum teams. If they’re not a good fit for this type of environment, they often become coordinators or managers of larger cross-team integrations, managing things like logistics, scheduling and tracking.

Functional managers no longer delegate work to teams in scrum. They play more of a mentor role… a servant-leader to the team, helping them to grow, learn and get better. As we know, scrum teams are self-organizing. They don’t need to be told what to do or how to do it. Teams look to scrummasters for guidance on things like standards and helping to resolve impediments.

If you’ve changed to a team-centered structure, what has been your experience? Have roles changed as well?

This entry was posted in Agile Management, Agile Teams, Scaling Agile, Scrum Development, Scrum Methodology. Bookmark the permalink.

One Response to The Team-Centered Organization

  1. Brian Irwin says:

    Good post, Michael. The matrix organization was created primarily to optimize allocation by functional skill. If you’re a developer, you may develop on multiple projects. But, optimizing this way is archaic and does not address one of our most pressing issues in today’s environment – quick value delivery to the customer and the ability to change direction quickly. In fact, what often occurs is the creation of unnecessary dependencies between projects that may not be related at all. People become the dependency. This is done quite unintentionally but at great risk. What should be done is to pay attention to workflow through an organization; not on optimizing everyone’s time. Organizations are needlessly sub-optimizing their delivery capability.

    The one caution I’d have is how to approach the PM role. People have often spent years getting advanced degrees in project management and many actually love their role. Organizations need to consider people’s situations and approach them with empathy. Helping them through the transition is a lot of work but it can turn them into amazing champions. Unfortunately, organizations can become myopically focused on processes and their adoption and give only a small afterthought (if any at all) about how to address the “individuals”. Wait – I seem to have read something about that somewhere, where was it? Oh yeah, never mind. :)

    Great post! You always hit it out of the park.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>