Search the Blog

Once upon a time, agile software development was revolutionary and cellphones were for making cellphone calls, but those times are long gone. Agile is a mainstream best-practice and if you aren’t applying it then I must brand you a laggard. But agile has changed in the last decade, and not always for the better.

 

Back in 2001 it was generally recognized that the principles behind agile were its most important characteristic, but nowadays there is an unhelpful emphasis on its mechanics. The phrase “an agile process” is often heard even though one of those principles states that agile values “individuals and interactions over processes and tools”.

 

Or to put it another way:

 

So if being agile doesn’t mean following some process, what exactly does it mean?

 

Well in TECSYS R&D we think it means striving to reach the ideals expressed by the four principles of the agile manifesto, i.e. valuing:

 

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

 

We’ve adopted practices like Scrum (as illustrated in the picture above), but we continually question these practices. The principles are what’s important and not the methods to achieve them. We see great benefits from this.

 

For example, Scrum has helped us to focus on the precise problem to be solved in any project, and that boosts our productivity. It also encourages us to seek out and welcome feedback on our products to guide our development. And we organize our R&D department in small independent teams to reduce overhead and facilitate communications.

 

To be agile means to be humble. We never stop learning, so we’re open to finding out that we’re on the wrong track in a project. Experience has taught us that setting out to develop software is like venturing forth on a voyage of discovery – we can imagine the destination even though we don’t know exactly how to get there. So a roadmap is a bad analogy for development plans – think of a seamap instead as described in this blog by Jessica Kerr.


Tags: , , , , , , , , , , , , , ,

Post Comment

Please notice: Comments are moderated by an Admin.