Agile: Stay away from the light
15 years ago, working in an often chaotic tech industry in Dallas, Texas, “Agile” seemed like a gift from the gods. Here was a seemingly developer-centric approach to organising and delivering software with realistic ways of setting expectations around delivery dates, and an emphasis on sustainability. It felt empowering, human and open-minded.
So, of course, the first thing I did was to dive headlong into Scrum, being a “Scrummaster” and “story points”. I was an evangelical advocate for all things Agile, with a side of TDD, a sprinkling of XP and eventually getting my WIP limits on with Kanban.
I learned a lot and I carry a lot of those techniques and patterns of working along with me in my career. Indeed, I still consider myself a firm advocate of Agile thinking as expressed in the original manifesto. I am profoundly interested in agility as a concept as it is deeply tied to my professional endeavours, and because the businesses I love working for seem to do better things for the world when they remain agile.
As human beings, we are good at optimising for least effort in attaining goals, especially in the context of a small number of reasonably defined constraints. This is one of the things that makes a process like Scrum so compelling. Sprints, stand-ups, retros etc constrain and synchronise cadence and working practice. Typical implementations encourage deferring estimation (and detailed analysis) of business requirements until late in the delivery process (or perhaps just-in-time if you’re a true believer). “The Team” have something to focus on and gather around in the morning.
In ye olden days of those mythical “waterfall”, structured-programming projects, it would have been project status meetings or delivery checkpoints that teams focused on. BRDs and documentation were constraints we could rely on. Roles focused on particular disciplines also helped focus particular people on particular attributes of the project’s deliverables.
The Agile Manifesto was largely an opportunity for technologists who were sick of process-centric engineering to refocus their efforts on engineering the product or software they were delivering, rather than the artefacts which contemporary processes had become optimised to produce. Now, 20 years on, Agile has in many ways become the new Waterfall.
Because Agile processes (or methods) have become defacto in the industry, teams spend a lot of time focusing on the process artefacts (post its, Kanban board, backlogs, story sizing, cycle time, sprint commits etc.) All of these are useful, healthy concepts to consider and use within a healthy delivery team. However, when they become the focus of someone leading the team or delivery or project, it becomes very hard for a team to focus on doing their job well.
That’s why I’ve started to advise my teams to stop using these processes and to refocus their attention on engineering great solutions to the particular business problem at hand. Any delivery process (just like the analysis, testing, deployment and support) of a product should be developed as needed and justified for the particular business case at hand. In particular, care should be taken to ensure that the technical architecture is the core focus of the team as the technical architecture, more than any other concern, tends to determine the agility of the team, it’s delivery and the software’s future value.
Process and team structure should be secondary concerns to the primary focus of optimal technical architecture for most business projects. Until we get that back, I think we should stop doing Agile, and stay agile ;)
