My Current Thoughts on the Most Useful Parts of Agile Development

In real life, if you sprint repeatedly with small pauses in between, that’s not sustatinable, that’s ‘interval training’, which is a method to drive yourself to exhaustion in the shortest possible time! I think language actually has a really important role in influencing our expectations and mindset. I would prefer to call iterations ‘jogs’ or ’laps’ to express the endurance that should be expected. Or simply, ‘iterations’.

The infamous daily stand-up meeting can definitely have value, but it usually snowballs out of control into a ramble that takes up most of an hour. People should practically be prevented from giving a status update in standup meetings, and asked a hard yes/no question “Are you blocked?”. If the answer is “Yes” it is immediately followed up (interrupting any attempt at a long-form status update) with a short exchange organising a time for a breakout call or meeting afterwards. I would go for having more structured meetings in general and prescribing an Amazon-style method with agendas and even reading time at the start of the meeting.

On to Jira…if the organisation of the project tracking has too much focus on the customer or management goals, instead of on assisting the team itself, engineers and testers won’t use it, and will start to take up their own informal methods to track their own to-do lists in e.g. text files. ‘User stories’ should probably more often be ’epics’, and allow people to freely create and manage their own small tasks underneath that.

I used to be excited by the idea of ’evolutionary’ software development, where many small iterations can eventually create complex software, that is still working and effective at every point. I was inspired by the theory of how an eye would evolve in a biological organism - starting as a small light-sensitive cell, and ending up as the complex visual organs that we know, while always being useful to the organism. While this feels like a romantic and sophisticated model, in practice it’s painfully easy to become trapped in evolutionary dead ends (or local maxima/minima, if you prefer the mathematical perspective).

One thing that pulls us towards a dead-end state is abandoning half-assed work at the conclusion of a sprint. Bluntly, when too much emphasis is put on meeting arbitrary completion metrics at the end of a sprint, people will sign off half-assed work to meet those metrics. The process has turned into the infamous ‘scrumterfall’ where the sprint is a deadline instead of a periodic self-assesment. Documentation and comprehensive testing are the first to be left aside, as usual, and a year later we have a huge complex piece of software with very little of either. I hear the opinion “Don’t ask for time to do documentation and automated tests, you shouldn’t ask for permission to do your job” but that’s putting a lot of pressure on individual programmers who don’t have any customer, management, or regulatory guarantees to back them up.

Another thing, is when close collaboration with the users is blocked or stalled. Unfortately the person comissioning a software feature is often not a user themselves. And the person talking to them is not an engineer, but a product manager or business analyst, who can fall into the trap of that guy in Office Space. “I take the specifications from the customers and bring them to the engineers!” “You physically carry the printout of the requirements?” “No, my secretary does that.” So we have two layers of indirection between the people who actually need (or don’t need) the feature and the people trying to make it for them. With the smallest teams, best customers, and the most socially astute programmers, it can be possible to get everyone in a room and sort out a fantastic outcome, but that rarely happens, and when it does, actual ‘user delight’ may be experienced.

I’m suspicious that a lot of Agile processes were created by studying a strong high-performing team, and copying the methods they used. But the cause and effect are backwards. The methods did not make the team stronger and perform better; the strong and high-performing team made those methods possible.

The original sin of Agile is the co-opting of it from a set of tools and guidelines to empower workers, into an prescription that disempowers them and increases the frequency of the monitoring and control imposed on them. While it is now often described as the “failed revolution”, the original spirit of the manifesto is still there to be found.