Agile? You're soaking in it

I recently had a discussion with a team about the best way to “use Agile”. During the discussion, I noticed team members were getting hung up on formal definitions and methodology. They were saying things like:

I believe I’ve worked on projects using the agile project management methodology but I would struggle to explain what it’s all about

It might be worth those of us who don’t know the Agile approach, to attend some training

I’ve always worked out best solutions and got work done fast, evaluating and adapting as I go along. That’s my own method of agile with a small ‘a’. It doesn’t necessarily mean that I know what a recognised Agile methodology is.

Some other people in the team thought they understood agile working. But it turned out they were defining it almost exclusively in terms of tools and methods. There was a lot of enthusiastic talk of user stories, kanban boards, whiteboards and Post-It notes. But there was very little talk of shortening communications pathways, incremental understanding of requirements, responsiveness, collaboration, or actually building the thing.

This public sector organisation had historically been heavily oriented towards PRINCE2; probably still was to some extent. And the public sector tends to emphasise the importance of The Correct Process over the importance of JFDI ¹ anyway. So it wasn’t entirely surprising the team were searching for a formal understanding of “Agile”. And the people who thought they understood it, well, they were mostly getting distracted by shiny new ways of doing things.

The last comment really resonated with me. That person was already being effective and agile in their daily work; possibly more than some who follow formal “Agile” methods. They were already soaking in it ² but they didn’t recognise it for what it was.

There’s nothing wrong with agile with a small “a”. In many ways this usage is actually helpful, because it encourages you to think about what’s important in an agile way of working, rather than the tools, processes, methodologies and labels. Agile isn’t a noun, nor is it a panacea. Projects that do Agile without understanding the reasoning behind it are just as doomed to failure as projects that blindly apply PRINCE2 or any other methodology as a substitute for critical thinking.

The reasons for working in an agile way can be explained in three bullet points without reference to sprints, backlogs, kanban etc:

On complex projects, it’s hard to get a complete set of requirements. Big sets of requirements are intimidating, and often wrong. And requirements on all projects, almost inevitably, change. Embrace change rather than trying to control it, and constantly monitor your requirements and assumptions.
It’s better to ship 20% of the business value, then 40%, then 60%, then 80%. Rather than waiting until you have 80% before you deliver any of it. This demonstrates progress and keeps communication going. Also, rework is costly and some of your early assumptions may be wrong. Better to find that out early.
To achieve the above it’s best to have small, empowered teams with members that a) know the business requirements as they’re understood at that point and b) know the current state of the project, particularly with reference to the bit they’re working on. Keep your people informed, but don’t over-communicate.

Being agile means embracing change, effective (not voluminous) communication, incremental understanding of requirements, and managing complexity so you’re only focusing on one deliverable thing at a time. It’s simple stuff really. Practically speaking this often means regular short meetings, lots of Post-It notes, a preference for delivery over documentation, direct engagement with stakeholders, and the ability to make changes directly. But these are just some symptoms of being agile; they’re nothing special in themselves.

Postscript

There are lots of meetups where you can discuss this sort of thing. I sometimes go to the Leeds meetup - come and say hi if you’re ever there.