Where I Think “Agile” is Headed, Part 3: What Is The Recipe, The Right Answer?

I started this series asking where “Agile” was headed. Part 1 was about the 4 big problems I see. Part 2 was why we need managers. This part is about how people want a recipe, The Answer, for how to get better at “Agile.”

Before we can address what an answer might be, your need to know your why for an agile approach.

Why do you or your organization want to use an agile approach? Let me be clear: What is the business reason (or multiple reasons) for considering an agile approach?

Too often, I hear things like this: “do more with less.” Or, “deliver faster.” Or, “become a 10x team.” Those are expressions of business reasons. They mean:

  • Our cycle time is too long. We think the work is too expensive for the value we perceive.
  • Our cycle time is too long.
  • How can we get the teams to perform better?

If you take the meaning, and not the words behind the imperatives, you see the need for a culture change. Can “Agile” deliver on that?


Let's first discuss why “Not-Agile” creates these problems.

Why Do These Problems Exist?

If you are not a software person by training, you might think typing is the thing we need to optimize for in software.

Nope. Typing is the easiest part of writing software. The hard parts are these:

  • Understanding what the person/team who touched the code before you did. Did that person leave enough tracks or tests so you can learn what they meant?
  • Understanding the boundaries of the current code. Do you have tests so you can create small, safe-to-fail experiments?
  • How to make decisions about how to take the code to the next place to get more value out of the code (product). Do you know how customers use the current code so you can make good decisions?

All of these problems are about learning. As we learn together, we can create the product.

The Hard Part of Software is the Learning

Typing is how we construct the product. However, software is learning, not construction. We rarely—if ever—create exactly the same thing twice. Why would we? Why wouldn't make that first thing into a library and reuse it?

How do you learn when you create software? You walk through the code. You might ask questions of other people. You might create tests to interrogate the code. You might create prototypes to do small experiments.

What happens if you get stuck? You might talk to the duck. Even better, you might bat around problems with other people. Why other people? Because they have insights you don't.

That is why pairing and mobbing work so well for software. Not because they're “agile” practices. (They're not. I paired back in 1982. I've been part of tiger teams where we mobbed and swarmed, as far back as 1980, I think. Long time ago.)

When we work with other people, we learn how they see the product, the questions, the code and tests. We learn from and with them.

This learning is why we cannot divorce technical practices that create excellence from any project approach. You can do all the iterations or WIP-limiting you want. If you don't add technical practices, you cannot succeed.

But That's Not Efficient, Right?

So many managers are stuck in resource efficiency thinking they do not understand this one key idea:

If you ask the team to collaborate as a team and ask them to focus on one thing at a time, achieving what done means for that thing, you can get the benefits of any agile approach.

Busyness looks efficient. It's not effective because busyness creates long cycle times.

Team learning and team delivery is effective.

How Do We Become Effective?

Maybe I'm unique but I don't think so. I become most effective when I work with other people. Jessica Kerr uses Nora Bateson's definition of symmathesy: a learning system made of learning parts. (I urge you to start with Jessica's definition and read/watch everything she says.)

When we work as teams, we bring our past learnings with us. That's why having varied backgrounds and experience makes great teams.

We learn as part of our current team. We bring our past interactions and learning to our current team. That's how we create symmathesy—ripples that pay dividends for our lives and work. (That's why many people who look for jobs look for people they can learn with.)

Effective software teams use flow efficiency, so they all learn together. They need to practice and exercise all their technical excellence, so they learn how to work right and continually improve the product and their work environment. The more often they make little improvements, the faster they can learn.

That means you can't use an agile approach as a project framework and expect that to work. Yes, an agile approach might help you organize your work.

You must use technical practices along with how you organize your work to be effective.

Why Do People Search for the Answer or the Recipe?

When I meet people as I did at the conference, I meet people who feel as if they are under pressure. More pressure to go faster. More pressure to deliver. Their managers use Theory X approaches to make sure the teams finish more tickets and increase each person's velocity. (Personal velocity? Ugh. Total misuse of the ideas.)

When people feel significant pressure, they stop thinking. They want the recipe, the one right answer.

The problem is that each team is unique. Each project is unique. The agile approach that works for me might not work for you. Context matters.

Every Team Generates Its Own “Recipe” or “Answer”

How do you choose which agile approach to use? Which technical practices? It totally depends on your context. There is no recipe.

However, we do have principles. Review the Principles behind the Agile Manifesto.

Are there any principles you “can't” live now? You will challenge the culture with any agile approach you choose.

