Get certified - Transform your world of work today

Reorganizing for Agility I

For Matrixed Organizations

12/10/2013 by Anurag Prakash

Why reorganize for Agile

Waterfall probably came about with all good intentions. In some ways it mimics layered software architecture: Interface between the adjacent layers is clearly defined. There is clean delineation of responsibility. The matrixed org structure also has conceptual clarity. Functional teams are organized on the basis of their skills and managed by resource managers. For each project, the project managers borrow resources from the functional teams to form a project team. So where do the loyalties lie in this contract between different functional teams?

Let's look at how the project team runs: Since we are running Waterfall, the design is pretty clean. We can introduce some parallels where possible; e.g., the database and UI teams could be running at working on their deliverables.


Issues with matrixed organization

Missing product focus: Since each specialist team has a manager, the success criteria are usually very much skewed toward performance of the functional team. This may not always align with the success of the product as a whole, and it can result in:
  • Adding buffers to estimates and lack of openness
  • Setting deadlines for other teams and unnecessary competitive behavior
  • High cost of change administration as team representatives haggle (CCB, or change control board)
Project team dynamics: We may try to mitigate the drawbacks by including a strong component of project manager feedback during ranking  and ratings; or we could give project management issues higher priority. However, a project team of specialists belonging to different functional teams will suffer from:
  • Complicated communications issues (cross-functional behavior will be difficult)
  • Complicated decision making (issues may be frequently referred back to functional teams)
  • Poor story sizing as team members defer to specialists (open discussion will be difficult)

Reorganizing matrixed teams

The simplest approach is to turn functional teams into "communities of practice." Moving the focus away from functional teams helps the organization become more focused on product and outcome.
  • Use communities of practice, which are without hierarchy and have minimal structure. Sharing of ideas, results of experiments, and new discoveries are discussed in an informal setting. There is no status to be given or yearly reviews to be done. This helps the professional development of the team, which is important for its sustained productivity.
  • Keep teams intact for as long as possible. Move the whole team from one project to another with minimal change. This will give the organization a good basis for release planning, because a stable team will have a reliable velocity number that can be used. In addition, people take time to develop relationships. Frequent changes negatively affect productivity.
  • Move ranking and review system to the project team and reward the team for productivity. It is important that we remember that different people come to work for different reasons. We need to align the product goals and team goals. Performance needs to be measured as a function of contribution to the end product and not relative to perceived technical expertise.
  • Encourage the team to be cross-functional. Everyone is welcome to pitch in if a test is lagging. Test folks are active participants in design discussions.
  • Embrace openness. It is important to feel psychological safety and to be able to admit to a mistake or challenge someone else's assumption. The importance of this point cannot be overemphasized. Reliable story sizing and good design decisions depend on it. Discovering dependencies early, during backlog grooming, depends on it.
  • Let the team come up with team norms. It helps team members feel good about what they are doing, while at the same time ensuring discipline. Empowering a team usually happens much more slowly than putting Scrum rituals into practice. We need to make the team feel as empowered as possible in return for openness and agility.
To be flexible and nimble, we need to have simple and effective team interactions. This requires the use of good engineering processes, such as using as much automation as possible for regression testing and release. Documentation as a part of acceptance criteria reduces refactoring costs. Good engineering methods also enable clean handling of the code base by multiple teams.

Road blocks

Nothing is ever easy. We must strive to find ways to make even proven ideas work. A perfect practice of Scrum rituals will buy us precious little, unless the culture changes to include openness and agility. Let's look at some of the road blocks to adapting the matrixed organization to product-focused teams:
  • While Agile teams are supposed to be empowered, it isn't easy to convince functional managers who will experience a loss of control. In addition, the organization will need to find an updated role for them. This is the major reason why ScrumMasters/coaches cannot change a company culture without the support of a high-ranking champion.
  • The team may be used to being assigned tasks day to day and may not know how to handle this new freedom. They may actually look for more structure, as when they were able to work as directed for eight hours and productivity was not their concern.
  • The product owner and the ScrumMaster(s) need to assist the team and not try to manage. Acceptance criteria needs to be thought out, backlog grooming support has to be regular. Any discovered dependencies need to be addressed as early as possible.
In my next article, I plan to discuss reorganization for agility as regards SOA architecture.