Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Jun 18, 2014 — Enterprise Agile Planning expert

The Team-Centered Organization

Enterprise Agile Planning

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.


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?

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us