Agile and contextual intelligence

The word 'over' which is repeated several times in the Agile Manifesto signifies the importance of choice. An understanding of the specific context, even as it keeps changing, is very important if you aspire to be agile.

Bejoy Jaison |

The more agile I aspire to be, the more I realise that contextual intelligence - or plain common sense for those who prefer less fancy - is vital to being a successful agile practitioner. As I learn to retrospect more often, I observe that I have had better success in delivering value to business when I made conscious choices.

For example

  • Timely delivery of critical business value over squeezing in every bug fix because the development team thinks so.
  • Delaying a release to ensure quality over releasing crap into production.
  • Having a working iteration backlog over waiting for a day for the team to close that last story so we could claim another handful of points and bump up our average velocity.
  • Similarly, letting the team work on features (business value) over getting into protracted discussions about how we could split stories at the end of an iteration so that we could increase our velocity.

If there is one word that keeps getting repeated in the above statements, it is "over" - the same word that stands out in the Agile Manifesto.

Processes and metrics bring in rigour, however choosing when to demand adherence and when to let go is an important day-to-day activity for most agile practitioners. Which means the understanding of the specific context, even as it keeps changing, is very important if you aspire to be agile. Often, these simple decisions would allow the team to deliver business value instead of getting caught up with the nuances of following agile as a shiny new project management or delivery process.

Image credit: https://unsplash.com/photos/CNBRg1K9QvQ
Posted under: Agile Maturity

Read similar articles

An agile approach to managing dependencies

Capturing and visualising dependencies between work items is the most obvious way to manage dependencies, but have you ever felt that things go out of hand really quickly?

The golden laws of agile delivery

What do you do when agile transformations are not having the intended outcomes?

Would you consider a single-MVP project as agile?

Is a single-release agile project an oxymoron or is it really feasible?