Agile Team Velocity and Forecasting

A long while back I wrote an article about “Increasing Velocity vs. Stable Velocity“. In that I listed a catalog of improvements that once done, could help make your sprint velocity stable. Of course the full list would probably never be realized as it’s unlikely teams would do everything. The reason I created the list was to give visibility of the many things an agile team could try. For some people, the list really wouldn’t have helped. Always easy to tell people what they could do but finding reasons and value for doing it is sometimes hard.

I wish here to talk about velocity and the business. Businesses have a tough time keeping their many shareholders and/or stakeholders happy with continuous growth and prosperity. One thing that makes all these people happy, or at least stops them from lynching the execs, is for the business to predict when things will happen with some accuracy. If you’re a software product company or a digital product company, the people you count on for this are your agile teams. The Product Owner manages the business aspects of sprint work while the development team manages the customer solutions. Combined into one agile team, the product owner and development team forecast what they’ll deliver anywhere between 0 to 12 months. This forecast is based on several factors but a key component will be the team’s past track record for delivery, their velocity.


Velocity is simply the average amount of work one team can successfully complete in one sprint. For most teams, this may take a few sprints to stabilize as the team finds itself through the stages of formation.

Velocity sits at the team level and does not translate to individuals on the team. If a team of 5 has a velocity of 40, adding another person doesn’t mean their velocity goes to 48. If the team’s velocity is 40 story points per sprint and a new person is added to the team, the team’s velocity is more likely to fall in the near term rather than rise. This is due to the disruption the new person causes in the team, needing mentoring, learning how to do things the “team’s” way, and the change in group dynamics (see stages of group development). So keep it simple and use velocity for the team.

The product owner

The product owner represents both the customer and the business within the agile team. It is the product owner who’s held accountable or at least responsible for getting the most valuable product features into the hands of the agile development team at the right time. They do this to meet both delivery (business) and customer demands. It’s the agile development team’s responsibility to match their forecasts with actual deliveries, scaled appropriately from near term (sprint) to longer term (release). All this needs to happen with regularity. All this can fail if the underlying forecasts are unreliable. The agile team’s velocity is the most reliable measure used during forecasting.

The single wringable neck

It often falls upon the product owner to meet promised delivery dates. This is strange because it’s not the product owner doing the work. The product owner relies on the development team to deliver. The product owner needs to manage business expectations once an agile release is in flight. This happens regardless of the reliability of the forecasts made by the team. However, the amount of effort and stress associated with managing these expectations can be mitigated if there’s a solid foundation to base initial forecasts on. The solid foundation starts with a predictable team velocity. Once a predictable velocity exists, product owners can begin challenging the agile team to achieve degrees of accuracy in their forecasts & estimates. For example, the product owner and development team might set planning goals as:

  • Get 85% or better accuracy between 0-6 weeks (sprints)
  • Get 60% – 70% accuracy up to 3 months (release)
  • Get 50% accuracy 3 – 6 months (release/future release)

Make success possible yet challenging

It may be the agile team has an unpredictable velocity, especially common with new teams. Asking a team to have an estimation accuracy of 90% for a two-three sprint window when the development team is barely at 35% is asking for failure. Instead if the team is at 35% accuracy, challenge them to achieve 45% within the next two sprints. But simply challenging the development team won’t be enough by itself, you’ll need to work with their Scrum Master to change the team’s current processes. This often means making backlog grooming sessions better.

The backlog

The product backlog is an example of a combining longer term strategic planning with near term tactical planning in one convenient place. The product backlog epitomizes the concept of Just In Time (JIT) planning. The product owner owns the product backlog and they, along with the development team, need to continuously maintain it. The product backlog is prioritized from top to bottom. It’s very common to think of the backlog as an iceberg with 3 distinct layers. The top layer is the bit of the iceberg that is above water, is the sprint ready layer. User stories here are the most refined and best understood. The product owner desires these stories to be the most accurately estimated to make sprint commitments viable. One grooming goal therefore is to get user stories to the highest state of readiness or ‘sprint ready‘.

