Agile papercuts

I’ve worked on a few projects and I’ve tried many ways to run them. The agile manifesto is a great starting point, and should be in your bookmarks for quick reference. But when you put it into practice, your first thought is the mistakes you made last time, the lessons you learned, so you can do better this time.

So you look at where things failed, and you add a process around it, maybe one of your own, making taking inspiration from others.

For example, you had a big problem with release management in your last project, and git flow is a process for release management, so you try it on for size.

But the planning decisions about when to deliver features, and how the support and feature releases work together are not changed, because it was a release management problem, not a planning problem. So you add more process.

STOP

Let’s assume you don’t have time for root cause analysis of everything that caused you pain last time. Just assume everything is causing some pain, but for some things the benefit outweighs the cost.

How do you spot what causes more pain than benefit?

Does your process support the people, or sideline them? Is the documentation useful or mothballed as soon as it is delivered? In other words, are you valuing the things on the right more than the things on the left?

As developers, it is a long battle to get over your ego, and the sunk code fallacy, and learn not to be precious about the code you’ve written because the product you’re delivering can always be improved, and if your code is no longer fit for that product, it should be removed. Celebrate the code you no longer have to maintain.

As tech leads, we can be just as precious of our procedures and our practices, but they can be even more painful that the code. They’re harder to refactor, to measure, to test, because people are less predictable than code, but we need to be willing to identify waste, and identify the pain points so that we can address them, and remove practices if necessary. Measure where you can, but don’t be afraid to be as ruthless with your process as you are with your code. Anything that didn’t add value is weighing you down, and even those small papercuts that sung every time are worth removing.

Whatever you think Agile Is, even if you think Agile Is Dead, don’t forget your process is as much a part of the delivery as the code you produce. Own it. Trim it.