High Performance Agile Teams Have Problems

December 31, 2007

problem.jpg

Yeah, you heard me right. High performance Agile teams have a lot of problems. These clowns discover new problems every day. Every time they resolve one (which they do very aggressively), another rears its ugly head. And, believe it or not, they love every minute of it.

What’s wrong with these people? Where does this irritating habit come from? Perhaps a traumatic head injury? Is it some sort of deep seated neurosis that compels these folks to revel in the problems they discover? Surrounded by all these problems, you’d think these teams would be populated with those negative types who just can’t see the glass as anything other than half empty.

Not so.

A team that is constantly raising and resolving problems (or impediments) is likely to be highly effective. Not only are they continuously improving their process (Kaizen), they are also removing those things that slow them down. They are also continuously learning. They are uncompromising in their perfectionism – looking for even the smallest ways to improve their performance as a team.

So, if you are looking for the best performing team in an organization, perhaps you should be looking for the team that is finding and resolving the most problems!


What does it mean to be a “Cross-Functional” team

December 22, 2007

As a coach, I’ve encountered a great deal of confusion when talking to teams about building a cross-functional team. Often, as soon as I mention the notion, the reaction is negative. People often seem to think of cross functional behavior as every person on the team being able to do every job on the team. The impression that they get is that they are being told specialization is bad, and generalization is good. I believe this is often exactly what some Agile advocates are thinking when they talk about cross functional teams, but I want to paint a different picture.

I mean, generalization overall is a good thing. But we still need specialists. We are looking for the right mix of people with the right skills – not one person with all the skills. Everyone can’t and won’t be equally good at everything.


Tom’s Catalog of User Story Smells

December 20, 2007

Here are a few smells I’ve encountered while working with user stories with different customers:

  1. One word stories
  2. Technical stories
  3. Stories missing goal
  4. Stories missing user role
  5. Stories specifying architecture
  6. Customer doesn’t understand stories
  7. Boring stories
  8. Too many stories

For each story there is a symptom and a related discussion of the problem:

One word stories

Symptom: Stories are just single words jotted on a card with no description or explanation associated with them.

Discussion: Although stories are “Intended to be a placeholder for a conversation” it is possible to stretch that notion too far. It’s easy to see how a product owner might think that they have a mutual understanding of the issue with the team – so much so, that they neglect to describe the story sufficiently. However, it’s critical that the story provide some simple context, some simple statement of action. A disciplined team sticks to the format: As a <user> I want to <do something> so that <I can accomplish goal>.

Single word stories can also be an indication that the team is writing the stories for the product owner.

Technical stories

Symptom: The story is written in completely technical terms that have no meaning for the customer or the business domain.

Discussion: This is probably the most common problem with user stories. Technical stories that refer to layers of architecture, or specific technologies are completely opaque to the customer. The customer finds it hard to understand the value of the activities if they are not written in business terms. If you go to a review meeting, ask the customer/PO to accept the story and they say, “I don’t know what that means.” Then you have a technical story.

Technical stories are also an indication of another smell: Customer won’t write and prioritize stories. As a result, the team ends up writing stories that make sense to them – technical stories.

Stories missing goal

Symptom: Stories contain user role and feature, but there is no explanation of why the user would want it.

Discussion: Incomplete stories of this type are quite common. The goal is what can provide context for the rest of the story. Often the goal is an expression of the value the feature has to the user. Often an inexperience product owner will neglect to put the goal in a user story.

Stories missing user role

Symptom: Story contains a description of the desired feature without a reference to the user role.

Discussion: Without knowing who the customer is, it makes it very difficult to understand the value a feature may have – furthermore, it’s almost impossible to assess the fitness of the feature to the user.

Stories specifying architecture

Symptom: The story contains references to architectural design or components.

Discussion: This is simply another version of a technical story. This comes up most often when there is a dedicated architecture team.

Customer doesn’t understand stories

Symptom: Customer/PO doesn’t recognize or understand stories

Discussion: It’s likely they didn’t participate in writing the stories.