The middle layer is populated with stories that are in planned releases including the current release but are generally less well understood. These stories are estimated but will likely be split into stories sized to fit within the sprint time box. As stories are split and new understandings are reached, they are re-estimated. Stories from the Release layer are feed into the Sprint layer as openings appear, based on priorities. This is a continuous process. A second goal of backlog grooming is to split stories down to a size that can be completed (Done) within the sprint time box.

The bottom layer but no less important are the stories for Future Releases. These stories might represent new feature or new products. These stories are the least understood and often are more speculative in nature. For example, a Future Release story might get dropped if there’s no customer support or the business ROI is too weak. Future Release stories feed into the Release layer as openings occur. The third goal of backlog grooming is to validate the customer/business value of new features, prioritize them, and allocate to releases as space becomes available

The backlog and velocity

Let’s get back velocity and see how the product backlog and velocity are inseparable. At the Sprint layer, the amount of work, usually measured in story points, is based on team velocity. For four teams working from a single backlog and the cumulative velocity per sprint is 135 story points, the Sprint layer might have 405 story point worth of stories (3 sprints X 135). (I recognize that skill levels within teams matter and I talk about cross-skilled teams at the end but for the moment, assume the work is equally divisible by team strengths.)

For the Release layer, velocity is used to project work capacity into the near future, often 1 to 6 months or one or more releases. Below is an example of a multi-release story map from Steve Regalsky of Winnipeg Agilist. Story mapping is probably the best way to engage the development team(s) and get realistic commitments using their own velocity metric.

For future release layer, velocity plays only a small part in that you can estimate these features or new products by the number of sprints they might require to complete. This is done in portfolio planning where costing is done at a gross level. It’s a good idea to use T-Shirt sizing at this level to abstract the estimate and help prevent any premature expectations. The question development answers is how many sprints would this feature or new product take given your current velocity? A guide to T-Shirt sizing could be:

  • Small (S) => 1 – 3 sprints
  • Medium (M) => 4 – 8 sprints
  • Large (L) => 6 – 12 sprints
  • X-Large (XL) => 9 – 18 sprints
  • XX-Large (XXL) => Unknown

It would not be unusual for one Future Release story to be enough work for one or more releases.

Tips for getting and using team velocity

There are several activities that can improve velocity but there are also a few things a team or business can do to help make team velocity useful.

  • Keep the team intact and constant. This means no swapping people in and out of the team on a random basis.
  • Co-locate the team. The team sitting together will build stronger bonds over a shorter period of time.
  • Be patient and give the team time to grow. They’ll go through the stages of group development over a period of time but give them that time. Use team building exercises such as Journey Lines to help them grow closer.
  • Engage the team with the business early. Get the team thinking solving business problems and customer problems is their responsibility.
  • Do not use velocity as a stick. The team’s velocity is for the team to use and improve. Enable the team to improve and trust that they will improve.
  • Have the team create and agree to what success looks like. The team needs a common understanding of what Done means for sprint work.
  • Maintain strict adherence to how velocity is calculated. In its simplest form, velocity is a count of work completed, averaged over several sprints.
  • Improve ‘T-skills’ within and across teams. The goal is to progress work, not have everyone equally skilled. Reduce reliance on specialist roles.
  • Focus coaching and training activities to areas that can improve velocity. Maximize the value of agile ceremonies and interactions within the team, not just doing.
  • Be honest. Only count stories that achieve a ‘Done’ status towards velocity. A story that needs 30-minutes in the next sprint to be complete counts for 0 in the current sprint.

Cross-skilled agile teams

If the agile teams are limited in their skills and unable to work any story in the backlog, this complicates things a little. Velocity can fluctuate wildly when work needs divided up based on skill. This can hurt if you have a team but no work for their particular strength. In practice this usually means stories are not worked in a priority order. For example, the backlog might have stories targeted for IOS developers and Windows developers. However, within these categories, stories would be in a priority (customer value) order.

