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?
Maybe.
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:
- Collaborate on the work, as a team.
- Make technical excellence a cornerstone of everything the team does.
- Limit the WIP (Work in Progress) so everyone can learn together.
- 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 series so far:
- Where I Think “Agile” is Headed, Part 1: Do You Need an Agile Approach?
- Where I Think “Agile” is Headed, Part 2: Where Does Management Fit?
- Where I Think “Agile” is Headed, Part 3: What Is The Recipe, The Right Answer?
- Where I Think “Agile” is Headed, Part 4: What Does “Agile” Mean?
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Where I Think “Agile” is Headed, Part 3: What Is The Recipe, The Right Answer? Opinions expressed by Java Code Geeks contributors are their own. |