Boring stories

Symptom: Stories sound stilted and without passion.

Discussion: This could just be that the stories aren’t well written and need to be refactored a bit. Another problem may be that the goal is not particularly compelling. Is this story prioritized correctly?

Too many stories

Symptom: The total number of stories in the product backlog has grown to literally 200, 300, 400 stories or more.

Discussion: This is waste. The team will very likely never get to those stories. When the backlog gets this large it’s time to prune it down to a more reasonable size.


What’s a Waterfall?

December 12, 2007

As an Agile coach and a trainer I often compare Agile methods to “Waterfall”. Waterfall is a bad thing. We all do it. When we are assessing a team, sometimes I hear people say in a desultory tone, “They’re just doing mini-waterfalls.” Typically when I think of waterfall processes I think of a project that is organized as follows:

Analysis ->Design->Implementation->Test->Release

Or something close to this (you may use different terms). Basically, we do this, then this, then this… and repeat. Typically this method is criticized as creating too much specialization, not enough collaboration, too many hand-offs, and so on. So far, none of this should be  a surprise to anybody. I can slap this sort of project together in MS Project in my sleep.

Now, let’s take a look at our Scrum task board. Here we see something similar to the following:

ToDo, Test Complete, In Progress, In review, Done

Interesting. In a typical case, can we do any of these steps out of order? No.  Can we skip steps? No. Hmmm…let me show you those terms one more time:

ToDo->Test Complete->In Progress->In review->Done

Oh, now that’s kind of interesting. It seems that the Agile process that we are using to track our tasks looks remarkably similar to the Waterfall process. But that can’t be right! Let’s put them side by side and see if we can find a difference:

AGILE:                 ToDo->Test Complete->In Progress->In review->Done

WATERFALL:    Analysis ->Design->Implementation->Test->Release

Oh nuts! Now I’ve really done it. Perhaps its a matter of scale. Perhaps its a matter of the order of magnitude difference in the activities. Or…perhaps using the “Waterfall process” is a straw man that we shouldn’t really be using when we talk about the benefits of Agile. Perhaps the greatest difference between how things are done on an Agile project, and whatever folks have done in the past is not in the order that the tasks are completed in. You can rename the tasks, reorder them all you want. But you still end up with the same thing. Call it something different, “a mini Waterfall.” If it makes you feel better, great. But my argument is that this is not the key difference between Agile and other methods. The difference lies someplace else, not in the ordering of the tasks – because, if we just compare the ordering of the tasks, guess what? Agile and Waterfall look the same.

Maybe I’ll sleep on this tonight and look back on this tomorrow and regret it. After all, I’m a good little ‘Agilista’ and I don’t want somebody to stamp my meal card “No desert”.  Perhaps I’ll go back on my medication tomorrow and realize that this was all a hallucination. But somehow I doubt it. If we are looking to explain to others how doing an Agile project is different than others, perhaps we should avoid this comparison and focus on other differences.


Top Ten Ways to Destroy Agile Teams

December 11, 2007

There are a few disruptive corporate behaviors that have been bothering me for a while. Forgive me for a moment while I get them off my chest. If you have witnessed these disfunctions, I’d be curious to get your perspective on them. Here are my top 10 ways to destroy an Agile team.

  1. Break apart the team when the current project is complete
  2. Keep the individual/team compensation plan a secret
  3. Don’t openly share financial data with the team
  4. Lay people off on a periodic basis
  5. Refuse to aggressively invest in employee training
  6. Keep the team ignorant of corporate goals and plans
  7. Do not allow any “slack” time
  8. Always cave in to the demands of the customer, regardless of the impact to the team
  9. Allow the customer to “cherry pick” the team members they want
  10. Ignore the skill set of team members when building a team (“Hey, aren’t we all cross functional?”)

Hey, I feel better already! Some of these things may seem pretty obvious. Others may may be more difficult to understand unless you happen to be wandering around in my skull (a dangerous neighborhood for sure…).

Breaking apart the team

