Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Acceptance testing is either not done or done at the end

Forces:
Excessive belief in unit testing
No testers involved
Insufficient awareness of how to “agilize” old habits
No acceptance test criteria
Excessive time/resources to run
Lack of hardware/understanding of economic issues
Perfectionism – 100% must be testable
Reliance on manual work

Consequences:
Systems that don’t work
Release bugstorms
Projects canceled
Loss of trust

Example:
1,000 unit tests, but the system is broken

Better solution:
Insist on acceptance test criteria
Buy hardware
Training on iterative testing
automation
Exceptions:
Trivial systems
Internal tools
Prototypes

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Unable to take responsibility
Cannot say no to developers/stakeholders

Forces:
Authority problems
Inappropriate personality in key role
Unclear roles/decision rights

Consequences:
“bedazzlement” – confusion – “rabbit in headlights”
Time wasted
Poor prioritization

Example:
Developers talk excessively at daily meetings
Multiple customers cause constant re-prioritization

Better solution:
Certain roles need certain personalities

Exceptions:
Better than having a “nasty” guy in charge.

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Manager prioritizes stories, tells how to do them, developers don’t have a say (because of manager’s authority)

Forces:
Customer absent
Managers want to stay in control
Manager knows product and thinks he knows what users want
Organization doesn’t trust developers

Consequences:
Customer doesn’t get what he wants/needs
Team is disempowered/alienated
Creates dependency situation

Example:
Product owner manages the whole team. He discourages the team to come up with better solutions so that they depend on him.

Better solution:
Separate product owner from other roles on the product
Onsite customer
Train manager as coach (so that he has a role outside of owning product and can drop that role)

Exceptions:
Very small company
Temporary replacement if product owner on planned/unplanned absence

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Not switching pairs

Forces:
High productivity of pair
Pair is happy
“never change a winning team”
Inability to pair with others

Consequences:
Pair does not improve
Pair will get bad habits (we always do it like this)
No knowledge sharing
Pair might get bored with each other
Needed split up impossible

Better solution:
Pairing schedule
Encourage pairs to switch

Exceptions:
Crisis
2 person team
Siamese twins

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Individuals volunteer to refactor for the team

Forces:
Trying to take responsibility on behalf of the team
Some people do not refactor enough
Some people are afraid to refactor
Because they don’t know how to do it
Because they don’t want to change someone else’s code
It is faster for the one who knows how to refactor to just do it than teach the others
Only one person knows how to refactor or has good OO skills
Schedule pressure does not allow the team to practice/learn refactoring
“if it ain’t broke” attitude.

Consequences:
Top producer no longer produces (busy refactoring)
Never enough refactoring, never improves
Generates refactoring stories which have no acceptance criteria and no direct business value
Hides the real problem – “failing late”
People never learn the real value of refactoring

Example:
XP enthusiast introduces XP to a new team
Team starts to practice TDD, but doesn’t refactor enough
Team learns to refactor slowly
Leader feels pressure to produce and “leaves” simple design to go faster

Better solution:
Plan for the learning curve
Refuse to refactor along
Remember to refactor only to implement a story
Don’t accept story submissions with obvious design smells
Review more until refactoring improves.

Exceptions:
Team made up of contractors
Short product lifecycle (maybe)
Single use utility

Here is one of the XP2006 workshop antipatterns the group worked on.

Poor Solution:
Concurrent work on to many stories
None of the stories are done at the end of the iteration.
All stories are in progress.

Forces:
Desire to go as fast as possible
Big stories are not split (seem to be unsplitable)
Belief that multitasking is faster

Consequences:
Stories don’t get finished
No data to plan the next iteration
The team feels bad
The team gets blamed
There is nothing to integrate

Better solution:
Split stories so they can be completed
Take on fewer stories per iteration
Minimize work in progress

Exceptions:
None

Here is the description of the workshop I ran at XP2006:

Agile methodologies are just as prone to mistakes, deviations and subversion as any other methodology. This workshop is intended to discover and share agile process anti-patterns then discuss and present creative solutions.

Anti-patterns, also referred to as pitfalls, are classes of commonly-reinvented bad solutions to problems. They are studied, as a category, in order that they may be avoided in the future, and that instances of them may be recognized when investigating non-working systems.

