Hi, I’m Dom Davis, CTO at Rainbird, and lapsed Agile Evangelist.
I’m going to be honest here. When Paul asked me about coming to Agile On The Bench I fully expected to be sitting in the audience watching someone else talking. You see, I’ve rather fallen out with agile. I don’t recognise what people call Agile these days. I couldn’t even tell you what Agile is anymore.
In my last role I was confidently informed that I didn’t do agile because I didn’t do scrum – which was an interesting statement. Agile isn’t scrum. And Scrum spelled with a capital “Waterfall” isn’t agile either. It may sound harsh, but I can guarantee you that’s what they were practicing.
Part of this persons philosophy was that stand-ups were important, but hard to organise every day. So instead of five short daily stand-ups there was one hour long weekly standup. That’s not a stand-up. That’s an uncomfortable team meeting.
And it’s not just that one person. I’d go so far as to say that most people using Scrum aren’t really being Agile. At best they’re being Clumsy. At worst they’re deluding themselves. The same holds for Kanban, Lean and pretty much any flavour of Agile you care to mention.
The problem is that you cannot prescribe a one size fits all approach to software development. People are different. Teams are different. Companies are different. Trying to force people to work in a specific way simply because it has been prescribed as “Agile” is agile with a capital FR.
What works at company X may not work at company Y. And while it may look all fine and dandy at company X I’m willing to bet they also have issues – they’ve just got an evangelist who’s willing to stand up and talk about the good bits, while glossing over the problems.
This carbon copy approach shows a fundamental misunderstanding of what it means to be agile. Scrum, Kanban, Lean; these are all frameworks, philosophies you can weave into the very fabric of your company, not rigid processes to be mandated and enforced. Constraint and agility are diametrically opposed. One cannot allow the other. A rigid process, by definition, cannot be Agile.
And yet the virtues of Agile have been sung from the highest parapets. So much so that we all now know, at a visceral level, that Agile Is The Way. So if it doesn’t work for some reason we’ll just try another flavour of it. We’ll employ certified scrum masters and hope that if we believe hard enough, and follow the plan rigidly enough, it will all be OK.
It won’t, because you’re addressing the wrong problem. This is not the Agile way. It’s the Clumsy way. It’s only when you need to react fast, to be truly Agile, that you find out you’re actually Clumsy. And you find out the hard way, tripping over your processes and getting tied in knots.
Agile is not a process, it’s a state of being. It means you can act with agility. That you can react to the needs of the business, and to the pitfalls of software development in a timely manner. And that’s it. Everything else is process.
Most truly agile teams will review and change their process regularly: keep what is working at this time, shed what is not. What works today may not work in 6 months because the problem space is dynamic, constantly shifting. They understand this and embrace it. There is no perfect solution, just something that works well enough for now.
Strip away the buzzwords and we’re just talking about project management. Except project management is a dirty word. It’s enterprise-y, and we’re all ninja-rockstar-full-stack developers deploying fleets of containerised micro-services to the cloud. We don’t want to be constrained by Process.
But we do need something. It doesn’t need to be Process with a capital P, but simply building a Kanban board, running daily stand-ups, and declaring ourselves to be “agile” isn’t going to work. There are some fundamentals we need to get right. Without those fundamentals you’re setting yourself up to fail.
There are no quick wins. But there is basic starting point to get to the solutions that works for you, in your team, in your company. In the end it all boils down to communication. How do we communicate the requirements from our stakeholders and users to the development team? How do we communicate progress back to the stakeholders and users?
This could be anything from Post-It notes on a whiteboard and informal meetings when required, all the way up to full blown project management systems. Informal doesn’t scale well, and the more formalised the system the less agility it has, so there is a trade off.
But don’t start with the tools, or the process. Start with what you want to communicate. How do new issues enter the pipeline? How do we make sure that what is developed is what is required? How do we feedback progress?
Get that sorted and you’re well on the way to winning, regardless of how it’s done, or what you call it.
If you want to hear more I’ll be ranting about Agile and Agile Processes in a longer session called ’Agile Smagile’ at NorDevCon.