Boy, for some reason this is a controversial topic for executives and resource managers. To me, it just seems obvious – if it ain’t broke, don’t fix it! Yet for some reason many managers feel compelled to reorganize teams on a regular basis. They cite reasons such as:

  1. Moving individuals to different assignments is easier than moving whole teams.
  2. Teams get ‘stale’
  3. The company can’t afford to keep all the good people on one team

The way I see it, a team is greater than the sum of its parts. Based on my own experience, getting a good team that gels well and performs well is very rare. So when someone from management claims that it is ‘easier’ to move individuals than teams, I feel like they don’t really appreciate what goes into making a good team. People simply aren’t fungible resources. That notion is one of the fundamental mis-understandings in the development world. You can’t replace Joe with Bob and get the same work. Sorry – it almost never happens that way.

Alternatively I’ve heard the claim made that a team is getting ‘stale’. Team members are too comfortable with each other, and they aren’t pushing each other to excel. Therefore we need to break apart the team and try another combination. Possibly, but I doubt this for two reasons: First, I’ve yet to meet a team where being ‘too comfortable’ was a bad thing, and second, making this a decision outside of the team is basically making a command and control decision without the participation of the team. It’s up to the team to improve themselves and it is up to the product owners to hold them accountable.

Finally, the notion that all of the talented engineers can’t be on one team is a great example of a team that becomes a victim of it’s own success. First they become a high performing team, then they are well respected within the organization, then people start to say, “hey, we need some of that talent over here!” Again, based on my experience, it is very difficult to build a truly high performing team. Once you have one, the worst possible thing you can do is break it up. Instead, use the team as a model for other teams. Find out what it is about the way that teams works that makes them so successful and then emulate it.

So, despite what may seem to be rational objections to keeping teams together, I think there are few things that are more important to a team. Any organization that finds itself reorganizing the teams over and over again is very likely going to find it extremely difficult to succeed at Agile. They are more likely to find themselves reinventing the wheel over and over again. Forming, Storming, Norming, Forming Storming, Norming, Forming, Storming…ad nauseum.

Keeping the Individual/Team Compensation Plan a Secret

The fundamental problem with this is that compensation is never really a secret to anyone on the team. Everyone finds out sooner or later, whether it’s over a beer one night, or in a back room bitch fest. If we can accept that, then we have to realize that openess and transparency are a much more”Agile” solution to the problem. If everyone knows that they are fairly compensated, then they don’t care as much how much someone else gets paid. If they are not fairly compensated (or perceive it) then they are going to be unhappy. I would rather have that unhappiness out in the open. I want to have those difficult conversations within the team. If the team is going to be expected to be self-organizing, then they ought to be given the ability to control their own expenses – and this includes their own salaries. Let the team work it out – not the managers. I know it’s a wacky thought, but I think it might create more dedicated investment in the success of a company by the team if they were to manage their own salaries (within a budget).

Don’t openly share financial data with the team

Now to me, any company that isn’t willing to open their books to their own employees probably doesn’t trust them. That mistrust doesn’t go unnoticed. If the company wants the team to feel like “were all in this together” then they should share this information. I’ve only worked for one company that didn’t share financial data with their employees, and I hated it. Frankly, I want to know if the company is going down the tubes, or conversely if it is doing extremely well. I think my rule of thumb now is not to work for companies that aren’t willing to show you how they are doing financially on request.

Periodic Layoffs

Ugh! This is a no brainer. Any company that shows a regular pattern of layoffs is never going to be able to create a decent environment for Agile teams to grow in. Layoffs create an environment of fear and distrust. I understand that layoffs are a fact of life in today’s economy, but I don’t understand how companies can do it repeatedly – that just screams “bad management” to me.

Refuse to Aggressively Invest in Employee Training

To my way of thinking a highly educated workforce is an Agile workforce. Having the discipline and drive to engage in continuous improvement has to be something that is motivated at a personal level. Anyone who is constantly seeking to improve their own knowledge is very likely to be the kind of person who can best motivate continuous improvement. Unfortunately, more often then not, I see training given only lip service by executives and resource managers. It’s very rare that a company shows a serious commitment to it.

