The essence of agile and plenty of snake oil

Arcticle originally posted on Polar Squad’s website.

In February 2001, seventeen privileged white men gathered at a skiing lodge in Utah to talk, ski and relax. At the end of this two-day trip, the Agile Manifesto was born. It is a document that loosely defines what these men thought should be preferred in software development to make it better.

Over 20 years later, we have countless frameworks and agile is now absolutely everywhere. Yet, I do not think it’s the agile the authors of the Agile Manifesto intended. In most places, it certainly is not what I would want it to be.

So what is the essence of agile and where did most of us go wrong?

After a few years of working in Scrum teams in the early part of my career, I found myself frequently pushing back against some practices that crept up in many of these teams. I found it frustrating to watch a team of developers and stakeholders arguing over whether a 15-minute task was really of size 1 or 2. I found it frustrating to find the same team having to explain why they again missed their “promised” sprint target. I thought this had very little to do with being agile. Fortunately, I found I wasn’t the only one (see the whole #noestimates movement). In general, I had very little interest in what a Scrum book would tell me if it did not seem to help the team or the customer.

Some time later, I was happy to notice that someone had coined my thoughts with what they referred to as “Modern Agile” – with no framework but instead four exact points:

• Make People Awesome

• Make Safety a Prerequisite

• Experiment & Learn Rapidly

• Deliver Value Continuously

Let’s elaborate on each of these points. The first point, “Make People Awesome”, is a great reminder that we are not here to make a great product or a great company, but rather to make our customers awesome at whatever they do with our products or services.

American author and entrepreneur Seth Godin famously said, “People aren’t afraid of failure, they’re afraid of blame.” The second and third points underline that in order to gain the benefits of iterative development, we must fearlessly try new things, measure them, learn and adapt. But if you get blamed every time you try something that turns out to be a bad idea, you will very quickly stop innovating and return to doing waterfall development disguised as agile.

The final point, Deliver Value Continuously means that good ideas are not worth much if it takes ages to get them into your customer’s hands. Innovation is actually defined as the practical implementation of ideas that result in the introduction of new goods or services. So it’s not just you and your colleagues doing a little brainstorming session that makes your company innovative.

I firmly believe that the above list is all that is needed to define agility in software development. So what does this mean for you? It means that in the end it’s all about people, and different people work and communicate differently. Therefore, no framework or prescription is perfect for you. You can and should borrow ideas from others, test them, and keep or discard them based on whether they improved the four pre-mentioned points for you, your team, or your organization.

I’m a big proponent of agile when it’s pragmatic and holistic. But to be honest, I’ve tried my best to not use the word agile for several years now. This is because I feel so many efforts in agile, agile transformations and scaling agile have ruined the term. Many of these are just misunderstandings, but there’s also lots of snake oil perpetuated by agile consultants, big frameworks and organizations offering certifications. There’s so many ways to do faux-agile that you could easily compile a book about it, but I’ll go through some of my favorites next.

Scrum

Scrum is the most widely-adopted agile framework. It’s a simple framework with a bunch of practices and ceremonies. None of which should be done just because Scrum says so. Each might be beneficial for your team. Each can be practiced in a misguided or even malicious way.

Sprints were originally designed to protect the team from outside interference. Unfortunately, in many places it’s now used to squeeze the team to promise which exact tasks will be ready in the next two weeks. If the team and stakeholders instead focus on prioritization, each task completed would deliver the most valuable things at that very moment. If some things get pushed to the next sprint, they would be the least valuable or time-critical.

Planning poker or story estimation used to be quite popular. This is the process of estimating the work required by a specific story before it’s included in a sprint. I’m not quite sure where this came from originally but I’ll emphasize this here: current official Scrum Guide does not mention word estimation one single time. I’ve always considered estimation useful and estimates useless or even harmful. For me, estimation is useful when the team really thinks through what they are actually building. Then they can look at the story and consider: Is this a small story? If you know it is not, instead of trying to estimate the work required, continue splitting the work until you find something small that still produces value or answers a question.

Another anti-pattern is turning the daily stand-up into a reporting session. Instead, the team should focus on things like: Does someone need help? Can I help finish something rather than starting something new?

Out of all the ceremonies in Scrum, the only thing I would never give up is a retrospective. No framework will ever be perfect for your team. But if you have a process of frequently looking at how you work and trying to improve that through frequent experimentation, I can guarantee you will find ways of working that are better suited for you than anything out-of-the-box.

Backlogs are probably the most ubiquitous concepts for managing agile projects. I’ve had the pleasure of meeting Mary and Tom Poppendick, the authors of Lean Software Development. When we met, Mary stated flat-out that backlogs are one of the most harmful concepts ever. One great way to understand your software development is with a value stream map. You draw a map of how a product feature flows from an idea all the way to the hands of the customers. In that flow, every backlog is a delay. In a perfect world, a backlog should be a very short buffer that has just enough items to keep a team working. This would allow for the fastest possible loop for new ideas and learning. But instead, most backlogs are endless lists of wishful thinking. By the time your team arrives at item 157, they will spend most of their time figuring out if that item is valid anymore, wondering what the original meaning of it even was months ago when it was created.

Certifications

Learning and studying are essential for personal and professional growth. They allow individuals to acquire new skills, knowledge and perspectives, and to stay current in their field. Software development is definitely a field where constant learning is necessary. Different organizations offer a plethora of courses for agile development and different associated frameworks. Quality of the course is highly dependent on the teacher. It’s easy to explain the bits and pieces of a framework. It is much harder to communicate the essence of why, when and how to apply the learnings. You know, the stuff I tried to explain in the beginning of this article.

It’s hard to communicate the essentials of an agile way of working, as it’s so highly context specific. Something that helps one team in their quest might be harmful for another team in their environment, personalities and organization. Now try to turn this into a multiple-choice exam: The correct answer to pretty much everything would be: “It depends.” Anything else encourages dogmatic following of a framework, which could not be further from what it is to be agile.

So by all means, try and find a good teacher or a mentor for your agile journey. But remember that it’s all context specific and the devil is in the detail of applying and adapting the learnings to your context. I do not see any value in certifications in this context. And yes, I have a whole bunch of certifications, including agile certifications and I do see the irony of it.

SAFe

In 2011, the dark dungeons of Nokia gave birth to a monster. It was a scaled agile framework clearly designed to allow some sense of agility without offending anyone in a highly bureaucratic, project manager-driven organization. The framework was called SAFe, or “Shitty Agile for Enterprises” as software engineer and thought-leader Martin Fowler dubbed it. It alone has probably done more harm to the agile community than anything else.

On the team level, SAFe offers no surprises as it happily mashes together well-known practices from Scrum, Lean, Kanban and XP. But on top of those, it layers a system so complex that the diagram depicting it looks worse than the London underground map. All these added layers seem to have very little to do with agility and in most cases the end result is that your project managers or product owners are now called “release train engineers” and nothing else changes.

I’ve worked in many organizations that use SAFe. Most typical change is that a sprint is no longer considered the unit in which people expect results. Instead, it’s now a PI (Program Increment), “a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems”. This puts a drastic slowdown of cadence and unjustifiable overhead into planning that only encourages a waterfall approach to development.

It is understandable that when aiming to “scale agile”, it’s much easier to sell a highly prescriptive framework with courses and certifications than the hard truth: in most cases you should not “scale agile” and when you do, it needs to be built from the ground up to adapt to your people, teams and organization. But a highly prescriptive framework is as far from agile as possible. The fact that it’s often pushed from top to bottom as an “agile transformation” makes it even worse, as people will do it “because they are required to do so” rather than embrace it as their own and something they can and should adapt to their needs.

If my criticism of SAFe feels unjustified, don’t take my word for it. Tens of respected thought leaders in software development and agile methodologies have written testimonials on how they find SAFe harmful. You can read those here.

Agile has come a long way since its inception in 2001. However, in many cases, it has strayed from the principles outlined in the Agile Manifesto. In this post, I argued that the essence of agile is to:

• Make People Awesome

• Make Safety a Prerequisite

• Experiment & Learn Rapidly

• Deliver Value Continuously

These principles should be the focus for teams and organizations, rather than blindly following specific frameworks or practices.

It is important to remember that different people work and communicate differently, and therefore, no one framework or prescription is perfect for everyone. By testing different ideas and discarding those that do not align with the four principles, teams can improve their agility and better serve their customers.