Agile is a Band-Aid for a Lack of Trust
Zone Leader Sam Atkinson on how agile processes designed to replace waterfall are often flawed, and how it harms agile methodologies in general.
Join the DZone community and get the full member experience.Join For Free
I’ve had the pleasure of working on a variety of teams and projects, some as a dev and some as a manager. I’ve done waterfall, agile, and an awful lot of stuff inbetween (waterfall agile AKA Wagile). I think as an industry we’ve all come to an agreement that waterfall is terrible but there is also a realization that the agile practices we’ve put in place to replace it are often flawed and suffer from the same problems; 2 weeks sprints but large release cycles, kanban and scrum boards which remain consistently out of date, multi hour estimate meetings which are redone each sprint, and half hour sit-down stand-ups for the purpose of updating management.
I know there are lots of high performing teams that don’t suffer these smells and I salute you, but I think you’re in the minority. I think most teams are struggling in the badlands of wagile, and I have a hypothesis why — we’re ignoring the core purpose of agile (lower case a) and instead putting Agile Processes (uppercase A) in place because there is no trust in the teams.
The original manifesto specified “Individuals and interactions over processes and tools”, which was spot on. The composite parts of agile are there to facilitate and help teams in their task of fast delivery of good solutions. Yet in my experience the components of Modern Agile such as Jira boards and planning meetings have ended up as a framework for developers to follow blindly for the sake of management tracking, not increased delivery.
In one of my recent projects I was fortunate enough to be the lead on a team consisting of my 3 favorite developers and myself. These guys know their stuff and develop well tested, functional code at speed. At the start of the project, we sat down and came up with a team manifesto for how we wanted to run the project. It only took about an hour but it clearly set the ground rules for how we wanted to operate.
The key outcomes? We concluded we didn’t need standups (there’s 4 of us, let’s just talk to each other regularly). We banned formal meetings (see previous point). We tracked tasks using a physical story map purely for our own benefit (so we knew where we were up to and what was left). We estimated only so that we had a vague sizing of the tasks. We agreed we wanted as much pair programming as possible and that we’d be TDD focused. Then we got on and coded, and it was by far the best team I’ve ever worked on.
This could have been a disaster, but it wasn’t for a single reason: trust. All the developers trusted each other, and as the lead I trusted them too. There was no one-upmanship. We helped each other out, and we did a lot of pairing which increased the trust in the codebase.
This runs contrary to a lot of teams I’ve witnessed. There were 2 week “sprints” with no demo or delivery at the end, meticulous documentation and tracking on JIRA (with triage into spreadsheets!), long planning sessions and standups, all the usual smells. Bad agile is much like a government that doesn’t trust it’s citizens, so creates excessive regulation to keep them on track which in turn slows development down and produces sub par solutions.
Highly performing teams consist of A-team players who trust and value each other. There’s a reason the top dev shops like Netflix pay above market for great developers, and offer great severance packages to people who aren’t meeting the grade. B- and C-level developers don’t just passively contribute but instead reduce the performance of great teams.
For the regular dev shops however your teams are always going to be a mix of standards and abilities. But once we acknowledge the problem we can then take steps towards mitigating the issues. If you team has agile smells then chances are you have trust issues. They may be between developers (we’re a fickle and egotistical bunch), or between the lead or manager and their team. If you are able to increase the trust on your team you will be able to reduce the red tape and processes around them and finally start putting individuals and interactions first and foremost.
How to go about this in the real world? Pair programming is a great place to start. It’s not a silver bullet, but it’s very close. If you have two sets of eyes on a problem and a piece of work it’s much easier to trust that the final result be the desired one. It forces developers to talk to each other and interact, which (hopefully) will increase the trust.
I’m also a big fan of self assembled teams. If a group of developers are friends then put them together on teams. For some reason I see friends split apart on projects time and time again. They already have a basis of trust, they already value each others work, so use that to your advantage.
Sit down with your team and come up with a team manifesto. If the team decides the tools and processes themselves they are much more likely to follow them than if they’ve been foisted upon them.
If you’ve other tips then drop them in the comments for everyone to see.
Follow @SambaHK on Twitter for more like this.
Opinions expressed by DZone contributors are their own.