Reorganizing Agile Teams

When you work you most likely will go through a reorganization at some point in your career. It seems that in some companies it is almost a habit to roll out the next reorg before the current one is complete.

I often wondered whether frequent reorgs are a good thing or a bad thing. Until a few years ago I thought that because people are affected reorgs should be kept to a minimum. After all there is always someone who looses and someone who wins in a reorg, isn't it?

My team has helped me to learn better. The current project is now almost 20 months old, and I can't recall all the changes we had in our internal team structure. Many different factors caused us to change the team structure. Let me highlight just a few of them.

Scope: While the overall project objective wasn't modified a lot, the plan for achieving it changed a lot. Starting with a huge legacy code base (over 3 millions LOCs) we thought that using tools was a good idea to move to a pure Java implementation. So we organized the team in several smaller groups, each of which attacked the problem from a slightly different angle. For instance one group focused on how the code base could be restructure, and a different group was looking into converting screens from an old implementation to the new one. In doing this we learned that the automatic conversion wouldn't work for us for various reasons. So we decided for a new plan, and luckily we had the management support for now rewriting the application from scratch. Not an easy thing to do for a small company! As a consequence we changed the structure. I can't recall any major issues on the people side. The team understood that we had to adapt how we worked.

Team size: In August 2006 our little company was acquired by First Data Corporation. After the initial issues that typically follow an acquisition were solved, it was decided to increase the size of our team, and we started hiring. At that point the team consisted of two groups and each of them worked mostly independent, but we rotated engineers once in a while to keep the architecture and design of the system simple, and also to promote reuse across the groups. With the increasing team size we have realized that we had to change again, and therefore we regrouped again. Now some of the groups are almost too small (just one or two pairs). However, we have currently 16 openings (see First Data Utilities' website) and so the groups will eventually have a good size again. It's too early yet to tell whether the new setup will work for us.

Team maturity: Initially we had three co-located subject matter experts. Over time as the team matured and the interaction between the subject matter experts and the software engineers intensified, we realized that the subject matter experts were becoming overloaded, effectively a bottleneck. So we added two more, and we plan for another one or two over the next 12 months.

These were only three examples of what leads us to adapt over time. In essence, we reorganized as necessary and we are much more flexible than in companies I worked with previously. So agile teams seem to be different in that sense too: They continuously search for better ways to develop software. This teams has proved that it is capable to not only adapt architecture, design, toolsets, process, and technology. They have also developed the capability of continuously assessing the team structure, trying something new, discarding things that didn't work, and keeping things that did.

In closing I'd like to encourage you, the agile leader, to try this with your team as well. It's not easy initially, but it works and pays off!