What am I talking about? I’m talking about getting rid of ‘Agile Development’; certifications, rigid process, faux-flat company hierarchy and moving to agile development: near real-time communication, small feedback loops and empowerment of developers who are making software.
But I bet you’re wondering:
Why the sudden epiphany Max? Aren’t you a big advocate of Scrum?
Yeah, I was and still am to a certain extent, but I’ve recently started a new job in a much smaller team and it’s given me some perspective.
Scrum is good; great even. It still has a place amongst teams with little experience in developing software with agility. But it’s not, and should not be the be all and end all of software development. It certainly isn’t something that we should, as developers, aspire to as a long-term goal. It’s a stepping stone to a better way of working and a very worthwhile one too. It’s ‘agile with training wheels’. It quickly ingrains the principals of agile development in to its members. But we do not use training wheels forever and we definitely don’t hand out certificates and praise to those who encourage it. It starts to hold you back. We’ve reached a bizarre paradox at this point. You want to go faster (be more agile), but you just can’t because the rigid process (the stabilisers) is holding you back. You’re ready to move on but you can’t. The process is ingrained and beyond change.
As a result of this idea, why do we need ScrumMaster certifications or even the whole concept of a ScrumMaster. Not just because the name makes me cringe but because why do we want to encourage keeping the stabilisers attached? A true leader (or master if you insist) keeps the stabilisers attached for as little time as possible, empowering the people doing the work to do the best job they can and then slowly removes the stabilisers, encouraging the team to make mistakes and learn for themselves. The development team are probably smart people, you hired them after all. A bad leader says “It’s 11am. Time for a daily stand up because that’s what we always do.”
Convinced that Scrum might actually be holding you back? Ok, good. I’m not a believer in trashing a decent concept unless there’s a better one waiting to take its place. Like I said, that’s small-a, agile development. To be a member of an agile development team you don’t need a certificate, or even a fancy job title, you can be a manager if you want, team fascilitator, team leader, god of process, I don’t care. Just make sure you do the following:
Communicate
All the time. Ask questions. Make sure everyone knows what everyone else is doing. Use a daily stand-up if you want. Or don’t. Whatever works for your team.
Feedback to your customer atleast daily
Two, three, four, five times daily. They’re paying you to make something great but they run their business, they know what’s best. They must know what you’re doing so show them! Feedback can take many forms whether it be just a phone call to update them or a piece of shippable code so they can see a feature in progress. Whatever works for your team.
Spot issues early and resolve them quickly
Use sprint retrospectives if you want but in my experience, once every two weeks isn’t often enough. Problems come up unexpectedly, that’s why they’re called problems. Got an issue with management? Talk to management. Got an issue with code quality? Talk to the developers. Got an issue with the client? Talk to the client.
What I’ve described here is just a practical implementation of the Agile Manifesto, which is exactly what Scrum is but with less rigidity. My issue isn’t with Scrum itself, but with its inability to change without no longer being ‘Scrum’.
The rest is up to your team. They’re smart people. Empower them and they will, almost always, surprise you.