Tuesday, June 02, 2009

When Agile gets Fragile

Agile methodologies have represented a great move forward from in delivering real value in software development. It’s principles are defined by a simple manifesto from the Agile Alliance:

“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.”

To be Agile, so many things need to come together, when they don’t you end up with a terrible pot-pouri methodology or lack there of which sabotages a project right from the start.

I state here some things in my experience that have made the process of being agile less than effective:

  • Fixed set of deliverable to be delivered in a fixed short timeframe, without heed to the teachings in  The Mythical Man Month
  • Lack of application of agile software techniques. Including but not limited to code reviews, unit testing, refactoring.
  • Resources being added to team late on in projects. See first point. With tight deadlines, it is most defiantly to stick with the staff on board at kick off and let them do their utmost to meet that goal.

It is true that each of these issues stated here effectively break the software development process, Agile or not. What can we take from this? Maybe this one statement:

“In software development, all stakeholders must make a commitment to a process, and stick with that commitment regardless of external pressures.”

We should stop looking to processes to solve our issues when we don’t commit to those processes.

0 comments: