What I wish I had said ...

Let’s try this again. The previous article was not clear to all readers. I suppose this is often the case with my work but in this case I thought I’d try again. What’s my point, anyway??

Too many frameworks

I do believe that there are too many “Agile” and “Agile”-related frameworks. They are not different enough to justify their existence, in my opinion. There certainly are differences, including:

• Some frameworks are as simple as their authors could make them. Crystal Clear and Scrum are leading examples. These frameworks explicitly require that those who use them use retrospectives of one kind or another, to see how things are going and to decide how to improve.
• Some frameworks are more specific. XP is an example. XP amounts to an enhancement of Scrum to include certain technical practices for building software. It’s worth noting that Jeff Sutherland, Scrum’s co-creator, says that these practices are essential.
• Some frameworks are little more than restatements of an existing one, created, I believe, to give their creators a brand of their own, and to allow them to re-emphasize the things they believe are important.
• Some frameworks are compendia of ideas from other methods, “Agile” or not. These tend to be variants of RUP, and are often aimed at large organizations. The compendia may or may not offer some of their ideas as optional.
• At least one framework seems to be a rather cynical compendium of every software development ever formulated, sold with a name and style that look to me to be intended to confuse the customer into thinking they’re studying the other, more popular, more reasonable, method.

Now, I believe that almost all of these offerings are sincerely trying to help, although some of them are rather visibly aimed at creating a “business” by riding the “Agile” wave. Even so, there’s nothing wrong with creating a product or service that serves a growing and important market.

Nonetheless, I believe there are too many frameworks for the good of the people the Manifesto Authors were trying to help, namely people trying to build software. And I’m not saying there should only be XP, or only be Scrum. As I write this article and the previous one, I’m almost wishing that there were no methods at all.

All that matters is what we do

Go with me here for a moment. Yes, thinking is important. Intentions are important. Good feelings are important. Whatever you’re reacting about right now is important.

Nonetheless, it is only our actions, not our thoughts, intentions, feelings that impact the universe. Our thoughts, intentions, and feelings may inform what we do, may change what we do, but in the end, it is the doing that changes the world.

The word “practice” refers to things that we do. Our practices, the things we do, are what changes the world. Yes, we choose them with our thoughts, our intentions, our feelings. But when we practice them, we change the world. If our inner state does not emerge as action, we’ll have no impact.

We improve by adaptation

An essential notion of the “Agile” methods, and of most every other thoughtful idea about how to succeed, is that we’ll look at our environment and our results, and we’ll change what we do to improve our results.

We’ll change what we do. We’ll change our practice.

Now sometimes we change our practice very directly. We observe that there are defects in our code, and we just begin to test it.

But often, the first change we do to our practice is less direct. We observe that there are defects in our code. We’ve heard of testing. We set out to learn what testing is and how to do it. We read a book, check on Stack Overflow (no help there), ask our friends. We take a course in testing, or in Agile Developer Skills. Then, maybe later, we actually begin to do testing.

The best changes we make to what we do come from learning new things, internalizing them, applying them to our situation, observing, learning more, applying more, improving more.

What about frameworks and methods?

There are lots of frameworks within which we might work. Here are a randomly selected few to show some breadth:¹

• Scrum, which tells us to create cross-functional teams, drive them with business needs, ship software every couple of weeks, and improve.
• XP, which does similarly, with some starting technical practices.
• FAST, which says to do XP … ?
• Kanban, which says to begin where you are, limit work in process, and pay attention to figure out improvements.
• Lean, which says to focus on people, eliminate waste, pay attention, figure out improvements.
• SAFe, which says to build a large hierarchy of organization flowing features down to people who would be doing Scrum+XP except that you’ve never trained them. (SAFe does say “train everyone”. That has never happened, not even once.)
• LeSS, which apparently says to get rid of all your managers and then do Scrum with some really interesting enhancements.
• DAD, which says to do RUP with some of the phases removed and some of the details renamed, and with a massive menu of alternative things to do and ways to do them. (This is not far wrong, in some regards. We’ll discuss that in a later article.)

All of these, and many others have a form which can be generalized to this:

1. Start somewhere;
2. Do some starting things;
3. Pay attention;
4. Improve by changing what you do.

Note that the improvement only happens when you change what you do. Note also that where you start probably has little effect on how far you improve, though it may affect how rapidly you do so.²

Improvement comes from our practices, not from our methods

Or, to put it another way, improvement comes from what we do within our framework, not from the framework itself.

Or, to put it yet another way, improvement comes from the practices we choose, within our “Agile” or “Agile”-like framework, not from the framework itself.

So that’s why I was musing the other day about what would have happened had the Manifesto Authors gone on to emphasize much more strongly “Individuals and interactions over processes and tools”, to the point of making clear that even their own processes, and their own tools, were only flimsy starting points, within which we need to seek out the very many practices that add up to success. I was wondering whether we could have reduced or eliminated the proliferation of frameworks we have today, producing instead a much more healthy ecosystem of ideas and help around what we should try next on our never-ending road to improvement.

But that’s water under the dam, over the bridge, and up the creek. We can’t rewrite the Manifesto and wouldn’t if we could. But what about tomorrow?

Focus on practices NOW?

I’d like to suggest that we’d do well to look beyond the framework we use to start, no matter which it is of the ones mentioned here. We would do well to realize that while these starting positions may be interesting – although probably not as interesting as their proponents think – what matters, always, is what we do next.

There are many “practice realms” out there, including but not limited to:

• Product visioning
• Need identification
• Planning and estimating and not estimating
• Contracting
• Working with humans and other animals
• System design
• Database Design
• User Experience Design
• Testing
• … and many many more …

Within each of these realms are innumerable books, videos, web sites, articles, experts, trainers, courses. There are resources of all kinds. From this universe of information, our job is to select things that may be helpful to us, learn about them, and apply them to our practice.

Apply them to our practice. Change what we do, so that we can change the world.

That’s what I’m talkin’ about.