iDIA Computing Newsletter
April 2022
April 2022
I've been mulling over something that John Banmen, a therapist and a major force in the Satir Institute of the Pacific, mentioned on a Satir Global call last year. He was talking about different models of therapy, how some derive from the same sources and have overlapping models. Some therapists stick with a particular brand of therapeutic model. Another possibility is using one model as a base, and integrating other ideas with it. This he likens to a chemical compound, mixing ingredients and coming up with something new. Others take an eclectic approach, using ideas from different models at different times--whatever suits the context at hand. They may return to one model that they use as a base understanding. John referred to this as a mixture, where the components retain their individual characteristics rather than joining to form something new.
There are many Agile brands. Agile itself is a brand name created at the Snowbird gathering where, in 2001, proponents of various "lightweight methods" of software development gathered to find common ground. They decided to name that common ground "Agile," as that was a better brand name than "lightweight." Among the brands at that meeting were Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming.
The Agile approach I first heard of was Kent Beck's eXtreme Programming, which is somewhat of an anti-brand. The name certainly gave me the wrong impression before I looked into what it was. It sounded like random hacking, much like my son's thrashing on his skateboard. As I recall, one of the thoughts behind the name was that large stuffy consultancies would be unlikely to co-opt such a name. Still, it was a brand name that proponents could use to represent a collection of concepts briefly, making conversation easier. And it was perhaps a brand name that would attract the cool young kids who were willing to push the envelope.
Both before and after the Snowbird gathering, people were offering brands that fit the Agile category. Some of the names, such as Adaptive Software Development and Feature Driven Development, were descriptive, trying to clearly represent the contents on the outside of the box. Others, such as Scrum and Crystal, were more opaque, requiring a closer look in order to think you knew what they meant. Some brands show their roots. ScrumBan, for example, merged ideas from Scrum and Kanban, codifying a mixture of the two methods into a new named compound brand.
Branding gives a name to an idea, or a cloud of ideas, and provides an easy reference that doesn't need to be re-explained every time you mention it. At least within the context of those who know the brand, the name lets them know what you're talking about. This is true even if they don't like the brand. When I mention "Wonder Bread," it brings to mind a sliced white bread with a very consistent texture, even for people who prefer a whole grain bread with seeds and nuts embedded in the crumb. For people who don't know that brand name, they generally recognize that fact and can ask for an explanation.
Branding creates a recognizable term that turns something amorphous into a solid impression. This can also have side benefits for the brand creator, giving them higher visibility. Becoming associated with a brand is a public relations or marketing boost with people who hold that brand in high regard.
Marketing consultants will tell you that a brand has many benefits: recognition, credibility, trust, loyalty, and others. These can be used in the pursuit of higher profitability, if you're selling something or some services associated with the brand. These benefits also support non-economic marketing, encouraging a greater acceptance of the ideas.
Controlling the brand gives some measure of control over the usage of the ideas, at least as far as they're associated with the brand. You get to say what the brand means, and what doesn't qualify. You get to offer official descriptions, books, and training under the brand name to educate people in the proper use of the branded ideas. You can license other people to offer similar materials and services using your brand name. Branding is important to building a larger business.
In use, brands shift in meaning and become diluted. Bandaid is a registered trademark of Johnson and Johnson. Over time it has, in popular usage, been used to signify any adhesive bandage. Worse, it's often used, even more generally, to describe a superficial covering that obscures a problem but does nothing to alleviate the problem itself.
If that can happen to a trademark being defended by a major corporation, what hope does an informal brand coined by a group of people, some competitors with each other, who gathered to find their common ground. So we have seen the term Agile applied to many things, some which look very un-agile to many long-term practitioners. For some people, "Agile" has become a dirty word, reminding them of micro-management and software development death marches — problems that Agile was intended to solve.
It's no wonder that some have tried to re-brand Agile more specifically, to recover or extend the original meaning. Hence we have Modern Agile created by Josh Kerievsky and Heart of Agile created by Alistair Cockburn. These both seem attempts to more tightly control the meaning of the brand, restoring its value without restricting its usage.
Circa year 2000, a common question within the eXtreme Programming community was "Do you have to do all 12 (or 13, depending on who was counting) practices of XP to say you're actually doing XP?" What if you left out one practice, such as System Metaphor? This was arguably the least favorite XP practice, and one that many people found difficult to implement in their particular situation.
A related question is this, "Can you still call it XP if you keep doing the heavyweight software development practices that your organization has always done?" Certainly if you have a monthly Change Management Board that meets monthly to review and approve or reject any ideas proposed for development, you're missing the spirit of eXtreme Programming.
These questions try to make a clear distinction between what is and what is not XP. For brands of ideas, this may not be the most important distinction to make. The ideas of Agile Software Development were intended to make software development easier, more productive, and better suited to a changing world and our changing understanding of our goals.
Paul Raynor, speaking of Behavior Driven Development at CukeUp 2015, reached for the work of Paul G. Hiebert in his studies of Christian missionary methods. (http://thepaulrayner.com/bdd-is-a-centered-rather-than-a-bounded-community/) and suggested the concept of a centered rather than bounded community. This makes it harder to draw a line between inside and outside the community, but it makes it easier to focus on the reasons you created the community in the first place.
The purpose of this essay exploring how we think about ideas is to bring clarity to why we're attracted to those ideas and why we want our actions to be guided by them. I didn't get involved with eXtreme Programming because I was attracted by the brand name. Instead, I found the ideas within it congruent with what I'd previously found helpful. Investigating the brand introduced me to new ideas that, while they were foreign to my previous experience, were being touted as also helpful. And I acquired fellowship with a community of people who had an overlap of goals and experience with mine.
This does not mean that my goal is strengthening the XP community. My goal is to become better at what I do, and I don't restrict myself to the ideas centered around XP. I will, however, appreciate the XP community with fondness for how much I grew in association with that community. I still find the ideas centered by XP to be very valuable, and continue to use them where appropriate.
P.S. What are your thoughts on branding vs ideas? If you want to talk about it, we can use my Discovery Session mechanism to set it up. Let's talk!
Or you can also simply reply to this email or send an email to newsletter@idiacomputing.com to continue the conversation. There's a person, not a bot, on this end. I'd really love to hear from you.