Skip to main content Skip to Footer

BLOG


March 09, 2017
Values, practices and tools: A top to bottom approach
By: Keith Pleas

I have a very simple pyramid model…so simple that it borders on the trivial. Yet, I am constantly trotting it out to illustrate critical issues in delivering software.

I can easily describe this model in words, but instead, let’s start with an image:

Values practices tools 1

In showing this around, I got an unexpected response: “It’s upside down,” one person said. “Values are the foundation.”

If you think about this in strictly physical terms—say, as a representation of a mountain—I could see that.

Still, I believe most immediately grasp the idea, which is that you start with “Values,” derive the “Practices” that support those values, and, finally, acquire the “Tools” that enable those practices.

Oh, wait… that wasn’t obvious?

Show Me the Money

Twitter. This opens a new window.

Well, it’s certainly not obvious if you look at all the money spent on software tools—billions upon billions of dollars collectively.

There is “medium” money to be made in Practices, as people who create a new practice typically earning good livings; even their disciples (masters and certification trainers) do pretty well. In our world, this aligns with many of the practice consultants who drafted the Agile Manifesto.

But how much money is there in Values?

Um, not much. You might be able to name a motivational speaker outside of software who has done well. But when was the last time you watched a software conference presentation on values, or picked up a book on that topic, or paid a consultant a lot of money to advise you on “values?”

So, in terms of dollars spent, this might be a better distribution:

Values practices tools 2

By the way, the terms I’m using for these layers are not particularly precise. A strong case could be made that “Culture” would belong at the top, with “Process” and “Methodology” in the middle, and maybe “Platform” in the bottom tier.

The exact terms are not critical, but I would consider adjusting the boundaries like this:

Values practices tools 3

As I said previously, the proper, top-to-bottom order is significant, Values to Practices to Tools. After all, haven’t vendors been telling us for years that if you buy their tool, you will (immediately, quickly, real-soon-now) reap those values?

It almost doesn’t matter what that value is—quality, speed, security, whatever—buying their tool is the fastest and best way to achieve that.

Of course, you know it’s not that simple. And, so do the vendors, which is why they create or partner with others to create all the collateral to make adoption a success.

Know the “Why”

Twitter. This opens a new window.

Still, it’s your responsibility to know why you are adopting that tool, because that is how you ensure you’re aligned with your organization’s Values.

I find this model particularly helpful when communicating the role of leadership. Leadership, after all, didn’t even get mentioned in the Agile Manifesto, so it’s common to assume that it’s not really necessary in modern software development and delivery.

Except, of course, it is.

It is the unique privilege and responsibility of the organization’s leaders to create and communicate these Values.

But that’s only half of the story. They must also reward for delivering on those Values. If, instead, they reward for alternative Values, then they’ll get alternative results and end up with misaligned Practices and Tools.

What’s Your Mission?

So, what are your organization’s values?

One clue can be found in your mission statement. But it’s increasingly popular these days to say “We want to be like Netflix (or Facebook, or Amazon).”

But note that for many years Facebook’s culture was to “Move Fast and Break Things.” Is that appropriate for your organization?

Reed Hastings, CEO and co-founder of Netflix, posted his “Netflix Culture: Freedom & Responsibility” presentation from 2009 on SlideShare. Amazon’s “Leadership Principles” are well-publicized.

Are those appropriate for a large enterprise such as yours? Well, you might not be surprised to learn that I have another model—one that distinguishes between cloud startups, cloud-native disruptors (like those I just mentioned), traditional enterprises and an aspirational “best in class.”

I’ll be sharing that model in my next post. Stay tuned.


constantly trotting it out to illustrate critical issues in delivering software.

Popular Tags

    Archive