Mythical Agile Shortcuts

Posted by Ben Hughes on Jan 17, 2008

Sections

Process & Practices

Topics

Adopting Agile ,

Agile ,

Agile Techniques

Tags

Introducing Agile

Ross Petit, an experienced developer, PM, and program manager working with ThoughtWorks, recently published an article on the common failure points of going Agile. On the face of it the practice of going Agile shouldn't be too arduous. In fact, often the Agile approach requires less process and procedure than more traditional methods of software development. So where does it go wrong? If the processes are followed how do projects end up with technical debt, unshippable code and all the other nasties that going Agile is supposed to avoid? The author details some mythical agile shortcuts:

We write unit tests, but it doesn't matter if they pass or not
Writing unit tests and automating them into the build is an obvious best development practice.  While many people are willing to write unit tests, they are not necessarily diligent about maintaining them.

We pair, but only when we have trouble
Pairing is often considered a "nice to have" rather than an absolute necessity. The reality is that pairing maintains consistent throughput of Agile teams, as well as the great team benefit of knowledge sharing.

The work we do doesn't lend itself to Agile "stories" so we track to technical tasks
Teams define work not as an end to end story but as a task. Requirements are structured as statements of technical activity for developers, not as user-valued features understood by the customer. Often its easier for technical teams to produce collections of technical tasks and try to pass them off as Agile stories.

Petit concludes: "A shortcut is the longest distance between two points." It seems half-done Agile may be even worse than the monolithic procedure it's aiming to replace.

You can read the full Agile Journal article here, for Petit's view on how to avoid falling into these traps.

1. Back to top

   Pair Programming required?

   by Tim Ferguson

   I understand some of the benefits of pair programming however it seems that there are many reasons that pair programming would not work, such as developer personalities, development organization size (say only 2 developers). I think the goal of consistent throughput can be hampered by these things I have mentioned, sure it may be consistent, but it might be less than optimal. For knowledge sharing there are many other things that seem to be able to produce the same results such as code reviewing, brown bag lunches, open workspace concepts. Does anyone agree or disagree?
   
   Also, we are constantly struggling to keep the stories from being technical stories, especially when our product owner is very technical himself. I still wonder though, how do Agile teams include all of the work that is required just to produce and maintain the build process? We constantly struggle with how to insert these items into the iteration and weigh these "maintenance and upkeep" tasks that the owner really doesn't see (other than they contribute to the overall production of the finished product) against the stories the product owner has already prioritized, .
   
   Tim Ferguson, xaware.org

   Reply

2. Back to top

   The implication "All or Nothing" is misleading

   by tim dugan

   Quote from the author:
   
   "half-done Agile may be even worse than the monolithic procedure it's aiming to replace"
   
   If you are not doing Agile today and you start doing agile tomorrow, can you move from 0% Agile to 100% Agile all at once? The BIG BANG may work in physics, but human processes have to move more gradually on an evolutionary scale.
   
   Read a book on Agile development, like Jim Shore's latest book...there is WAY TOO MUCH to do it all at once. By the time you get to everything in the book...there will be a new and better book...

   Reply

• Older >