Does agile really work?
A friend sent me an interesting job post the other week, where the hiring manager was looking for people who can dive in and get things done without too much process getting in the way, and it struck me as being a breath of fresh air in a world of process-driven teams and particularly Agile being presented as the de-facto saviour of software development.
It made me wonder what specific problems or constraints that approach was trying to address.
Let's pick some key points out from the job post...
Let's just get things done!
Time and again, I have witnessed engineers knowing what needs to be done yet being unable to get things done because of “the process” or because “more data is needed.” Some of the most effective projects have been skunkworks projects, where engineers have taken total ownership of a problem and driven it to completion. I want to normalize that.
Now that feels to me like a somewhat "old school" approach to development, and one that — being somewhat old school — I recognise from an earlier phase of my career.
"When I was a younger developer" we all got stuff done by just diving in and, well... getting stuff done!
We collaborated, we brought in people with specific, relevant expertise if we didn't have it ourselves (or couldn't acquire it qwuickly enough), and we solved problems as we went along.
Sounds kind of "agile"1, doesn't it? But this was in the days before seemingly everyone had gamely swallowed The Agile Manifesto whole and GANTT charts were still the main measure of project progress.
A process is only good if it's a good process
When we think about how these processes came about, we realize they carry a pessimistic mindset. They box people into smaller roles to minimize the chance of not meeting a certain standard... We’re building an environment that is optimistic about what engineers can own and achieve and embraces the innovative engineers (and frankly, often stays out of their way).
For me this is an interesting perspective.
In the context of "agile", the traditional "waterfall" process is presented as being both slow and adversarial — the requirement to plan everything in advance slows things to a crawl, requires everyone (both client and vendor) to understand everything in detail before the first line of code is committed to a repository.
Agile is supposed to address that by acknowledging uncertainty and putting processes in place to deal with it whilst also allowing work to not just begin but actively progress without necessarily defining everything up front. An attractive notion, isn't it?
To be completely fair, I have seen very successful work being done in agile teams. We use agile methodologies at Deltatre. I like the idea of agility and pragmatism, and of simple processes brough together to help talented individuals to collaborate effectively and to manage their workload, increase the cadence of delivery, and create predictability.
I have, however, also seen agile used as a dogmatic crutch to cling to, despite prevailing evidence showing that it wasn't working in that specific situation and context.
Getting the best out of good people
To accomplish this, our engineering leaders need to think deeply about individual performance, process, and culture - not running sprint planning or driving product and technical decisions. You’ll focus on building your team, their skills to thrive with the ownership they’re given, and an environment that empowers them to do their best work consistently, with little distraction.
For me, that's the most interesting part of this particular approach.
It's very easy to get sucked into the process for the sake of the process, and yet to also hold too tightly to the reins and to the ownership of the decision making within the team.
In my experience the best way to get the best out of an engineering team is to make sure that they are aligned on the target outcomes and get out of their way.
Footnotes
-
Notice the lowercase "a" there. I try to avoid the classic blunders — I don't get involved in land wars in Asia, I never go up agianst a Sicillian when death is on the line, and I certainly don't get involved in religious wars over agile frameworks. ↩