An agile team needs to learn enough about how agile approaches work so they can generate their own “recipe.” And, they need to reflect at frequent intervals so they can assess their current effectiveness and create experiments.

My “Right Answer” is Principles

If you followed me through this post, here are my principles:

  1. Collaborate on the work, as a team.
  2. Make technical excellence a cornerstone of everything the team does.
  3. Limit the WIP (Work in Progress) so everyone can learn together.
  4. Improve the product and environment as you go, so the learning is easier.

Do those things, and you can get all the ideas in the first paragraph: reduce the cost of creation, shorter cycle time, and higher-performing teams.

Agile approaches require collaboration inside the team and with the people who want (or the people who represent those people) the product. If you can't get collaboration, will an agile approach help?

There is no “Agile Recipe.” There is no One Right Answer for everyone in your organization. You can use principles to decide what works for you.

The entire series:

4 Replies to “Where I Think “Agile” is Headed, Part 3: What Is The Recipe, The Right Answer?”

  1. Johanna, I think the problem is more complex than how you described it. Even agile influencers or “big names” would not agree together what Agile is about and what to expect in the organization. If reduced to SW development practices only, there probably could be some free form of agreement over some techniques. Unlikely beyond. https://www.linkedin.com/pulse/agile-transformation-definition-business-enterprise-michal-vallo/

    I think polarized agile community to agile business and agile hippies derailed original intention to improve organizational performance through new techniques and people engagement. We have many trainers and “heads of transformations”, who never read any book about agile. And second big problem is that too many organizations are just branches of big multinationals hunting for cheap resources for auxiliary works, so innovation and improvement is in fact not required. When Agile became popular, they wanted it too, in a cheap form without training and practicing, expecting miracle, but unable even verbalize what the miracle should look like to recognize it when they get it. And finally, success is “expressed” by measures fit for orange paradigm and not green or teal (using Laloux’s color coding). M.

    1. Michael, thank you. I agree with a lot of what you wrote. While I have read Laloux’s book, the colors don’t stick with me. I’m more apt to use Schneider’s 4 quadrants.

      As to what you said about trainers, heads of transformation etc not even reading any books about what an agile approach is or even about lean thinking? Oh yes. That occurs way too often.

      I don’t have a problem with people hiring others all over the world. I wrote a book about how to be successful in a distributed agile team. I do have a problem with attempting to shift work from “expensive” to “cheap” labor. When you ignore the cycle time for the work, you can’t achieve the cost savings you want.

      I see much of this as a failure of management. Just as I would expect programmers and testers to build their technical and interpersonal skills, I expect managers to build their management skills (and interpersonal! skills). I see too many people focused on the short-term and ignoring the long-term.

  2. Collaborate on the work, as a team.
    – I agree. Unfortunately management systems are designed to reward the individual. I have suffered in my career for caring more about the team than in promoting myself.

    Make technical excellence a cornerstone of everything the team does.
    – Agree. Many organizations don’t invest in technical excellence and learning. I worked for a consulting firm once and I was “on the bench” for an extended period of time. I asked to take a course that would make me more marketable but they demurred. Short-sighted.

    Limit the WIP (Work in Progress) so everyone can learn together.
    – Agree

    Improve the product and environment as you go, so the learning is easier.
    – There are two problems I’ve encountered here.
    — 1. Managers are rewarded on getting things done, not in paving the road for future success. . They’re not rewarded for “improving the product and environment”
    — 2. Many software professionals are inept at making business arguments for investment for the future. I’ve coached many developers on increasing their skills in this area. “I need to spend a week to refactor this code”. “Why?” “Because I don’t like how it’s structured”. Many developers don’t have the skills to convert their technical points to business value or simply don’t try. “Trust me” is not a convincing argument.

    1. Adrian, I wrote about management incentives in Designing an Organization for a Product Approach, Part 1. An agile culture requires the entire organization to optimize for the organization. Yes, managers will have to make difficult decisions re the short-term and long term. And, they need to make those decisions as a team.

      I wonder if the divide-and-conquer mentality for managers originates in HR. Too many HR people do not understand culture and organizational design. Argh.

      I agree with you that software people need to make business arguments. If they want to refactor, show me the cycle time for how things work now. Let me weigh those costs against releasing a new feature. I wonder if this is because too many people have been infantilized by their previous management. If someone else makes all the decisions about your work, how would you know how to create good arguments for or against?

      I always asked my managers about the data they needed. I wonder why other people don’t default to that position—helping their managers—rather than falling back on the “it’s the right thing to do” argument. Hmm. Might be another post.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.