Agile Software Development: It’s Not a Process

Platform, Posts, Software Development, Supply Chain

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”.

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.

Back to List View
Supply Chain Brief