This workshop focuses on participants’ (less than perfect) experiences in the workplace and mines the collective wisdom of the group to come up with creative solutions via a fishbowl process followed by breakout sessions and then group presentations. This is a half day workshop.
A fishbowl is structured conversation technique where a small number of people sit in front of the group (in the fishbowl) and converse with each other. The audience listens and at any time a member of the audience may become a member of the fishbowl, replacing one of the existing members.

I promised that I would post the results of the workshop and I (finally) have them prepared.

Workshop Antipattern List

Session 1

• Coach as manager
• Scrum master is nominated
• Worst employee as scrum master
• Too many stakeholders
• No iteration planning
• Story not really done
• Splitting stories for credit
• Velocity as dial
• Iterate without delivery
• Iterations as checkpoints
• Micro-stories
• Stories to big
• Not enough stories
• Too many meetings
• Unit tests as specification
• Specialist handoff
• Steering because you can
• Refactoring butler/gnome
• Refactoring task/backlog/iteration
• Breaking someone else’s tests
• Rebranding departments as scrum teams
• Desert island teams
• Manager is the product owner/customer
• Tools getting in the way
• Technologist as customer
• Come back when you are done
• Customer proxy believes he is the real customer
• When pairs don’t swap
• Too nice a guy in charge of planning

Session 2

• 0 Velocity Iteration
• Testing after release
• Stabilization iteration
• 80% complete stories
• Customer won’t choose
• Only new stories get worked
• Feedback ignored
• No sprint demos
• Lack of effective acceptance testing

One of the things that often happens when the product owner is technically savvy is that they start writing solution stories. That is they specify how something should be done technically rather than what should be done.

For example here is a story that states specifically how the task should be completed (solution):

Partition the customer history table horizontally

This story has been written by a customer who either knows a lot about physical database performance tuning or has talked to someone who does (or a least someone who tossed out a possible solution).

A better story that gets to the real business need (performance) is:

Ensure that saving updated customer information takes no more than 2 seconds on average

By knowing what the need is the developers can look at the whole system to see why saving the customer is taking longer than 2 seconds. This gives the developers latitude on how to solve the problem rather than boxing them in. In this particular case the real solution was fixing some logic in the trigger and adding an index.

What Make a Good Story?

Bill Wake has an article on the characteristics of a good story. He uses the acronym INVEST:

I	Independent	Stories are easiest to work with if they are independent. If they are independent we can schedule and build them in any order. This allows us to select stories with the highest value without worrying about all the expensive, low value dependent stories.
N	Negotiable	Negotiation is a key ingredient of agile development. Remember that agile methods are typically scope variable. That is the time line is fixed (iteration length) and the quality and scope are varied. A story is a placeholder for discussion. We need to be able to split, combine, tweak, clarify, etc stories at any time.
V	Valuable	Stories need to have real business value to the stakeholders. Typically this is the customer although there are other stakeholders (including the development organization). I like to see all stories expressed in ways that the primary stakeholder can understand the value provided by the story. The definition of "value" can vary somewhat from project to project and organization to organization.
E	Estimable	If a story can't be estimated then the customer can't derive value or assign a priority to it. We don't need a precise estimate or a guarantee that the estimate will never change. But we do need a good enough estimate that is as accurate as current information allows.
S	Small	Having small stories is a result of estimable and negotiable. The larger the story the harder it is to estimate, the less flexibility in negotiation. Each team has a "right size" story which tends to be in the several hours to several days ranges (in ideal time). Stories larger than this tend to fall into the "I don't really know" category.
T	Testable	Stories need to be testable, otherwise how do you know the story is complete?

For more info on how to write better stories see Mike Cohn's book User Stories Applied or look at the sample chapter.

Aren't there Any Exceptions?

Of course there are. Most projects have constrains of some kind which are technical in nature. I.e. "Must support Oracle and MySQL" or "all logging will use our custom Log4Net appender". These are definitely solutions, but generally apply to all (or most) stories so I track them separately. I've heard of others using different colored cards to visually indicate the difference between feature stories and constraint stories. I also like to make a note on my feature stories if there is some particular reason to pay attention to a constraint, at least until the team gets a feel for where the constraints apply.

