Sep 162014

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.


Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.


  2 Responses to “Dedicated Teams And The Agile Portfolio Management Game”

  1. avatar

    I’m currently wrestling with this challenges of forming and sustaining Agile teams within a complex, enterprise environment. We have far too many lines of business (value streams) to be able to form long lived teams around these lines so must find a strategy to address the various competing forces. Agile has been working for us at the team level but ironically the received wisdom (dogma?) of keeping teams together for long periods is actually holding back our organisational agility; we need something more for us to more effectively serve the business, something perhaps along the lines of “maneuverability” to quickly respond to changing market conditions, and ideally start anticipating them. I’d be interested in your thoughts on this.

  2. avatar

    If I understand what you’re saying, the number of business domains is significantly larger than the number of teams that you can form. For sake of argument, let’s say you have 10 teams and 20 lines of business. In this case, there’s still an argument for keeping the teams stable, even if they hop between different business domains, project by project.

    Teams generally face three knowledge hurdles, the business domain (processes, roles, etc., and also the systems generally used in that area), technology (“Does anyone here know mobile testing?!?”), and the team itself. It’s easy to underestimate the importance of the third form of knowledge — and sadly, many organizations do. When we estimate work items, do release or sprint planning, swap around tasks, and perform other regular activities, one of the biggest constraints on the team’s knowledge of the team.

    Is this the kind of story that has given us trouble in the past, no matter how easy it looks? Are there any hidden tasks that need to be part of our done criteria? What happens when Bob gets into a slump? How sustainable is the effort we’re talking about for the next sprint? The answers to these and thousands of other questions depend on the team’s self-knowledge. The less team stability, the less self-knowledge is possible.

    Military organizations are keenly aware of this problem, which is why they stress squad cohesion, joint training among units that will be working together, etc. Check out Sean Naylor’s Not A Good Day To Die for one of many cautionary tales about military operations that depend on people who aren’t used to working with each other effectively collaborating. If the military understands the importance of team cohesion, why don’t software professionals?

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>