Five years of Agile, a retrospective

Over the past twenty years I’ve worked in IT under one guiding principle: don’t do it yourself if the machine is intrinsically better at it. As it turns out, the machine is a lot better at many things than I am and it keeps improving. I’ve intrinsically been doing agile and DevOps since before they were “things”. Over the past five years agile methods crept into my work environment. Here is something of a retrospective of my experiences working in such environments.

Humans first

So what does “Individuals and interactions over processes and tools” really mean in practice? In some cases the principle holds true, but not by a wide margin. That’s why I would like to rephrase this princple a bit more strongly: humans first.

No matter how awesome the tools, no matter how slick the process, humans are the one essential ingredient for success of any kind. Respect them, serve their real needs, listen and adapt.

Too many teams and organizations still fail to respect their humans. You’re dealing with professional adults. You hired them yourself. You pay them every month. Why is it so difficult to trust them to do the right thing? Thou shalt not micro-manage any professional ever, nor bend them to fit your toolbox.

Maintain your conscience

The manifesto states “Working software over comprehensive documentation”. In practice this all too often gets interpreted as a get-out-of-jail-free card and no documentation gets written at all. After all, who needs documentation when the software works in production?

For one, documentation serves as the development team’s conscience. Properly written source code documents the ‘how’ and the ‘what’ on its own and Git captures the evolution over time. User stories capture much of the ‘why’, so most of what is traditionally expected of documentation is already present in some form.

The problem with user stories is that they are ephemeral. The coloured post-its survive only as far as the next retrospective, if they’re even that lucky. I’m a strong advocate of using the retrospective itself as an opportunity to write down and update a centralized story of the ‘why’. Doing this updates team’s collective conscience and history, allowing future members and stakeholders a chance to learn from past mistakes.

Documentation on the ‘how’ and ‘what’ is easily generated from annotations inside the codebase. Enshrine these in your definition of done and respect them. Use generators to create searchable online documentation automatically. Those who inherit your code will thank you for being considerate.

Negotiate the journey, not the destination

“Customer collaboration over contract negotiation”, preaches the manifesto. This is where the manifesto radiates idealism over realism. The sentiment is honorable, but there are a few pitfalls here.

At the very least, lay down the groundwork of the collaboration itself in a proper contract. Openly and clearly agree on the method to be followed, the roles involved and the commitments required from all parties.

This is different from negotiating a traditional contract over concrete results, features and delivery dates: the kind of contract this principle from the manifesto intends to address.

In its idealism, however, the manifesto seems to skip over the very real need for formal agreement on the details of the agile development method.

Play chess, don’t go bowling

Agile is all about permitting change in the name of value: “Responding to change over following a plan” is one of the underpinnings of agility. Instead of inviting outright anarchy, the popular Scrum method deals with this principle by prescribing time-boxed sprints.

While it is permitted to abort a running sprint and reboot the team, my experience tells me that it’s often inadvisable to do so.

Sprints usually take only a few weeks and the members of the team are committed to achieving the sprint goal. This goal is assumed to be a sensible, realistic and above all valuable target.

Refinement took place, the sprint was planned, work is under way and points are being burned. Interrupting this flow now may be absolutely imperative in the case of some unforeseen calamity. By all means, do proceed in such cases. However, in practice, most “calamities” really aren’t all that urgen can wait until the next sprint.

Aborting a running sprint destroys quite a bit of invested effort and, at best, postpones the value that would have been added by achieving the sprint goal. In the worst case the sprint gets aborted, the fix for the urgent calamity introduces breaking changes, and the aborted sprint’s refined backlog doesn’t fit reality anymore. Not only does this have a measurable impact on team velocity, it can also put a huge damper on the team members’ motivation. Product owners should use this powerful instrument sparingly.

So please do adapt to change. It’s impossible not to do so. But please do stick to the plan as much as possible once it’s set in motion. Your next move is only a short sprint away. In software development it’s usually better to play chess than to go bowling.