Dedicated teams are critical to the success of Agile projects, both in the short-term (this particular project) and the long term (the queue of future projects. A serious game on which I’ve been working shows this principle in action better than any words I’ve used to communicate this point.
I started working on the game because a lot of people struggle with the notion of dedicated teams. Even in cases when Agile has achieved a foothold in the organization, and everyone’s happy with the results, many people outside these teams may not understand or appreciate how big a difference team cohesion makes. There’s a difficult cultural shift from seeing teams as collections of individual “resources” to teams as people who need to learn how to work with each other in a particular domain. Therefore, the game is an opportunity to make this mental leap in less than an hour, instead of after months or years of expensive trial and error in the real world.
In this board game (the working title is Design Factory), you play the role of an IT executive, managing both people and projects. You can form up to three teams however you want, but at the end of the day, you have to satisfy three different internal customers, e-commerce, manufacturing, and finance. Every project is rated for the amount of value it creates for the organization, the base number of sprints it takes to complete it, the business domain in which it falls, and any specialized skills, such as security, that it demands. Some employees start with knowledge of one of these domains, and a precious few also have specialized skills. There are some precious high performers in the mix, too.
Once the game begins, you can take a limited number of actions each turn to either manage teams or projects. Hiring a new developer and assigning her to a team falls in the first category; changing the assignment and priority of projects falls in the second.
Shown in the diagram to the right is the amount of value that I generated, as our fictional IT executive, over four plays of the game. As you can see, there’s very consistent pattern.
In case you’re wondering, every project you complete adds between 1 and 5 points of value to the meager pool of 5 points with which you start. You have to spend these points to hire and train employees, which is why the cumulative value score can go down, especially in the early turns.
The strategy I followed in these games was, Build the teams, then manage the projects. During the first few turns, I didn’t worry about the project backlogs for the time being, as long as there was something in the queue for each team.
Even though new team members increase capacity, and often fill critical skill gaps, the game imposes some costs for changing team composition. You have to pay to hire new employees. Initially, new team members aren’t as productive as they will be later. If a new team member doesn’t know the business domain, there are additional productivity losses. (Eventually, the newbie will learn the domain from working on projects in it.) If no one has a skill like mobile development, you have to pay for someone to learn it, and you reduce their contribution to the team temporarily. You’ll happily pay these costs, as long as they pay off in the long term.
In both the game and real life, these investments clearly do pay off. The only decision that could seriously jeopardize your investment is if you tear down teams and re-build them gratuitously for each project. Even a team composed solely of high performers, if they have never worked with each other before, and never worked in the domain of the project, is less productive than a team of people of mixed skills, who know each other and the domain. Therein lies the difference between a high performing individual and a high performing team.