Agile software development

If you tell people where to go, but not how to get there, you’ll be amazed by the results.

General George S. Patton

“Agile” has become the standard in software development teams. It is now the expected methodology or process when building and releasing a software product.

The key factor i’ve learnt over the years is, different teams all “do agile” differently.

Being agile in the true sense of the word is is not about the tools you use or process you put in place. It is about working in short iterations, learning from your progress, having a clear vision or problem to solve and communication.

Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.”

Albert Einstein

Being agile is different to “doing Agile”

Adopting and becoming agile can be a very hard task; agile practices are mostly learned and experienced, they’re not something that you can easily glean from a book or article.

Giant non-sensical ‘requirement documents’ and ‘functional specifications’ meant the team actually building the product had no autonimy to do what’s right for the project as unexpected questions and issues arose.

The inter connected and systemised nature of software does not play well with locked in requirements as things will literally change on a weekly, if not daily bases.

This is where being agile allows teams to have the autonomy to make the decisions needed to best solve the problem. This does not mean you have teams of engineers coding anything they want. To become agile you need to have a cross-functional and balanced team all working together to achieve an outcome.