The only realistic solution is to upskill the agile teams so a team can progress most any story in the backlog. This is achieved by building ‘T-Skills’. ‘T-Skills’ means although there’s depth in a particular discipline, the person has some capacity across several other skills. Teams can begin analysing their ‘T-Skills’ with a skills matrix.


A skills matrix can help identify areas where weaknesses exist. For example in the matrix above, we see that several skills have only one contributor. These would be prime areas to begin any cross-skill training. Having Sid pair up with Alice on occasion to build his Backend skills might be a good idea. This would make two people who can do Backend work although not with the same rapidity but does allow work to progress when the key person is unavailable.


The Goal Is Not Agile

You hear about and read about agile transformations, like this article about ANZ

“We need to break with some of the traditional 20th century approaches to organising and working to ensure we are more responsive to 21st century customer expectations.

“Moving to implement the agile approach at scale in our business is an important evolution in how we run ANZ which will allow us to respond much more quickly to customer needs, create higher staff engagement and make further improvements in efficiency” – ANZ CEO, Shayne Elliott

But what does agile transformation really mean? From the article, the goal of ANZ’s agile transformation is to specifically target customers which is a hopeful sign. If we look at the agile principles we see customer focus is essential:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

ANZ seems to be looking to improve employee engagement. This can be achieved by recognizing the agile team as equal business team members. They bring a different talent set to the table but they’ll be closer to the customer problem and potential solution than anyone else.

And lastly, ANZ describes their goal to be more efficient. This doesn’t just mean doubling output but doubling the value of each outcome.

ANZ has announced they will use agile as the tool to achieve the objectives. One can interpret from the article that the goal is not to be agile but to use an agile approach to improve and be better. Easy, right?

Although there are several aspects of an agile transformation, I’ll mainly look at it from the agile team’s perspective and how they can effectively change their working environment to embrace the agile culture.

Agile culture

Agile is a mindset or cultural phenomenon that is hard to quickly adopt when the culture is Hierarchical and Command & Control. The ANZ article says, “The transformation program will … shift to a less hierarchical organisation, relying on small, autonomous teams.” I’ve seen companies who take a different road in adopting agile practices to improve. They adopt agile without having a ‘agile transformation’, instead they test and experiment (see this blog post) with new ways of working and discover agile ways worked better than most. The common activity whether doing large-scale ‘agile transformation’ or using a gradual adoption is experimentation.

In the book, “Blue Ocean Strategy,” W. Chan Kim and Renee Mauborgne cite four hurdles a company will face trying to institute broad change:

  1. Cognitive – people must understand why the change in strategy and culture is needed
  2. Resources – changing an organization will require shifting resources
  3. Motivation – workers have to want to make the change
  4. Institutionalized politics – overcoming the way we do things around here

So where does agile fit into this picture? If your organization is doing waterfall or is rigidly hierarchical in nature or is Command & Control, all four hurdles will be a challenge. Agile as a tool won’t solve any of these challenges, in fact, it’s the opposite, these four hurdles will need to be overcome for agile to work best.

How agile transformation happens

Let’s assume for the moment that the organization is a typical C&C waterfall environment. Businesses can be successful with waterfall but that success can have limitations. These limitations primarily center around taking advantage of opportunities requiring speed and the ability to fine tune the product as you go through continuous customer engagement. When we choose to do agile it isn’t because we want agile, it is because we know the waterfall methodology we’re using won’t always work for us.

Why the need for change

Change can be driven for strategic or tactical reasons. The ANZ initiative seems strategic by drawing the customers and the business closer together. Another way agile finds its way into an organization is tactical, like when an important business opportunity comes along requiring very quick results with specific functionality and quality.

For either reason, agile and scrum may seemed the only way forward. There are rumors and anecdotal stories about how great scrum and agile are and for some businesses, the decision to try agile re-enforces one hard truth, “Necessity is the mother of invention” or simply:

Necessity drives innovation