Keep the team ignorant of Corporate Goals and Plans

I know. It sounds so silly. What kind of company wouldn’t share their goals and objectives with their teams? Well, it turns out that a surprising number of organizations are like this. They stumble along and wonder why it is that their teams never really get very productive. It’s because the teams don’t understand where the company is going. You end up with 5 different teams going in 5 different directions. The ensuing chaos is fun to watch, but doesn’t help anybody.

Do not allow any ‘slack’ time

OK, I admit it. I’m a big fan of DeMarco’s book. If you are looking for innovation and evolutionary improvement, then you need to allow things to mutate a bit. You need to allow a little bit of randomness to creep into the process. Individuals who have hands on the keyboard all day long are not going to have any time to innovate. Frankly, their not going to have enough time to learn or do much else either. Focusing on development work as exclusively the activity of coding is ultimately counter productive. There is a whole host of different activities that go into creating great sofware – exploration, experimentation, pacing around the room, working with colleagues on the white board, playing with the desk toys – these are all legitimate activities that are not just necessary, but required to develop good software. Human beings don’t function well at 100% – give them a little slack, say 25% and you will probably get a much better result.

Always Cave in to the Demands of the Customer Regardless of the Impact to the Team

Part of me thinks this is petty, but it happens often enough that I can’t ignore it. Let’s face it, some customers can be a real challenge to deal with. Often times the Scrum Master/Coach spends as much time defending the team from interference from the customer as anything else. It’s a tremendous drain, but it’s what you have to do with some folks in order for the team to be successful. However, you can destroy this when an executive gets involved who is more interested in the money than how his team is treated. I’ve had execs walk in and cave into customer demands – usually fickle demands to satisfy their egos. Afterwards, the Scrum Master is left to go tell the team, “Sorry guys, you have to just suck it up and work 100 hours.”

Allow the customer to “Cherry Pick” the Team Members that they want

This is totally disruptive to an Agile team. I’ve had product owners who just felt like messing with the team. I’ve had customers worth millions of dollars to the business who decide they must evaluate individual contribution on the team. It is one of the worst forms of micromanagement that you have to deal with. My answer is a flat, “No.” You want a team, you take the one you get and hold them accountable to deliver. There are few things more disruptive and destructive than someone outside the team choosing the composition of the team.

Ignoring Skill Sets of Team Members when Forming a Team

There are some people, who feel that everyone on a team should be equally good at everyone’s job. This is a misunderstanding of the meaning of a cross functional team. Don’t get me wrong, cross functional people are nice to have, but nobody, and I mean NOBODY is equally good at everything. Don’t ignore people’s strengths when forming an Agile team. Don’t rob yourself of the best talent because you are looking for a “jack of all trades”. There is a reason that it is called a “Cross Functional Team” and not “Cross Functional Individuals“. Think about it. I say this because I have been on projects where I had lots of talented developers who loved Agile, but none of them had the skillset that we most desperately needed. Computer technology is unforgivingly specific. When you need expertise in a certain technology, you really can’t fake it. Well, actually you can, but it’s damn slow.


Type 3 Scrum – OK, now I get it (finally!)

December 11, 2007

It took me a while, but I think I’ve finally grokked the difference between type 1, type 2, and type 3 scrum. These different types or gradations of Scrum were suggested by Jeff Sutherland, one of the originators of Scrum. Briefly, the three types can be rather simply described as follows:

Type 1 – Fixed gates: Standard, out of the book Scrum. Plan your sprint, run your sprint, review your sprint – rinse and repeat.

Type 2 – Overlapping gates: Plan your sprint, run your sprint with ongoing planning sessions (for upcoming sprints), start next sprint as first sprint winds down, review last sprint – rinse and repeat

Type 3 – Mini gates: Plan a feature as needed & start sprint (features can start anytime), when sprint is complete – review it.