Solution Stories in the Wild?

What are the best examples of solution stories from your experience and how would you rewrite them to be "real" stories?

Agile principles at work
So which agile principles are at work in correcting this smell?

• Developers create & estimate tasks
• Developers self select tasks
• Customers write good stories

A common smell that is often detected in teams trying to become more agile is more and more stories/backlog items incomplete at the end of the iteration. There are a couple of different reasons this might happen, but the one I'm interested in today can be detected by the claim "I finished my tasks". The clear implication is that "I got my stuff done, but someone else didn't".

A little additional research usually shows that people are waiting for people with some kind of specialization such as database, QA, UI, or any other skill that isn't widely distributed among the team. As an agile team this is where specialization gets in the way. In a more traditional project the measure of delivery is the task, however, in agile projects the measure of delivery of working features. Specialist typically don't deliver working features, thus the problem.

Note I am not saying that specializations aren't needed, but they do need to be balanced with other needs that help deliver features. Agile teams tend towards people who are "generalizing specialists" rather than generalists or specialists. Scott Ambler has a good discussion in this article as does Mishkin.

So the question becomes "what to do about it?" Well, it depends (said the consultant...).

Are your specialists on your team or part of someone else's?

Are they part of a separate group dedicated to their specialty (functional grouping)? Typical examples of this are dedicated DBAs and separate QA organizations. In general agile teams want to have all the skills necessary to be successful as full time team members. Of course this is not always possible due to organizational constraints or because the specialist is from an outside organization (contractor). Scott Ambler recommends explicitly scheduling tasks that involve external groups. I think this great advise and can clearly assist in overall project transparency. You are making your project plans publicly visible aren't you?

Are the specialists available to your team?

If the specialists are not on your team are they available when you need them? Or is it more like Baskins-Robins where you take a number and they will get to you when they are done with everyone else. Or have the other projects in your organization slipped their dates and now overlapping with yours so that the specialists are double or triple booked?

The first thing to do is to try and get your organization to work with you, rather than against you. How you do this is dependent on your organization and may take longer than your project can stand. However, in the long term this is the best solution.

Assuming the organization can't or won't work with you there are a few options. You can go outside your organization to contractors, consultants, etc. This may carry some political risk with it so you'll have to balance the politics with the ability to get things done.

If you don't have funds to go outside your organization think about training the team so they are more independent from the specialists. This may not be as quick a fix as you need, but it can get you there sooner than you might otherwise. Plus it has the benefit of removing you dependence on the specialists (as well as giving your team new skills).

A more radical idea is to look for ways to eliminate the need for the specialized knowledge altogether. This won't work in all cases, but a little creativity could buy you a little time and possibly a lot. Think about things like database needs. What if you designed you system such that it didn't need a database, or at least was independent of the database. Then you could make use of the DBA when they were available, but it wouldn't impact the progress otherwise on your project.

Is your team pairing with the specialists?

When the specialists are working on your project is someone from your team pairing (or at least working with) that specialist? Or is the specialist isolated from your team (even if just in a separate cube)? Your team needs to start absorbing this specialization as well as decreasing the feedback loop on what the specialist is working on. For example if your performance testing group just takes documents as input and sends back performance data after a week without any intervening interaction you've lost valuable time if there was an early problem that you could have corrected the first day.

Agile principles at work

So which agile principles are at work in correcting this smell?

• Generalizing specialists
• Whole team commitment to completing features
• Do the simplest thing
• Work together
• Reduce feedback loops

I've been quiet recently, but busy. Last spring I moved from the consulting world back into "regular" employment where I manage a couple of product teams and internally consult on iterative software development and agile approaches. Since starting here I have run across a number of "Process Smells" that I encountered in my coaching/consulting days that are begging to be written down. So here I go.

Process Smells are those little and big things that get in the way of achieving your goals. The "Smells" name comes from Martin Fowler's reference to "Code Smells" in his book Refactoring. It seems to be a great metaphor since often times you know something is wrong, you just can't put your finger on it. It just smells wrong.

Most of my smells will be related to transforming a team to an agile approach as well as keeping a team agile.

Enjoy.