Static Teams Are Costing Your Business Money

Introduction

As an Agile enthusiast who works with teams to improve their development processes, I am continually mystified by the lack of creativity organizations seem to have when it comes to devising team structure. Fred Brooks in his seminal work "Mythical Man Month" identified communication as a key component to working through development tasks, yet it seems many organizations work effectively against better communication. On what basis do I make this claim? Because of the ubiquity of tools to do the job of communication for us. Slack, MS Teams, Discord, email, Jira comments, Google Docs, Sharepoint, etc. Asynchronous communication tools have replaced our interactions with individuals exactly contrary to the first value of Agile. What seems like a solution to the communication problem is actually a standardization of the communication gaps between teams and individuals.

Another significant reason I say organizations are working against better communication is the way many organizations structure their teams. It seems common wisdom is that team cohesion and high performance is a result of teams that remain together for longer periods of time in an environment that fosters camaraderie and fun. However the evidence suggests team cohesion and high performance happens as a result of skill inter-depency (aka cross-functional teams) and clearly defined attainable goals (Kozlowski and Ilgen 2006). There is no reason to believe these two items cannot be done with short lived teams.

Static vs. Short-Term Teams

Static teams have a lot of downsides. Institutionalized knowledge, burnout, communication gaps, underutilized personnel, and group think. Instead we want in our organizations a diversity of thought, consistently high value deliveries, fewer impediments, intact coherent contexts throughout the building phase, and a dynamic environment for developers to remain excited about their work. Using short term teams organized around delivering high value functionality is an easy way to achieve all of those things.

By keeping teams short lived the scope of their goals must remain small and achievable. Short lived teams create an environment of continuous change and new challenges to tackle which eliminates burnout. Group think is no longer possible at the team level (but still possible at the institutional level). It is much easier to align the talents and skills of the development staff with the most valuable deliveries. The list of benefits goes on and on.

Task-Forces

As a result of my work, thinking through this idea more thoroughly, and reading about Just-In-Time Inventory Systems (Lean), I developed a process I call "Task Force Driven Development". The idea is fairly simple. Align a technical lead to a specific domain. Have the technical lead collect the details of a feature request. Write the feature request as a set of user stories. Decide which skillsets will be required to complete the feature, and assemble a task force around those required skills. The size of the team can be adjusted to account for cross-training by adding novice team members to the domain, deadlines that must be reached, or corollary skills such as documentation, sales, and IT management.

The assembled team can then review and revise the user stories, detail the acceptance criteria, and begin working on the feature from beginning to deployment. This keeps the context of the feature in tact throughout the entire process and eliminates communication gaps that would otherwise exist between teams.

After the feature is delivered, a retrospective can be conducted to review the process, and the task force can be released back into the talent pool for the next delivery. Between deliveries the developers can work on building their skills, technical debt, or innovation spikes.

Benefits

You can see how this arrangement of personnel aligns directly to the value streams of the organization. It is then easier to assess the available talent pool and determine what, if any, new hires you will need for upcoming projects. Onboarding of new employees is simplified. Institutional knowledge is shared among a vast number of developers without the requirement of expensive tools to facilitate communication. The bus factor is eliminated. Vacation time is much easier to schedule around. Etc...

This also allows for a flatter hierarchical structure to the organization. Technical leads are the primary connection between customer and team so there should be at least two technical leads that are aware of the domain work. The backup technical lead could be a senior developer who is on the development team and has some experience with the domain. This helps keep the hierarchy flat so that we do not require a lot of mid level management to acquire and maintain project requirements.

Keeping the hierarchy flatter improves cost efficiency, puts the decision making closer to the problem source, provides more freedom of exploration, prevents an us vs. them mentality, and communication improves. The fewer rungs down the ladder an idea has to travel the less distortion the idea has when it arrives at the development team.

Cautions

There are plenty more benefits to having shorter lived teams that align to the highest priority items, but you may be wondering what some of the downsides are. I would be remiss if I didn't explain some of those challenges.

Perhaps the biggest challenge is the time it would take to collect requirements and form a team. That requires special attention. A technical lead can maintain a list of features several iterations in advance so as to keep the needed work fully prepared. The formation of the team requires some thinking so I'll tackle that shortly, but needless to say there are several ways of making team formation very quick.

Another challenge to short lived teams is prior work being revisited. This is not a novel challenge to short lived teams since most teams struggle to tackle refactoring legacy code, the challenge is in institutional knowledge needing to be shared across task-force formations. The easy default is to document carefully the work being done, which in and of itself is not a bad byproduct that should be done anyway. However timelines often require quicker solutions.