The way I see it, with type 1 Scrum, you are starting off with the training wheels on the bike. Things are pretty strictly regimented. We want to get the team used to a time box (they need to learn how to scope their work effectively). We want to get the team used to frequent planning and frequent reviews (put the rudiments of a quality driven, inspect and adapt system in place). And finally, get them used to working with smaller batch sizes.

As a team graduates to type 2 Scrum, they have mastered the fundamentals of type 1 Scrum. Now they can begin to improve on the process. Planning becomes much more of an ongoing activity that never stops. We remove the hard start/stop constraint between sprints. We want to establish a comfortable rhythm where the team begins to blur the lines between the current sprint and the next. We keep the sprint planning and review though – we want that culture of continuous improvement to remain. We probably have a trend of the batch sizes for each sprint starting to get smaller.

Finally, As a team gets comfortable with type 2, they have reached a point of really significant maturity. Now is the time when we can look at the team and say, “What if we reduce the batch size to one?” One sprint has one story. We overlap as many sprints as necessary. Basically we are creating a state of continuous flow where there are always multiple sprints in progress. In addition we have driven the batch size down small enough that the inspect and adapt cycle is now almost continuous. Sweet!

Based on my own experience I know that a team would have a very hard time skipping from type 1 to type 3. It’s an evolution. I also think that it is remarkably similar to other systems like Kanban – after a while I guess they all start to look the same in some respects.


Hanging My Test Driven Christmas Lights – A Retrospective

December 7, 2007

OK, so by now, many have read my first missive regarding my annual sado-masochistic ritual of decorating the house for Christmas. I’ve just finished the whole embarrassing production once again. Time for a little retrospective:

So let’s start by reviewing our objective…

Goal: To win the Elf Award for the best Christmas lights in my subdivision so that I can revel in the glory and adulation of my neighbors and idle passers-by.

What Went Well:

  • More lights than last year
  • Key display items repaired (“Frosty is back!”)
  • Ten Fingers, Ten Toes, Skull still intact, No broken bones
  • No visits to the ER
  • Fewer unexpected blowouts – improved quality
  • Still married

What Could Change:

  • Casualties: 3 fingernails & one stapled thumb
  • Work more closely with the product owner
  • Get approval for changes to the lighting scheme BEFORE implementing

All in all, this year’s lighting experience has been much better than last year’s. There are a few things that might explain this success beyond what I talked about last year. This time I did the work in much smaller chunks instead of trying to do everything in one day. This made the physical exertion seem much less.

I should have gotten approval from the product owner for smaller increments of the work. I had a few scares where my wife came outside, looked at the fruit of my labors, and said, “You’re NOT going to hang icicle lights on the tree are you?”

Of course not, Honey…

Of course the real approval for this release will come from the judging committee when they hand out the Elf Award. Maybe I should bake some cookies for the committee? Should I greet them at the door wearing a tie? Should I write an acceptance speech? Stay tuned.


Agile Planning Tools

December 5, 2007

A few notes on this list:

I tried to collect just the tools that are written specifically for the purpose of Agile planning. I know that a lot of teams use 3×5 cards and/or Excel for tracking and managing their projects. However, although you can use Excel to manage your planning process, Excel was not created with Agile planning in mind. So Excel doesn’t belong on this list. There are plenty of planning products that make the claim of being compatible with Agile planning. For instance, Microsoft Project has a Scrum plug-in. But MS Project was never really intended to support Agile planning. And if I may be so bold, the support it does provide sucks. So I have left out products that are basically Gant charting tools that some might consider using for planning Agile projects.

This list is by no means comprehensive. If you are aware of additional products that I have missed, please let me know. So here they are in no particular order:

  1. Rally
  2. Scrumworks
  3. XPlanner
  4. Mingle
  5. VersionOne
  6. TargetProcess
  7. xProcess
  8. Extreme Planner
  9. ProjectCards
  10. CardMeeting
  11. XP Story Studio
  12. PlanningPoker
  13. Acunote
  14. SilverCatalyst
  15. PlanB

