Revised 2017-07-05, adding Techniques.

Part of this “New Framework” idea – maybe all of it – is to try to clarify my thinking about “Agile”, what it means, and how to express it. That got me thinking about the high-level terms we use to describe it, terms like “Values”, “Principles”, and “Practices”.

My primary interest is in “Agile Software Development”, which is what the Manifesto was all about. But we’ll need to set this in context, of course, addressing management concerns, product concerns, executive concerns, and so on. Right now, I’m not sure how far I’ll press in those directions, since more than these others, I care about developers.1

Practices

I’ve liked the term “Practices” for a long time. Practices are things we do, and to me, nothing happens except as a result of what we do. And they are things we practice, meaning that we work on them continually, to improve our ability to do them. But there are issues with the word.

It’s important to practice, and to work, mindfully. We have to pay attention if we’re going to improve. If TDD is one of our practices, we need to pay attention to when our tests are too big, or too small, or too easy, or too hard. We have to learn from our TDD practice how do do it better. We have to learn what TDD can tell us about our code, and how our coding style affects our ability to write tests. TDD can teach us a lot, if we pay attention.

To some people, practices are just things you do mindlessly. So maybe the term is a problem.

To some people, if something is a practice, they want it to be a best practice. Arguably there are no “best” practices, just practices that are sometimes useful. How can we know when they’re useful? Well, my guess is that we have to do them often enough, and mindfully enough, to be able to decide.

To some people, if something is a practice, that means you have to do it. And I intend the word you here: they are inclined to tell you that you have to do this thing. I don’t care whether they are telling you that in their blog, or telling you that from their management throne, or from their ScrumMaster bully pulpit. To me, the team’s job is to decide, wisely, what practices are good for them. To make these decisions, they need to try a lot of things, and try them carefully enough to be able to decide.

So, to the extent that “practices” implies, to some people, mindless practice, locking in on something as best, or something to be imposed, the term is a problem. What might we talk about instead? How about “skills”?

Skills

Part of this New Framework effort seems to be going in the direction of grouping or generalizing specific ideas. I’ve written about Whole Team including the notions of cross-functional teams, as well as the Customer and Product Owner ideas. Similarly, I expect that Programmer Tests and Customer Tests are going to wind up in a grouping that I’m tentatively calling Confidence.

Maybe TDD is a Skill. Maybe Programmer Tests are a Skill or, more likely, represent a broad collection of Skills.

The term Skill might work nicely. We can always increase skill: we’re never there. And we can always add new skills.

The notion of Skills might lead us to an appreciation of life-long learning, of perpetual curiosity, of setting learning objectives and attaining them.

I’m liking the word Skills, at least for now.

Techniques1

My friend and colleague Joe Rainsberger mentioned the word “techniques” on Twitter. That seems to me to be a word we’d like to include and use judiciously.

There is a Skill, Refactoring, that one needs in order to produce software continuously without slowing down. There are Refactoring “Patterns”, such as Extract Method, Remove Middleman, and Replace Dynamic Receptor with Dynamic Method Definition.2 Sometimes the patterns are just called “refactorings”. Some people call them “refactors”. I don’t like those people.

Perhaps those refactorings should be described as Techniques that one might know as part of some larger Skill. That said, while there is a sort of implicit hierarchy forming here, with Skills being made up at least in part of Techniques, the hierarchy is at least quite deep, and perhaps not a hierarchy at all but a network. It wouldn’t do to parse these terms too finely, but it would be nice to have some way to express that these ones are components of those ones. But …

  • Continuous Delivery
    • Continuous Integration
      • Habitable Code
        • Refactoring
          • Extract Method
            • Visual Studio Refactoring Tools
              • Typing
                • …

This could go on for quite a while. I don’t think we’d do well to give all these possible levels names. Still, both Technique and Skill have different connotations and the distinction might be useful. We’ll see.

Values

I’m more and more troubled by methods having “Values”. It was OK for the Agile Manifesto to mention values: they were four shared values that those aging white men held, on those days in that time. We didn’t say that you should have those values: we said that we had them.

When we say, however, that XP Values are Communication, Simplicity, Feedback, Courage, and Respect, what are we saying? If we mean that the inventor of XP had those values in mind when he created XP, that’s fine. If we mean that XP is designed to improve communication, increase simplicity, provide better feedback, and enable courage, that’s fine. If we want those things, XP might be a way to get them. When Kent Beck added “Respect” to the list in his second edition, was he saying that doing XP will increase people’s respect for one another? Or was he saying that we need to have respect for one another in order to even try XP? Honestly, I don’t know.

If, however, we say that in order to apply the ideas of some framework, you must have these values, I think we may be going too far. People have the values they have, and they can’t just switch to new values when they show up at the office.

I don’t have a better word than Values at this moment. I might continue to use it, if I need it, or I might come up with a better word, or I might address the areas the term covers in other ways. For now, I have a concern and no solution. That’s fine.

Miscellaneous

I’ve seen and used words like “Rules”, “Guidelines”, “Standards”, and the like. And we of course have terms like “Sprint” and “Iteration” and “Meeting” or “Event”.

I’m more concerned about the “higher-level” terms but words are important. We’ll keep working on this.

To come …

I’m sure I’ll have more to say about this. My present plan is to keep these articles in roughly a sensible order to be read like a book, so I’ll probably come back here with updates.

Feel free to write and offer ideas. Better yet, join the Slack mentioned below.

  1. Added 2017-07-05. ↩ ↩2

  2. I bet you don’t know what that last one is. I didn’t. No, I’m not going to tell you. Look it up. :) ↩