Agile — You’re probably doing it wrong.

I’ve worked in a few “Agile” environments — but can safely say that I think only one of these had Agile “right” for their needs.

I recently read a blog post about Agile being done wrong, and it made me think, which is never a good thing. There are so many different thoughts on Agile, and what it involves, and what it means to development. But what’s right? Is there a right?

One of the common misconceptions about “Agile” is that it itself is another methodology, like Prince 2, where things are structured in a set way.

For example, in Prince 2, you have a Gantt chart to monitor your progress. In Agile, people look for equivalents, and draw comparisons to Burndown charts or backlogs for progress monitoring. Whether that’s right or wrong is for another time. But what I’m trying to emphasise is that there is no need for the comparisons, if you’re doing Agile right, then it’s its own entity.

“Agile” isn’t a standalone methodology. It isn’t a structured tool to manage a Project. It isn’t a set pattern that can be reused for every project. It doesn’t have to have stories, features, epics, sprints or any other buzz word that you can chuck in to the mix. It doesn’t have the same parts as other methodologies.
This is the whole meaning of Agile, just look at the Manifesto:

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity — the art of maximizing the amount of work not done — is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

Agile is something that should be fluid, expandable, reducible, reusable.

Or all of the above, none of the above. Whatever.

The key principal is that Agile works for you, your business, and most importantly your team. Crucially, that it is based primarily around fantastic communication from the offset between all parties, as the manifesto outlines:

Close, daily cooperation between business people and developers

It’s down to you, in your role, to adopt the Agile principals and create a methodology that works for you, for your business, for your product, for your project. Something that should be discussed as a team, not an individual, and not as “management”.

And most importantly, remember that what you’re currently doing is probably wrong, if there is such a thing.

And wrong isn’t a bad thing. It just means that what you’re doing can be better. And we all want better, right?

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.