I learned a few things researching this list. First, everybody and their cat has a planning tool these days. It was only a few years ago that there were only a handful of products available if you were interested in a tool for planning Agile projects. Now they are a dime a dozen. It’s starting to look like a pretty competitive market. There still seems to be a healthy mix of open source and commercial applications, so alternatives are available to fit whatever budget you have (or don’t have).

I’ve provided some minimal information with each product so that you can investigate them yourself. For those of you who want the “Cliff’s Notes” summary, over the next few weeks my plan is to write reviews for these products. Some of them are products that I have used before quite extensively, others I will install and try out.

Stay tuned.


Rally vs. Scrumworks

December 4, 2007

My first impression is that these are two applications that have come from very different backgrounds. ScrumWorks started off as a java based desktop application. Rally is based on an ASP model where the application and data are all hosted at a remote site. Both applications have grown their feature sets over the last two years with what appears to be 2 different objectives in mind. Rally has taken the approach of adapting to a wide range of customer needs, both Agile and traditional. Their goal seems to be to reach the high end customer and integrate with existing high end systems on the market. Their feature set is very broad and has been adapted to fit in a variety of different scenarios. In addition, Rally has also significantly beefed up their integration support in the last two years. There is no doubt in my mind that when it comes to integration and customization, Rally is the clear winner.

ScrumWorks, on the other hand, has kept focused on a goal of serving just the Scrum and XP community. As a result, they have a much narrower feature set that is easier for the typical Agile team to understand. This is just speculation on my part, but I think it doesn’t require as much training to use ScrumWorks. I would describe the ScrumWorks product as more fit for a specific use – in this case for Scrum and XP projects.

In general, when it comes to ease of use, ScrumWorks benefits from the fact that it has a thick client that can take advantage of OS features that web based applications can’t do quite as easily (Drag and Drop, etc.). So in terms of usability, ScrumWorks is currently the clear winner. However, Rally is not resting on their laurels, and they are implementing new usability enhancements that will quickly come to rival those of ScrumWorks in short order.

When we look at reporting functionality, ScrumWorks comes out ahead. ScrumWorks has a custom report generator utility that allows you to create your own customized reports. All of Rally’s reports are fixed and can’t be changed or added to. Once again, Rally is acutely aware of this issue and not likely to let it rest for long.

Cross Team & Program Management – Both products claim to have some cross team and program management features. Neither product really possesses a strong feature set in this domain. Rally defines a program as a combination of a specified product and a specified release – a very loose definition. ScrumWorks uses a separate mechanism that is completely orthogonal to the Stories and releases – instead you can create arbitrary groupings of features which can represent programs. This is a more flexible approach, but it still doesn’t provide the financial tracking features that I would expect from a full fledged portfolio management tool.

Detailed Feature Comparison

Feature

Rally

ScrumWorks Pro

Desktop (Fat) Client

No

Yes

Web (Thin) Client

Yes

Yes – Not all desktop features are available on the web client

Local Database

No – hosted by a 3rd party

Yes – Built into the default installation

Impediments Log

No

Yes – Tracks dates, resolution, and responsibility

Records blocking issues

Yes

Yes

Burn Down Charts

Yes – Sprint Burndown/Cumulative flow, Release burndown/cumulative flow, Bug & Test Tracking

Yes – Mike Cohn style ‘enhanced burndown’, Sprint & Release burndown

Customized Reports

No

Yes – Customizable report builder GUI

ROI and EVA

No

Yes

Time Tracking

Yes – optional

Yes – optional, but supported with custom reports

Supported Object Types

Release, Sprint, Story, Task, Test, Program, Defect, Defect Suite

Release, Sprint, Story, Task, Theme, Program

Supported Methodologies

RUP, Scrum, XP

Scrum, XP

Drag n’ Drop UI

Limited to certain screens

Used almost universally

Hierarchical Relationships

Yes

No – Uses themes instead

Built in collaboration features

Yes – Wiki & IM integration

No

Test management

Yes

No

Defect management