The first hurdle in cultural change, Cognitive, is met: we understand the need to do something different to be more successful. In other words, can the waterfall business cite an instance where a new product is created and delivered in weeks, not months (or years)? With a win here, the business, will be competitively better positioned. The agile team, product, and the executives are convinced a change in strategies and culture are necessary but this understanding is not enough to cause change. Trialing any new idea or new practices is a good way to build confidence that a change will result in success.

Get the right people

For a trial project the business doesn’t engage all developers but only a select group. This trial project has a clear goal and a definite release date, neither can be changed. What can change is the scope (as long as the goal can still be met).

The Resources chosen for the first scrum team are special in their experience and talents. Although there are whole product teams that might be used for this new business opportunity, the business decides to build a new development team by cherry picking people from existing teams. The team might be hand-picked for a number of reasons which may include:

  • Years of experience – with experience comes confidence they’ll be successful.
  • People who are self-motivated – these are not people who sit around waiting to be told what to do.
  • People who are innovative – these people are known for their new ideas and abilities to think around problems.

Selecting people for the first agile initiative is often driven by technical expertise and their ability to solve problems. These people are asked to do something very different from their waterfall paradigm but they are more goal driven than most and change is less stressful to them. After a minimum amount of agile training, 45-minutes feels about right, they’re off.

The idea of shifting resources to get lean will happen without much thought. The initiative to be agile in this trial means traditional reporting lines are cut and the agile team reports directly to the agile sponsor.

The only real casualty will be middle managers who traditionally told the developers what they needed to do. With agile, we push this responsibility onto the team. But agile needs managers to clear away obstacles that slow down or prevent the teams from being successful. It’s only when managers can’t let go of their control over people that they become the obstacle.

Motivation for change

One ingredient used as a motivator is the challenge to be more successful. Using your business’s own track record might be the best evidence that change is required. It’s probably already clear that current processes and practices are not given to quick wins. A long decision chain slows things down. If the decision maker doesn’t like the choices available there could be lots of back and forth negotiations. All of this results in delays. What might not be clear is agile cannot change these circumstances. Agile is more mindset than physical and therefore it takes people to push for change. Agile becomes a guiding set of principles that you aspire to achieve. Arguably the most important of the agile principles after satisfying customers will be getting the development team and business in sync and working together as equals.

One very successful agile transformation I was involved in started with the business leaders meeting with the development team and restating the business problem not as leader-to-subordinate but peer-to-peer; the business has this problem and we need to work with you to solve it. We’re not intending to create an elite team but a team with strong mission understanding. This team wants to be successful and given the business or customer problem, business leaders are asking the team to solve these as best they can. In my experience, this will super-motivate the team to try new ways and explore new ideas. The best part is when the team completes the mission, they become the seeds in other newly formed agile teams. They’ll bring with them stories of both successful and failed adventures, but more importantly, they are the seeds to start institutional change.

Institutional change

“One of the things that limits our learning is our belief that we already know something.” ― L. David Marquet, Turn the Ship Around!: A True Story of Turning Followers into Leaders

Changing the way ‘things are done around here’ is hard. If being successful is a motivator for change then it’s clear that the business needs to understand what processes, practices, and decision paths are slowing us down. It’s likely that processes created for a specific reason have bloated or the original problem has itself changed or disappeared. One way to make this work is to drop everything, then analyse each process or practice to get the essential value of it. For example, if a previous practice had the chief architect review the detailed design once completed, you might change this to the team does the detailed design together with the chief architect. Or maybe an architect needs to be a member of the team. Either way can eliminate a hand-off and a potential delay. The point is to streamline existing processes to capture the essence and intended value, not necessarily throw them away. Of special note are those practices and requirements which are generally non-negotiable such as security, quality, and regulatory. Adopting agile doesn’t mean putting the company or customers at risk. Be cautious and review & streamline these with the right people.

