Agile Failure Patterns

7 January 2014

Amr Noaman

Many teams try Agile methods, or rather techniques. Some of them fail, and they suffer from this failure later on because it induces resistance in the rest of the organization and makes later attempts at Agile adoption much more difficult.

The following are five patterns of immature Agile implementations. What's common among them is that the team concentrates on some superficial technique without really embracing Agile values.
  • Usually the team starts with stand-up meetings, and these fail because it simply hurts their legs to stand for one to two hours daily! Moreover, the meetings are boring and take up a lot of time. The team members feel that this "Agile" thing is naive and wastes their time.
  • Teams do sprints -- one sprint for every Waterfall phase. That is, a sprint for analysis, another for design, another for development, and a final one for testing. So the process simply becomes Sprintfall rather than Waterfall.
  • Team do sprints -- one sprint for every big requirement or group of requirements. The problem with this approach is that no feedback loop exists. In other words, the team has split a big Waterfall project into smaller ones. That just causes bigger management overhead.
  • Teams use sticky notes and decorate the walls with whatever they do, even with requirements in a typical Waterfall project. After a while, they lose interest in updating the board notes, because every step takes a lot of time (one to two weeks), and they cannot see any value in maintaining two databases of requirements and tasks (board and electronic versions).
  • The team does everything just right but does not take feedback from customers. This is somewhat better, but it's still Waterfall in the main. Teams iterate to get feedback and to adjust their development efforts along the way. If they do not get feedback, the value of iterating is not realized.

These are some common failure patterns; there are many others. To tackle these failures, you may try to apply other techniques that would help elicit the value of these non-value-adding techniques.

Let me give some examples. The first failure pattern (long stand-up meetings) would work if we just applied another technique: maybe standing against the Scrum board, and limiting discussion to task status for the recommended short meetings. The second failure pattern (one sprint for every big requirement) would be resolved if we broke down user stories properly into smaller ones. The fifth failure pattern (sticky-note decoration) would work if we applied tracking inside the iteration on technical tasks that are no more than four hours long.

One more piece of advice: Do not be shy about saying out loud that a given technique isn't working!

Article Rating

Current rating: 4.3 (4 ratings)


Phillip Stiby, CSM, 1/7/2014 4:46:12 AM
This is a great example of why scrum is a good agile approach.

point 1, in Scrum the daily scrum meeting is time boxed to 15 minutes, though you don't have to stand, its a good technique to shorten the meeting because our legs hurt standing for to long.

Point 2, scrum talks about delivering value as in working code (one of the principles of Agile).

Point 3, the issue here seems to be a lack of review and adapt (another agile principle) and the retrospective within the scrum process is there to capture feedback and make improvements.

Point 4, the team is only interested in the current delivery and the back log items being worked should if following the guide (July 2013 edition) be broken down in to tasks no bigger than 1 day.

Point 5, In scrum each sprint should be ended by the customer agreeing to the completed work which is demonstrated by the team and client feedback is given directly. The anti pattern here is more the team is not demonstrating or cut off from the client.

You must Login or Signup to comment.