I started this series asking where “Agile” was headed. (I didn’t like what I saw at the Agile 2019 conference.) Part 1 was about the 4 big problems I see. Part 2 was why we need managers. Part 3 was about how people want a recipe. This part is about what “Agile” or “agile” means.
I understand that people want what they perceive as the value “Agile” will bring them. Let’s return to the Manifesto for Agile Software Development, what I call the “Agile Manifesto.” (Dave Thomas would have a problem with that, but I’ll use it as shorthand.)
Why a Manifesto?
We’ve had a software “crisis” even before I graduated from college, 1977. What was the crisis?
- Projects were “overdue.”
- Projects were “too expensive.”
- Product quality stunk.
Sound familiar?
How did this happen? We didn’t pay enough attention to process.
I learned about structured design in my master’s courses. I’m pretty sure I learned about UML drawings in the 80s. I already knew about coupling (bad) and cohesion (good).
None of our processes helped us reduce the time or cost for our projects. As an industry, our product quality still stunk. (The first Chaos report was published in 1994.)
Enter the Age of Process
The original release of the CMM/CMMI was back in 1991. The thinking was if we could get the process right, we could get great products faster, cheaper, and with better quality.
My problem was that the CMM/CMMI—even with Watts Humphrey’s addition of Personal Software Process and Team Software Process—is that the process treated software projects as if they could be planned. Sort of like construction projects.
I do not know of any sort of product construction that does not iterate on the requirements and design. You might, but I don’t.
Several project-y things occurred in 1984:
- The first release of Microsoft Project.
- The PMI created the PMP in 1984. At the time, the PMP was more focused on construction projects. (This is what I remember. I might be totally off the mark, here.)
Too many people thought software projects were the same as construction projects. (Nope, software projects are about learning together, as a team.)
In the 1990s, many people assumed that if we:
- Got the process right
- Nailed down the requirements at the start
- Followed more construction-based approaches
We could get the software projects right.
I was never able to do that. I thought I was stupid. I wasn’t. I saw my reality and reacted to it using incremental approaches.
Software Reality in the 1990s
If you haven’t read Weinberg’s Quality Software Management series, or McConnell’s Rapid Development, never mind Smith and Reinertsen’s Developing Products in Half the Time, you might not realize how early the agile approaches started. I read Fast Cycle Time when I program-managed for a client.
The ideas behind feature-driven (incremental) approaches started at least in the 90s. I started to use the words “inch-pebble” back in the 70s. Many of us project managers used interim deliverables—at least internally—and reassessed and adapted our plans when we saw what the teams delivered.
I never used an iterative approach for the feature sets. No, I almost always used the “implement all/as many as possible” the features in this feature set for the next month. My timeboxes were never longer than a month, back in the 70s, 80s, and early 90s. (I started to use shorter timeboxes sometime in the mid-late 90s.)
Those of use who used waterfall approaches and released something every couple of months to a quarter succeeded. Those of us who used incremental approaches and were able to use continuous integration and might release every month or two also succeeded.
The rest of the projects did not succeed. They got stuck in requirements hell. Or, architecture/design hell. Or, testing hell. Unless they tried a Hudson Bay start.
(One note about releasing: we released on hard media: tapes, CDs, disks. The cost of releasing was high. It wasn’t until the late 90s that we could start to regularly release over the web.)
The process-heavy approaches didn’t work. Lightweight approaches with frequent releasing did work.
Lightweight, not Process Heavy
The authors of the Agile Manifesto wanted to help the software community succeed. They had seen—in their work—that lightweight approaches, based on finishing value and getting feedback worked much better than any process-heavy approach.
Think about that for a minute.
These people were practitioners. They saw the death marches in projects. They saw that the lack of team-based work made everything more difficult. They saw that without continuous learning, we would repeat the same problems again and again. And, the thing that surprised me the most when I read the manifesto was the integration of the customer into the team.
How could the customer be part of the team?
Then, I remembered some significant projects I’d been a part of and led. When I worked directly with the customer, I got more feedback. It didn’t matter what kind of a product: a control system for a factory line, an inspection system for car parts, analytical chemical instrumentation. When I worked with a customer, I did less work, had more feedback, and had a better product.
The projects that used lightweight approaches didn’t take too long. They weren’t high cost. I often got to stop early—when the customer said I was done.
At the very least, my projects weren’t crises. My projects were almost “better, faster, cheaper.”
Who wouldn’t want that?
How Often Can a Team Release Something?
When the Agile Manifesto authors met, they knew about a big problem: too many teams couldn’t release anything at all. The project teams had big problems, especially the Requirements Spawn Requirements problem.
How could you ever get out of the requirements phase if you couldn’t stop the requirements from changing?
That’s the beauty of managing WIP in some form: Only focus on the requirements for the next week or so, or the WIP in a given column. Sure, you know other things will happen. Don’t worry about them yet. Don’t implement ahead.
That freedom helps teams release something. The more often a team can release, the more often they can get new work. And, the more often the team releases, the less big change the project has. It might have small changes, but no big changes.
That was the problem the Manifesto authors wanted to address. What to call this lightweight approach to software product development? An “agile approach.”
“Agile” is not a Noun
Notice that “agile” approaches offer teams a ton of freedom. We can select from any of the methods/frameworks/approaches and see which, if any, fit our context. An agile approach is one, or a combination, of the many possible lean approaches to software product development. Scrum is just one of the many possibilities. (See Agile Does Not Equal Scrum: Know the Difference.)
I saw Dave Thomas’ talk Agile is Dead a couple of years ago. Then, I read his post, Agile is Dead (Long Live Agility). Go to about 10 minutes into the video if you want to see how Dave thinks about agile as an adjective.
What Dave said that most resonated with me is:
You can sell people nouns. You cannot sell an adjective.
We have an “Agile” industry. However, too few people actually understand what an agile approach is.
Not only is “Agile” not a noun, it’s not a proper noun. If you use “Agile” as a way to describe what you do, what does that mean to you? Agile approaches are an umbrella term, not a proper name. You have many options to create your successful agile approach. It’s not one name/term; it’s all the possibilities the principles behind the Manifesto.
What An Agile Approach Might Be
If you are thinking about an agile transformation or an agile approach for a team or a program, please consider what an agile approach might mean to you.
An agile approach helps you release what your customers want when you want to release that value. (See A Working Definition of Agile).
If you don’t need to release too often (that problem determinism again), you might not need an agile approach.
That’s not a problem. You don’t have to use a waterfall approach. You can use an iterative or incremental approach if they fit your context/needs better.
If you can identify your business problems and you realize you might need an agile approach, you might decide to ask teams to collaborate as a mob to spread the knowledge and solve problems faster.
You might ask teams to limit their WIP so the throughput is faster.
You can do this and not need a named agile approach.
When teams move to single-piece flow, they don’t need standups. They might not need planning sessions. They might, every so often, need to look at the roadmap and discuss/create tests/leave breadcrumbs so they don’t forget the risks they need to manage.
And, don’t forget the retrospectives.
Don’t Let Process Names Confuse You
I meet a lot of people and teams who tell me they use Scrum. (Sorry to pick on Scrum, but it’s got such name recognition that “everyone” tells me they standardize on it and use it.)
I ask about the retrospectives: How often does the team spend at least 45 minutes reflecting on the past and learning from that work?
“Rarely, because our managers don’t want us to spend the time.” That’s when I explain the role of managers. And, that retrospectives build resilience and learning into the work.
If you’re not retrospecting and learning from past work, you are not using an agile approach. The retrospective is the one practice the Manifesto principles specify. (I recommend you read the principles first, before deciding on a framework/method/approach.)
Read Something
I see too many management teams who want the value of an agile approach and they don’t realize what they’re asking for. I encourage them to read something (maybe more than one something) and discuss it before committing to an agile transformation.
Several years ago, I wrote Minimum Reading List for an Agile Transition.
At that time, I didn’t realize agile approaches required a culture transformation. Since then, I recommend these of my books:
You don’t have to like my books. There are many other useful books. I happen to be approach-agnostic. I find the agile principles much more useful than any specific practices.
Managers, please make sure you want what you’re asking for, in terms of an agile transformation. If you don’t want the teams to be autonomous, to collaborate, and to learn with each other, don’t ask for an agile transformation.
As the teams learn, they challenge traditional and hierarchical management. Make sure you want the side effects of an agile approach, not just the supposedly “better, faster, cheaper.”
The more managers read, the more they learn what an agile approach is. And, they might stop asking for “The Agile” which doesn’t make sense. I realize managers have way too much work to do. And, I know managers need to know what they want.
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?
I know I need a wrap-up post.
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 4: What Does “Agile” Mean? Opinions expressed by Java Code Geeks contributors are their own. |