Yes

No

Program Management Features

Release Status – not really configurable

Release Status + configurable feature sets, Good cross product functionality

Sprint Task Tracking

Yes

Yes – nice web based task board UI

Assign Business Value

No

Yes

Product and Role based permissions

Yes

Yes

LDAP Integration

No

Yes

Import/Export

Yes – Excel, XML

Yes – Excel

Supports Use Cases/Non-functional requirements

Yes

No

Notifications

Yes – RSS, email

No

Detailed Change History

Yes

No – very superficial

Product Integration

Eclipse, Mercury, Salesforce, Bugzilla

Bugzilla, JIRA

Pricing

$65/person/month

$249/person/year ($21/month)

Admin functions

User accounts, Roles, Custom features, Workspace management

User accounts, Roles

Hardware Requirements

None – externally hosted

Server must be allocated for clients & web app to connect with

Frequency of Updates

Quarterly

Quarterly

Built-in Support for pairing time management

No

Yes – There are “Team hours” and “individual hours”

Usability for teams

OK, some complain of delays and there are complaints about charts

Good, The thick client offers more natural DnD style of interface – good web interface for task board – natural for teams to adopt

Multiple Teams/Common Backlog

Possible, but awkward

Pretty well thought out

Support

Online, Forums, Coaching, Training

Online, Forums

Integration Technical Options

REST, SOAP, Others

SOAP


What is “Swarming?”

December 3, 2007

The term is derived from the behavior of insects in nature. The classic example of this behavior is a beehive when it reaches a critical mass. The workers will grow a new queen, and then the hive will split and a swarm will form that will leave the hive and seek out a location for a new hive. Perhaps the most astonishing thing is the fact that there is no one individual controlling the actions of the hive. There is no controller, no authority, no coordinating influence. Sounds kind of Agile.

These characteristics of “swarming” in the insect world are very similar to the kind of behavior that we are trying to foster within Agile teams. We want the entire team to focus on one and only one story at a time.

We want to use simple rules. We want to allow the team to self organize.

However, swarming is a relatively new pattern to emerge in the software world, and there has been a lot of misunderstanding and resistance to the notion of swarming. The idea of having the entire team focused exclusively on the same story is very hard for some people to swallow. The key is to create the right environment to support swarming activity.

If you are going to practice the swarming you need to make sure the following conditions hold true for your team:

  1. There is a definition of done that enables the involvement of the entire team
  2. The scope of the story is non-trivial
  3. A Set based decision making model is used

Often the argument that I hear is that a given story simply doesn’t require the involvement of everyone on the team. However, the more I thought about it, the more I realized that this probably isn’t really true very often. If we look at the definition of done for a team, we fine that there are activities from virtually every team specialization that are required to get a story into “potentially shippable” form. There needs to be a definition of done that enables the involvement of the entire team. Think about it – what activities need to be done for each story? Can we leave out QA? Documentation? Analysis? Design?

Someone once argued that it doesn’t make any sense to build a car 1 tire at a time. I have to agree, but I must also maintain that the challenge must be equal to the resources of the team. We should scale the stories to the appropriate size. The scope of the story must be non-trivial. Instead of building one wheel at at time, perhaps we should change the story to implementing the braking system? Perhaps the team should be implementing the suspension? The drive train? The story has to be scoped large enough that it allows the participation of more than one team member.

We also have to realize that swarming opens up some opportunities that we might not have using more conventional team organizational patterns. A Set based decision making model can be used. If the entire team is focused on the same problem, then we can also have them explore multiple solutions to the problem. This can lead to enhanced learning by the team, and allows them to explore alternatives more fully before making a commitment to an implementation or technology.

So, if you want to explore your busy inner bee, you need to create the right environmental conditions to support the swarming behavior:

  1. There is a definition of done that enables the involvement of the entire team
  2. The scope of the story is non-trivial
  3. A Set based decision making model is used

Given these conditions, the swarming pattern represents an exciting opportunity for us to explore a new way of understanding how we collaborate within our teams.