Corporate Values: Really Valuable, or Really Just a Poster?

You hear about the agile values and they seem to make sense, but what the heck is a value system? And how do you use value systems in your daily work? Do your values really help you do your job better, or are they really just a poster in your office kitchen?

When I say values, I’m talking about beliefs that guide behavior – as opposed to the term value meaning ‘the benefit of what is being produced.’ In software we use both “agile values” and “business value,” but they represent different things.

Corporate values have peppered company literature for ages.  These value statements are important expressions of the community and culture within a company.  In larger organizations, however, those values are often so abstract that it’s tough to impact a team’s work.

The notion of a value system to guide agile software development emerged in Kent Beck’s inclusion of values with the introduction of Extreme Programming (XP) in the late ‘90s.   A similar set of values was added to Scrum soon afterward. And soon after that, the Agile Manifesto was born. It brought software teams a straightforward value statement that today remains a powerful influence on the behavior and success of agile software development teams all over the world.

The concept of a human value system has been reasonably well studied in psychology since the ‘50s, but before 1999 (when Kent posed the question, “What is it that we value?”), developers simply didn’t talk about values – only the work at hand. People brought abstract, personal values in to work with them, which may have influenced behavior lightly.  This introduction of a value system was one of the most innovative parts of XP.  The XP values are Communication, Simplicity, Feedback, Courage and Respect. With the Agile Manifesto, that contribution expanded to the broader software industry and beyond, opening a new focus on behavior and improving the way we do things.

Let’s back up and define the agile values…

Watch this video: “The Agile Manifesto – 4 Agile Values Explained”

Sound familiar?

You’ve probably seen these agile values introduced in agile training, and they are easy to learn. They also read well on posters. But how do they affect you every day, every sprint, every release?

The utility of the value system is often lost to the intense focus on the agile frameworks and practices. Back when XP was still the most common agile approach, I gave a popular talk that included asking the audience, “What is XP?”  Invariably, it would take many minutes and an awkward silence after all of the practices were exhausted for someone to timidly mention the values.  Most certified Scrum people are not be able to articulate the Scrum values.  Of the roughly 150 words squeezed into the official Scaled Agile Framework® diagram, only one of values, Code Quality, made the cut (alignment, transparency, and program execution are the omitted three).  We have a long way to go to appreciate the important role that values play in enabling teams to be empowered to adapt their practices and maximize their delivery.

So, why are these values so important?  Aren’t we doing OK with the values being the footnote they are?

To see the answer, one needs to look no further than the frustration expressed around the dogma of agile.  A common complaint of Scrum team members is an almost irrational commitment to follow the rules of Scrum blindly.  Ironically, one reaction of the Scrum community to SAFe™ is that it is overly prescriptive in how organizations should scale Scrum.  In both cases, an increased focus and incorporation of the values leads teams to a better place.

In the absence of shared values to guide the adaptation of our practices, teams are left to resort to static rules to guide their behaviors.  We see silly arguments like “Should the Product Owner participate in the Daily Scrum?”  In the context of the Scrum values (Focus, Courage, Openness, Commitment and Respect), a team can answer that question easily and optimally by themselves.  We don’t need to enforce consistent practices, as long as teams apply the values to their situation.

Let’s explore some specifics 

The agile values system can guide daily decisions about working through problems with teams and individuals in a way that corporate values may not be able to.  Any problem we are trying to solve can be addressed with more rules and process, more contracts, more documents, more upfront planning.  Those are our traditional, comfort-zone, status quo solutions.  I can almost guarantee that in an early sprint retrospective with a new agile team, some of the feedback will be, “Had we spent more time documenting up front, we would not have had this problem.”

There will be times where those items “on the right” in the Manifesto will be part of the solution to our challenges.  But a commitment to our values will drive innovative solutions that better support our use of agile.  Examples include the increased use of tele-presence technology with distributed teams — reconstructing our workspaces, reconfiguring teams, and even relocating people — and collaborating with people we didn’t even realize were involved in, or affected by, our work.  The values will guide us to solutions that enhance agile, rather than contradict it.

One of my favorite examples where the values guided the solution to a problem was an SDLC compliance change at a very large financial services company.  Existing SDLC practices required numerous artifacts to be delivered within each phase of a project.  Requirements documents had to be signed off during the requirements phase, prior to design, etc.  The agile advocates needed this process requirement changed to empower agile teams to deliver shippable increments in each sprint.  But this needed to be done in a way that was still compatible with the majority of project teams who were still following the phased approach.

So, rather than create a big conflict, demanding that the whole process be changed, a simple change was made.  Audit artifacts are still required for the business, but teams have discretion as to WHEN artifacts get produced.  All of the artifacts are required when they close projects, but the team decides when it is optimal to do it. They don’t have to sign off on a Requirements document in the beginning of a long plan. Requirements can be modified over time, and they can furnish a signed-off Requirements document at the end. This moved the organization closer to the Individuals and Interactions value, while respecting the importance of Process and Tools in the broader organization.  A dogmatic stance on Scrum practices would not have been so open to that solution.  Later, further updates gave teams more discretion of WHICH artifacts were valuable enough to produce, further empowering the teams for continuous improvement.

So, the next time you’re in your Daily Scrum or Retrospective – or even just solving a problem – reflect on what is being talked about. How are teams and individuals working together to identify solutions? As you move across release and process design (teams and programs), pull out the agile values and assess whether your decisions and those of your teams reinforce the agile values or diminish them. Are they helping the organization make decisions that drive working software?  Use the values to guide your solutions and improvements.  If values aren’t helping people do their jobs better, why bother? At that point, they are just poster fodder!