There may also be processes that can be made part of the team’s definition of done (DoD) checklist. For example, we had a governance requirement for high-level designs to be reviewed by a ‘design steering committee’. We made updating the high-level design part of the DoD. We didn’t have a written process for this but did have a checklist that served the development team. High-level designs were decided upon during grooming with the chief architect. Once these were documented the chief architect worked with the steering committee, allowing the team to get on with the business of solving customer problems.

Changing institutionalized practices will be a challenge. Changing institutionalized management structures and practices can be impossible. Changing management often means changing the way human beings see themselves. If you’re the manager of a product team and the team is now empowered to make some decisions you once made, or owning practices you once controlled, you might feel a loss, even if you know:

  • Decisions are best made by people who have the knowledge to make that decision.
  • Keeping practices current, efficient, and relevant is best done by the people who use them the most.

By empowering the agile teams to make some decisions and giving teams the responsibility to continuously improve their work practices doesn’t mean managers are obsolete. Managers are critical in setting the boundaries from which the teams operate. Management are the enablers for the agile teams. It’s management’s responsibility in an agile world to ensure the agile teams understand the boundaries, what decisions they’re empowered to make, what processes and practices they own, and, most importantly, management ensures the agile team has the knowledge and support they’ll need to be successful.

Success is about being better, not being agile

My first scrum team was successful beyond all expectations. So successful in fact that the CEO asked afterwards, why aren’t we doing this “agile thing” with all our teams? With that comment from the CEO, comes the first truth about agile transformations: it’s not about agile, it’s about being better. I would wager most CEO’s are less concerned with how or what you do to be successful than they are about being successful. The article about ANZ says “implement the agile approach at scale” which can mean many things.

In my situation, what agile meant to the CEO and the rest of the business was a different approach that included:

  1. quick feedback loops to make decisions,
  2. high visibility of progress and setbacks,
  3. highly motivated teams,
  4. the agile team’s focus on business goals,
  5. the agile team’s continuous engagement with customers, and
  6. the teams desire to solve customer problems with the customer.

All these things made the teams better, made the business better, and made the customers happy. These agile things could not have happen at the scale it did without change.

Agile Collaboration

Collaborate (verb) – to work jointly with others or together especially in an intellectual endeavor

Collaboration (noun) – the action of working with someone to produce something.

(Source: Merriam-Webster)

I was recently giving some training where I asked people if their work environment was open and collaborative. They answered yes. I then asked if they knew what the CEO, CTO, CFO, Marketing, Sales were doing that week. Most didn’t know the answer. I asked how much say and influence the development team had over the type or scope of product work. The answer was little to none.

We often work in environments that are considered ‘open’ and ‘collaborative’ yet we have small groups making all the decisions and passing them around like dinner invitations. We get a meal but little input into the meal itself. For better or worse, the development team is often told what to do through some hierarchy and given requirements with the expectation that these requirements will be implemented as is and on time.

Collaboration and culture

How familiar does this sound: You’re in a meeting trying to solve some problem. The manager asks for suggestions and you boldly give your opinion on how best to solve the problem. The manager is looking at you without expression, perhaps even staring. You finish your comment and the manager continues to look directly at you for a couple beats after you’ve finished. The manager then states the solution which has no relationship to what you just said or for that matter, what anyone else has said. The manager closes the meeting saying something like, “Great ideas and a great collaborative effort. Thank-you all for helping.”

Now some would say the manager took on-board all the ideas and arrived at a solution but more likely, the manager had already made a decision. The manager held a meeting to check if he or she overlooked something and gave the illusion of collaboration. This kind of behavior is not uncommon and in at least one place I’ve been, managers were expected to make all the decisions.

How your culture is set up can determine how collaboration will work. Think about how your office works today. In Steve Coats’ article, “The Conundrum of Collaboration“, he describes it like this:

Think of it this way. You are one of two candidates being considered for a promotion into a higher position. You have always looked for opportunities to collaborate and have been part of many successful achievements. The other contender’s profile doesn’t focus much on collaboration. Instead it highlights a string of great accomplishments that this person has been directly responsible for throughout his or her career. From what you know about how promotions have been determined in your organization, would you feel like you are in the strongest position?

