A Dumb Guy's Guide To Agile (Redux)
Revisiting an old post
Back in 2017-2019 I worked as a lead engineer and acting principal engineer in the digital transformation team at Co-op Group. Looking back, it was a ridiculously talented group of people—alumni have gone on to high-profile private sector work, government work, various high-prestige startups and and I’m aware of colleagues that were founding directors of a unicorn or got their startup aquired by a big-ticket tech multinational.
The value of agile lies in developing systems around feedback loops to iterate to the desired business outcome.
Anyway, at the time I tried to distil what I learned about agile into a post that was a 1-minute read. It wasn’t bad.
Since, I’ve worked for a startup that was later acquired, contracted as a fractional CTO, done numerous digital transformation and due diligence projects, been the technical lead1 for a blockchain, started a company,2 and launched two blockchain protocols.
So what have I learned since?
Funnily enough, the original post mostly stands up. Probably the main thing I’d change is making the importance of trust3 even more central to both facets of delivery. I’d also emphasise feedback loops. To some degree, what you’re really trying to do with agile is:
Identify the desired outcome
Develop systems around feedback loops to iterate to that outcome
In a sense, this terser definition is even better than my past one, as it doesn’t rely on specific tools, approaches or conditions; it is generic advice (in the good way!).
As sharper readers will have spotted, as this is a generic approach, it won’t have any real impact unless the right outcome can be identified. That’s a very deep rabbit-hole, and outside of the scope of this post.4
However, in the spirit of the original post, I’ll have another crack at it:
Tech side
What?
Reduce cost of change
Reduce cost of failure
Fail fast
Identify and solve the right problems
How?
Trust
Staff agency
Experimentation
Automation
Iteration and building feedback loops
Why?
Deliver faster
Be able to scale solutions
Make money
Save money (either absolute terms or TCO)
Address correct outcomes
People side
What?
Meet user needs
Reduce staff churn
Improve ability of staff to address relevant business problems
How?
Diversity of thought and experience5
User research
Building trust
Building agency
Iteration and building feedback loops
Why?
Deliver smarter
Solve the problems people care about
Make money
Save money
Address correct outcomes
In both the ‘why’ sections, I’ve made a clearer link to business outcomes; in both the ‘how’ sections I’ve foregrounded trust and agency.6 I’ve also dealt with staff retention, hiring, churn and output in various guises in my consulting work, and so that has to be added to the ‘what.’
In both cases, I’ve seen a lack of agency expresses itself in both an inability to identify the most important problems, and then a lack of agency to actually tackle them.7
Finally, I’ve brought in the points about outcomes and systematizing feedback loops. Even within a business, you need to think about scaling an approach, and that’s what systematization does—allows you to take a playbook and apply it to different systems, processes or problems within a business to drive an outcome.
Indeed, it’s why, during my time in a transformation team, I worked on projects that were digital-first, in-store, in funeral care (both physical and digital) in data, and in hardware. The same set of analytical tools and system thinking can lead to problem solving in heterogenous domains. It’s basically what I’ve been doing since, both in my day job and my academic work.8
CTO? It’s not clear what job title even fits when the job description is, “you do or co-ordinate everything technical, from docs to releases, and you work for a DAO where every user is a financial stakeholder.”
Whose unofficial blog you are kinda sorta reading right now.
With my pendantic, academic hat on, I might suggest instead confidence, citing De Filippi et al. (after Earle), to describe a feeling of consistency or predictability that can be calculatively reasoned by agents, but that’s awfully specific.
Speak to your users!
Or perhaps, plurality, following Nate Silver’s reasoning in On The Edge. In my not-so-old age I’m beginning to think that some tension in a team might be constructive, as long as it’s focussed on the approach to the work, rather than interpersonal issues.
This is, of course, a wider critique of the current pervasive neoliberal paradigm we find ourselves in (I’m thinking specifically of Dr Abbey Innes’ 2023 book, Late Soviet Britain: Why Materialist Utopias Fail). Everything is regulated, quantified, and ultimately inflexible and ineffective. Or, as a stakeholder once put it when I worked at a learned society, “everybody’s a jobsworth.”
Very occasionally, there’s also a lack of skill or capacity as well, but very rarely have I found a lack of will or willingness, particularly among line employees. Due to organization politics or ability, I can’t say the same of management or senior management.
The common refrain “that’s a testable hypothesis,” which I seem to hear all the time in the UCL Computer Science building, is something I can also imagine a former boss of mine like Rob Bowley saying. While I’ve got your attention on former colleagues, you should read his and Katherine’s blogs.