Instead practices like Test Driven Development, small commits, and careful adherence to the Single Responsibility Principle should be employed. If refactoring legacy code is a significant problem for task-forces, it's actually an indication of prior bad practices that are now being exposed. The code must be legible so that at any time it can be refactored. The code must be deployed in small batch sizes to that reviewing previous changes to the code is easier to follow from commit to commit. Dividing the logic of a routine into smaller pieces that are well named helps with the readability. All of these things should be done regardless of the length of time a team stays together. Task forces merely expose this problem if it exists.

One last challenge you will hear is that of an environment that changes too frequently. Some developers prefer working on a particular domain for longer periods of time. The organization must find a way to accommodate these requests while still following a short lived team model. The simple solution is for the technical lead to continually bring those individuals onto the similar domain feature requests. However be weary of institutional knowledge not being properly distributed. That developer who prefers staying within a specific domain will become less aware of the corollary features being worked by other task forces.

Be sure to set the precedent early that the developers are working in a dynamic changing environment. As long as the precedent is set it will become the normal. That would then make static long-lasting teams an oddity.

Team Formation

As mentioned earlier, team formation must be swift in order to keep the flow of the work fast. Teams must be banded and disbanded in rapid fashion. There are a couple of ways you can achieve team formation; hand picked by the technical lead, or self-assignment to a task-force. The second is the most preferred as it allows for the developers to decide for themselves which work they want to do. However this can be tricky if some of the work needing to be done is less appealing.

Before we solve for the less appealing work, it should be noted that if the work isn't appealing the value of that work should be evaluated. Developers are typically very good at detecting "grunt work". This kind of work is often laborious and not actually providing value to the customer. Technical debt items often fall within this category. If that is the case, then once again your attention should be turned to the practices each task-force is employing to avoid technical debt in the first place. This is a feature of Task-Force Driven Development, not a bug. Those problems should be exposed and a source of pain, that's how you know you need to solve it. Just be careful to solve it within the system and avoiding the bad practices discussed earlier.

When a new feature is needing to be worked a simple rank-order system can be put in place to ensure even the least exciting work will still be completed. Technical leads can post "job openings" for each upcoming feature with a specific start date in which that job will begin. Those job openings should detail what the feature is, what skills are required, and an optional approximation of how long the task-force will be together. This time should be very very short since the feature should remain small. Again, this is a feature, not a bug of TFDD. Technical leads should keep feature requests very small (thin vertical slices) so as to be more precise with their timelines.

Be Weary of Timelines

Although timelines are possible, an emphasis should not be placed on them. They are most useful in helping to determine when the next feature can be worked, not as a delivery timeline mechanism. Organizations have an affinity toward arbitrary deadlines that have little to no practical use. "When will this feature be done" is perhaps the most common question management will ask of technical leads. This is a bad practice as it applies pressure on task forces to forego practices that ensure quality. It is akin to asking them to cut corners and produce an inferior product. If you do not want an inferior product, do not adhere to deadlines.

That being said, there are obvious cases where items must be completed before a particular time due to regulatory compliance or manufacturing processes. In such cases those features that must be done by those points of time should be of the highest priority for the technical lead. A technical lead may also form larger sized task-forces. As long as the size of the team is set early we do not run into the Brooks Law. But that is ALL that can be done about it. A team cannot work faster without compromising on quality and resources cannot be added later in the development process without actually causing a work slow down (Brooks Law).

Converting To TFDD

So how do you adjust your organization to embrace Task-Force Driven Development? Identify your value streams, assign at least one technical lead per value stream, and slowly disband your currently existing teams after their current work is complete (end of an iteration). Then have your technical leads draft up some "job postings" around the very same backlog items that already exist for those value streams. It's really not a hard conversion to do. It simply must be communicated well.

A town-hall style meeting should be arranged early to help the teams understand the new structure. Feel free to use this article as a guide to articulating that new structure. Most of all, you must remain confident in the developers ability to adjust. They are a group of smart engineers you have assembled. Highlight the fact they will be able to choose their own projects to work on. Highlight the fact they will no longer burn out working on only one domain. Emphasize the importance of knowledge sharing. And most of all, listen to them and their concerns. Address them completely. You may find a challenge that requires special attention.

Conclusion

Static teams are the norm in our industry and it's hard to understand why. Other industries implement short-term teams to fulfill customer requests all the time. Building contractors will sub-contract out work to various parties based on the building requirements. Surgeons will operate on patients with several different nurses and assistants depending on the needs of the patient and the type of surgery. I'm sure you can think of similar analogous industries where short lived teams are preferred.

Aligning your personnel to the value you need to deliver is the most important transformation your organization can undergo. Conways law says that organizations design systems that mirror their own communication (team) structure. The Inverse Conway Maneuver recommends changing your organizational structure to match the architecture you want to have. There is only one way you should want your architecture to be structured, and that is to deliver value to the customer most efficiently. Task-Force Driven Development is the tool to help you do that.