Although the company culture can deter collaboration, Steve Coats goes on to state that people’s own sense of self is a larger barrier to collaboration.

Clearly there are things about an organization itself that impact collaboration efforts, but none of those are the number one reason that collaboration stalls. That reason is much more personal. It is self-interest. People frequently refuse to collaborate because they do not believe it is in their best interests to do so. And those organizational confines just discussed strengthen that argument.

Sure businesses want people to collaborate but the reward goes to the individual who achieved something. At one place I worked, the performance review rated how independent I was. The top score was “works independently”.  Asking for help can be seen as weakness; always working with others can be seen as a crutch. You can’t expect collaboration if there’s no reward for doing so.

The hero and the collaborator

The Agile Manifesto and Principles don’t tell us how to do software, it’s up to the facilitator and implementer to figure out how best to be agile. While agile doesn’t directly say that collaboration is required, the expanded responsibilities needed for a successful agile team means that collaboration is a necessity.

In most organizations there are identifiable heroes; those people the company can “count on” to make projects successful. While this sounds familiar to most it is also an illusion. The hero does it all except grow the team. If the hero is away or leaves then there’s likely a vacuum that takes time to fill because the development team haven’t been trained or encouraged to step up.

In traditional projects, the heroes are in constant motion, making decisions, telling people what they need to do, and genuinely doing their best to make the project a success.  If the project were less than successful, either schedule or budget weren’t met, fingers are often pointed, usually at development. The heroes are Teflon coated and any negative feeling usually won’t stick to them. One reason heroes can flourish is they have knowledge that others do not have. To maintain their status as hero, it’s incumbent for them to withhold certain knowledge. To be clear, they are not withholding knowledge that could be catastrophic if not shared; they are not about to allow the ship to hit an iceberg. However, they might withhold details of why the work is being done. Development teams are expected to write “IF … THEN … ELSE” and not participate in the broader question of ‘why’. But here’s the problem: the development team collectively has a vast amount of knowledge and experience that is left untapped and businesses should tap into this to grow. Agile would sacrifice the hero to get to this untapped resource.

The hero acts like a tourniquet; too tight and the limb withers and dies, too loose and the patient dies. If the hero holds too tightly to knowledge, the development team will feel less engaged. If the hero let’s go without priming the team, the inexperienced team will likely falter. The tourniquet is not the long-term solution but a stop-gap. The danger to the business isn’t the hero themselves but the over reliance on the hero to the detriment of others learning and growing. I’ve been in meetings where one person says they’ll do everything and everyone else steps back to allow them to proceed. A hero can help make the company successful but we’re not here to rest on our current successes, we want to be more successful. Having heroes can limit imagination and growth because you’re stuck with what the hero knows.

Collaboration and success

The need for collaboration can come down to how you measure success. If you’re being agile, success is measured by customer satisfaction and achieving business goals due to that satisfaction. In traditional software development, success is measured by completing the project plan on time and on budget.

To be successful in agile, everyone working on solving the customer problem needs to be aware of how the customer perceives their problem and what they feel is a solution.  This is the fundamental shift from traditional project management. Everyone involved in the solution needs to have a near-identical understanding of the customers’ problem. This necessitates collaboration with the customers, development, product, marketing, sales, support, and management.

Steps to improve collaboration

“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win”JFK Rice University 1962

“win just one for the Gipper” – attributed to Knute Rockne

“I have a dream!”Martin Luther King 1963

If you’re looking to improve collaboration, one could say simply change the company’s culture to reward collaboration but this is insanely hard. Besides, when was the last time something big happened because you ‘said so’?

Improving collaboration within a business and between teams requires finding the answers to these two questions:

  1. how does collaboration benefit the individual
  2. how do I collaborate more

Neither question has an easy answer and the details of the answer are wholly dependent on the environment. However we can look at some general strategies to answer both.

Benefit the individual

One thing that most people will agree on is an engaged employee is a happy employee. The first step toward engagement will be to trust the them and their team to collectively find solutions. This begins with the business establishing boundaries where the team can operate and make decisions freely. For a development team this probably starts with the product backlog and grooming the requirements/user stories. To be clear, it becomes the team’s responsibility to work side-by-side with the customers, users, and product people to appropriately understand and refine the work. The reward is the team gets more input to the product. As the team becomes more involved with the business of solving customer problems, the more skin they have in the game. The teams will spot pitfalls and opportunities much sooner, increasing the likelihood of success. Taken together, this empowerment to make decisions and the added responsibilities will:

  • create strong team bonding
  • increase the team’s sense of ownership of customer and business problems

This will also allow a team to fail earlier and make corrections much sooner.

Collaborate more

It’s very easy to tell people to collaborate, very hard to have valuable collaboration. When I worked with teams that were located in different cities, I arranged for two scrum-of-scrum meetings each week. I also set down an agenda that balanced high-level knowledge sharing (e.g. business/customer problems being worked & architecturally where the last and next changes would occur) with low-level implementation work so developers weren’t stepping on each other. These collaboration sessions were facilitated by scrum masters and one team in each city documented decisions and actions. We did the double documenting to make sure we all heard and understood correctly. As we progressed we adjusted these sessions to maximize the value and reduce the duration. We generally did them in less than 20 minutes.

To get the executives, senior managers, customers/users, and agile teams on a first name basis so to speak, we did inception workshops. A key activity for internal collaboration was a ‘who/do‘ table. This is based on the book “Gamestorming” by Dave Gray, Sunni Brown, and James Macanufo.

Through this table of actions, all stakeholders team up and commit themselves to achieving a successful result. While there are several activities that can be done throughout a project to strengthen collaboration, retrospectives for example, having this at the start sets strong expectations for all stakeholders. The ‘who’ on the list are actual names of people when needed or roles otherwise.

If the team has trouble identifying who they need to collaborate with, they can do a variation of the circle & soup game during retrospectives. This is a game usually used to identify improvements and problems that either slows down or blocks something the team feels is important.

  • Inner circle: “Team Controls” – what your team can directly manage
  • Middle circle: “Team Influences” –persuasive actions that your team can take to move ahead
  • Outer circle: “Soup” – Can’t control or influence: elements that cannot be changed. This refers to the environment we work in and must adapt to. Ideas from the other 2 circles can identify ways to respond to the barriers floating in our “soup.”

As well as identifying problems and how to approach finding a solution, the circle & soup game makes clear the avenues of collaboration. For those improvement items they ‘control’, these are the areas that collaboration is needed within the team and between teams. The items in the ‘influence’ and in the ‘can’t control or influence’ circles means collaboration with those people who own the area of interest. The different circles suggest that different tactics and collaboration skills will be needed.


What happens with the developer who only wants to write code and doesn’t see talking to users or writing user stories as enjoyable or desirable? Moving these people is hard and could be likened to moving the sofa across a floor. At first you’ll need to exert lots of force to overcome static friction but once moving, you only need enough force to overcome kinetic friction. However, there is a point when it’s cheaper to hire right thinking people for the team rather than attempting to change behavior. This may sound harsh but it needs to be done on occasion. When I’ve seen this it often benefits both the company and the individual. I’ve also seen where someone once removed from an agile team returns sometime later.


Collaboration isn’t natural behavior for people and is therefore something that must be practiced and learned. There are tools that can help, ‘who/do’ lists and ‘circle & soup’ games, but in the end management and teams must recognize collaboration adds a dimension of efficiency and speed to any endeavor. The business needs to setup the conditions where collaborating becomes natural. Managers and management have long been collecting information, filtering it, and making key decisions. Pushing decision making down to the people who have the knowledge will be a challenge for some managers. However, only management can begin the process of removing hierarchies from peoples’ minds and teach teams how to collaborate and how to behave to maximize collaborative results.