What is value?

The majority of agile related articles, blogs, books keep telling us that value is paramount and that we should sequence work by value and that we should be value driven. However, none seem to tell us what exactly value is and what exactly the author means. A notable exception would be the well thought out work available at Black Swan Farming’s Web site.

Most likely, this lack of specificity is due to the realization that nailing down the definition of value is hard and we run into all sorts of problems when we try and concretely define what that term really means.

The first question that pops into mind is: “Are we talking about customer value, or business value, or operational value?” Those three are not the same and sometimes what’s perceived as valuable from one perspective is frowned upon by another (e.g., better utilization of pizza delivery drivers/vehicles negatively affects quick delivery to customers). Additionally, the word customer is ambiguous–are we referring to the user or the buyer of our product or service?

To complicate matters further, we often have situations where something may have customer value but no business value. For example, the company may not want to invest in the development of products or functionality because it is too costly relative to the revenue it’ll provide; likely will be hard to maintain; or inconsistent with the company’s strategy, competitive positioning, or brand. In certain situations, the reverse is also true–there are things that may be valuable to the business but not to the company’s customers. A company investing in analytics and business intelligence reporting to better determine how to target customer segments, or a company consciously making a decision to deliberately lose X% the least profitable (or unprofitable) customers, are examples of items with no customer but significant business value. The same line of thinking can be applied to operational value as well–things need to be done to keep the lights on or to improve the ability of existing systems to service current and anticipated needs.

As if that wasn’t enough, a further complicating factor is that value is not a constant; it changes over time. Fashion trends and seasonal clothing are examples where value becomes negligible at the end of a narrow time window. On the other hand, the value of specific tax functionality increases dramatically the closer we get to tax season but plunges once early tax filers discover that the functionality they need doesn’t exists. A similar but smaller window opens up for late filers but that disappears after April 15th as well. What this means is that we cannot prioritize work based on “value” once and forget about it–there is a need to revisit this every so often.

And finally, we ignore the very real possibility that someone else will come along into the market, disrupt it, and refute all of our assumptions. This becomes more likely in competitive environments for high value-add products, services, or features.

A number of IT departments try to get around this problem by treating the business as a customer and by doing what the business asks for in the order asked for. But, the business is NOT the customer! They are partners that together provide value to the customers. When we start treating internal groups as customers we lose sight of the real customers and start prioritizing work based on the (often conflicting) needs or perceptions of the many internal groups.

Common ways of calculating “business value” are ROI–the benefit (or return) of an investment divided by the cost of the investment expressed as a percentage or a ratio–and NPV, that unlike the point-in-time ROI considers the flows of money over time. However, NPV is difficult to calculate accurately due to significant assumptions about discount rates and future inflows. And neither work well when dealing with non-profits–they care about other things over making financial profits. In reality, there are multiple goals of an organization:
– reduce costs
– gain market share
– build better relationships with a customer segment or intermediary (e.g., latino roofing contractors)
– increase assets under management
– code maintainability, security needs

And when we really think about it, doesn’t the, currently in-vogue, term “business value” really mean what is valuable to the company? And shouldn’t everyone and every group/function/division already be doing what the company values? Does the term “business value” as currently used really add any additional meaning?

Considering the difficulties, I’ve come to believe that we need to abandon the idea that business value is a simple formula into which we can plug-in values ahead of time and apply to feature sequencing. Instead, we need to realize that “value” requires interpretation–and sometimes a sole product owner doing all the interpretation does not make work well.

We instead need to focus on the organization’s goals and the desired outcomes. Value of proposed initiatives, then is their ability and degree to address the sought after strategic goals. Lower level initiatives/projects/whatever should be in support of those higher-level goals–the battles should help win the war.

And because, of the rapid rate of change, we cannot know up-front exactly to what degree an individual initiative will contribute to the higher-level goal(s), we must treat the proposed initiatives as hypothesis. As we really do not know with certainty what is valuable and to what extent, we encourage experimentation, learning, and continuously improving our ability to meet the desired goals.

How have you defined and used value when sequencing work?

 

Are leaders and the company culture the real problems to agile adoption?

Most surveys about the state of agile, point to the existing culture and leadership as the primary causes of agile struggles. But are those two, and their derivatives, really the culprits?

Isn’t it curious that our goal, as agile coaches, is to deliver value by ascertaining how best to meet the needs that are determined by the organization, and yet we consider the organization itself to be the biggest impediment to doing so. Is it possible that the problem is not in the organization’s culture and management structure but in our own assumption that there is a singular definition of value and our determination to deliver on that definition despite the organization we are trying to transform? Could it be possible that the client organization understands what is value in ways that we do not?

G. K. Chesterton in this 1929 book, The Thing, said:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

This paradox rests on the most elementary common sense. The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep. It is highly improbable that it was put there by escaped lunatics who were for some reason loose in the street. Some person had some reason for thinking it would be a good thing for somebody.  And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious.

There are reformers who get over this difficulty by assuming that all their fathers were fools; but if that be so, we can only say that folly appears to be a hereditary disease. But the truth is that nobody has any business to destroy a social institution until he has really seen it as an historical institution. If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, or that they have since become bad purposes, or that they are purposes which are no longer served. But if he simply stares at the thing as a senseless monstrosity that has somehow sprung up in his path, it is he and not the traditionalist who is suffering from an illusion.

In other words, an organization’s culture has evolved for a reason and has likely been strongly influenced by what the organization has found to deliver value in the past.

Culture is a pattern of shared tacit assumptions that was learned by a group as it solved its problems of external adaptation and internal integration that has worked well enough to be considered valid and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems. ~ Edgar H. Schein

Since it’s inception, any organization has had to learn what strategies, values, procedures, behaviors, and norms work within its environment. Those that do not further the company’s mission are discarded; those that do are retained and progressively improved over time. This history of learning, by trial and error, is rarely written down but forms the basis of tacit assumptions and norms — the collected wisdom about what leads to success within the organization. What is valued by the organization, then, gets encoded in the company’s culture and their bureaucracy. To the uninformed, this bureaucracy may at first glance seem capricious, brutal, and wasteful, but it is simply a way for the organization to ensure that people pay heed to what is considered important in that organization. For example, the “burdensome” security scans, reviews, and audits in some financial institutions only point to the organization’s belief that doing right by the client is important and that their personal data must be protected at all costs or that our brand is everything to us and we shouldn’t needlessly take on risk that might harm our brand image and reputation.

The Chesterton’s fence principle applies to agile introductions as well. Again, Chesterton’s fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood. Just because there doesn’t seem to be a readily apparent reason for this fence to be here doesn’t mean there isn’t a reason. What this means is that Agile coaches must first come to understand those values, strategies, and goals that are embedded in the client organization’s culture.

Most agile proponents however, are far too eager to tear down what exists, without first understanding why that exists, in order to put in place what they believe is “agile” and “better.” It is the rare agile coach that takes the time to first understand what the company values — most coaches are aware of one way of doing things (insert the name of your go to agile framework here) and want to jump straight into the mechanics of implementing it. They often do this because they want to demonstrate, to the client, that they themselves are adding “value.”

The result of not heeding Chesterton’s fence is that the agile coaches frequently run into “resistance.” This resistance is chiefly due to the client management’s perception that what they value and what their concerns are aren’t being considered.

Agile proponents come in and say we should discard X and do Y instead in order to not have to deal with the negatives of the existing X.


X     |       Y
|
+                |
-----------------|---------------
-                |
|
|


But clients believe (whether incorrectly or not) that the benefit of the agile evangelist’s point of view (Y) leads directly to a loss in what the client believes is important to her (X). In addition, they perceive that the new approach simply swaps in a different set of negatives.

What coaches could do instead, is to work together with the client to come up with a solution that explores how to get the “new” benefits without losing the benefits of the existing approach/culture. Instead of approaching the transformation in a “big bang,” where the existing culture and structure is swept away in one fell swoop, a measured incremental approach where we learn as we go might be better. Agile coaches could take an agile approach to agile adoption — drive organizational change incrementally and make course adjustments based on what they learn about the organization’s true needs and dynamics.

But clients believe (whether incorrectly or not) that the benefit of the agile evangelist’s point of view (Y) leads directly to a loss in what the client believes is important to her (X). In addition, they perceive that the new approach simply swaps in a different set of negatives.

What coaches could do instead, is to work together with the client to come up with a solution that explores how to get the “new” benefits without losing the benefits of the existing approach/culture. Instead of approaching the transformation in a “big bang,” where the existing culture and structure is swept away in one fell swoop, a measured incremental approach where we learn as we go might be better. Agile coaches could take an agile approach to agile adoption — drive organizational change incrementally and make course adjustments based on what they learn about the organization’s true needs and dynamics.

 

Being a Discerning Thinker (aka Understand the Mental Models that Drive Your Thinking and Behavior)

What goes through your mind when you hear or read a statement like, “Change is hard?” Most people simply take it at face value, mindlessly add it to their belief system, and move on. There is little thought given to the conditions that might make it true (or false) and whether the statement agrees with or contradicts personal experience, observations, and beliefs. A more thoughtful person, however, would take a different approach and examine the statement in light of his mental models to determine if the statement holds up or if his mental models are outdated and need to be changed.

A mental model – or paradigm – is a framework or worldview that helps you understand life, make decisions, solve problems, interpret the world, and understand the relationship among things. Mental models are deeply held beliefs about how the world works and they guide your perception and behavior.

Most lean and agile coaches (and other consultants) unsurprisingly operate from the “change is hard” mindset — the metaphor they use is that change is a long arduous journey. The start of the journey is the client’s current state and the destination is the eventual end (desired) state. Sometimes, the journey is envisioned as one without an end — a distant ideal state or north star. Of course, the journey isn’t expected to be easy; it’s supposed to be hard and that’s why consulting help is highly recommended — a “good consultant” can show the way by producing plans and schedules and highlighting future expected impediments and countermeasures. This leads one to believe that transformative change is a linear, staged, and controllable process.

People with a different set of mental models, however, can view change differently:

• Continuously unveiled: Instead of change being controllable, it can be viewed as being continuously unveiled wherein every intervention and interaction gives rise to new circumstances that have to then be addressed or skirted, ad infinitum. These new circumstances and their order cannot be preconceived; change is, therefore, a series of ongoing adjustments to what is being observed. Non-trivial change is, therefore, contextual, non-linear, and impossible to be staged.
• Instantaneous: Instead of change being long and hard, it can be instantaneous like adding milk to hot tea. Just like the drops of milk diffuse through the hot tea, the right change interventions can smoothly, continuously, and effortlessly ripple throughout the organization. The operating belief is that a small amount of change in an important habit can cause a disproportionately large transformative effect. Charles Duhigg, the author of “The Power of Habit,” calls these “keystone habits.” This change is permanent — you can’t easily separate the milk and tea once mixed.
• Easy: Change can be easy. Effort doesn’t have to be a matter of gritting one’s teeth and willfully forcing oneself to act. Effort arises naturally once you establish the conditions that generate it.

The “long and hard journey” metaphor often leads to the belief that people are “change averse” — they neither like change nor the effort required to make that change. But there is enough anecdotal evidence that people make drastic changes willingly — we all leave the comfort of our parent’s house, go out into an uncertain world, change jobs, get married, have kids, etc. We are not averse to change; however, we are suspicious of change efforts that do not make sense from our point of view. Calling someone names, like a “resister” is so much easier than getting out of our own comfortable echo chamber and dealing with the vexing and even annoying challenges raised by the person who disagrees with your narrative. “Resistance” isn’t due to a lack of desire to change, but due to lack of information, skills, or insight and due to a fundamental disagreement with the change approach or desirability of the result. Change agents need to focus on people’s concerns, interests, desires, and bandwidth for change instead of lazily lumping people in a “change resistant” bucket.

Having a point of view is good, but believing that your mental models are the only true ones can blind you, make you inflexible in your thinking and approach to work, and preclude available options. The more we rely on outdated mental models even while the world around us is changing, the more our mental “entropy” increases. Mental models are imperfect and only provide partial explanations; however, good ones have the most utility and help you make wiser choices and take better actions.

Developing a broad base of mental models is critical for anyone interested in thinking clearly, rationally, and effectively. This is summed up nicely in the following quote from Timber Hawkeye,

“Our opinions and beliefs tend to change depending on time, place, and circumstance. And since we all experience life differently, there are multiple theories on what’s best, what’s moral, what’s right, and what’s wrong. Therefore, no matter how certain we are of our version of the truth, we must humbly accept the possibility that someone who believes the exact opposite could also be right (according to their time, place, and circumstance). Accept that other people’s perspectives on reality are as valid as your own (even if they go against everything you believe in), and honor the fact that someone else’s truth is as real to them as yours is to you.”

 

 

Can we get out off the Agile weeds?

I’ve been having far too many conversations regarding Agile frameworks, their implementation, and scaling recently. It seems to me that a majority of agile coaches and their clients seem preoccupied with rituals over results and I get the sense that people are too mired in the weeds and losing sight of the few basic things needed for becoming a more nimble and customer centric organization. So, here are some things to ask yourself:

• Are we truly a customer centric organization? Do we actually get out of the building enough to understand our customers, their needs, their problems, and how they use (and struggle with) our products. Can team members do a “follow-me-home” or some other customer discovery practice – journey maps, customer interviews? Are product teams primarily focused on gaining customer insight in order to better meet their needs? Do we even care about customer delight?
• Are we open to disrupting ourselves without the motivation of a crisis? Does our culture allow us to preempt crises, without much drama, by reinventing products and services offered or by changing the existing business model? Or are we complacent and reactive and buffeted by what are competitors are doing?
• Do we have true business and IT partnership? No, I don’t just mean that a PO sits with the team or that there is a Product Manager who ensures that her POs are aligned on the order in which to build the identified features. What I mean is that the business folks and IT have the same goals, the same targets, the same key metrics – and that they together focus on the same desired outcomes (and not just the outputs). Think X-Matrix and OKRs here. Think collaboration (in the true sense of that word) and not just communication, cooperation, or coordination. Think the CIO meeting daily with the Chief Marketing Officer (CMO) to strategize.
• As a company, are we good at making accurate decisions quickly? Can we get the right information to the right people making the right decisions at the right time? Can we provide the decision makers with relevant and timely feedback about their decisions? And then, do we encourage them to learn from mistakes and improve?
• Do the IT folks sit together with people from Product, Marketing, UX, Finance, and Operations so that we have true cross-functional product teams? Do these product teams (small, collocated, long-standing, cross-functional) have the autonomy to determine their own best solution to meet the defined goals? Do they have license to experiment and learn? Do senior leaders trust them to do the right thing?
• Are we providing open collaborative spaces for the collocated product team members? Or are we still struggling with ineffective communication amongst the distributed and/or dispersed team members?
• Are teams keeping design simple and writing good code? Can they rapidly get feedback by integrating and deploying continuously? Can they release on demand? Do they demonstrate their working product frequently to their stakeholders and to their customers? Yes, inviting real customers to a demo is a good idea.

You’ll notice that these are independent of any agile framework used. You can actually start improving on all of these without even using the term agile. So what’s keeping you from moving off the rituals bandwagon and focusing on what truly matters?

 

Executive Conversations At the Start of a Transformation Effort Are Key

To have a decent chance of leading a successful change effort it is imperative to have the right conversations, at the start, with the executives and stakeholders who will be instrumental in the success of the transformation effort. While starting at the team level and focusing on the process introduction is far easier, it is also the riskiest strategy long-term.

So what might you want to do during the initial session:

• Ensure that the executives and sponsors are clear on why they are embarking on their Agile journey. Remember that Agile practices and methods are just a means to an end and not the end itself. Additionally, most transformations fail because people treat them as transitions instead — you want to make sure the leaders understand the difference between the two.
• The leaders also need to be clear on what outcomes (quantified where possible) they want to achieve.
• Change efforts succeed when leaders actively lead the change and remove barriers to higher performance. You may want to talk about the three key components of organizational agility — (1) leadership agility (how leaders lead, inspire, direct, and motivate others), (2) organizational structures (structures, rules and policies that facilitate how work gets done and how results are produced), and (3) organizational culture (collectively held beliefs, values, and assumptions that determine how people think and how they behave) — and how they themselves need to approach the leadership work differently.
• Ensure they understand the concept of looking at things holistically — discovery, development, delivery, and leadership and how each affects the other.
• Lay out at a high-level what the incremental goals might be — moving from tactical to strategic to aspirational.
• Check their level of commitment on a 1-10 scale, where anything less than 8 indicates wavering commitment.
• If committed, introduce the concept of an enablement team and ask them for recommendations on who should be on that team.

Make sure you keep engagement high — have the leaders work through exercises that get them up and collaborating.

Bottom line — in my experience, two to three hours spent with the executives and sponsors early on will prevent hundreds of hours of pain and suffering later on. What have your experiences been?

 

Decentralize to be more nimble

Flattening the organization (i.e., reducing layers of middle management) by itself is not the answer to becoming more nimble. Flat organizations are still steered by the remaining managers and not driven by market pull.

Delegation is a small step in the right direction; however, decisions are still made by lower level managers and not by self-organizing teams nor those closest to customers.

Decentralized organizations, however, encourage decision making at the boundary where customer or market interaction occurs. Learning is fast, decision making swift, and pivoting easy. TJ Maxx is an example – purchasers can make on-the-spot decisions without prior approval or permission from head office. Contrast this with purchasers from other retailers who are bogged down with long-term contracts and have little leeway in who from and what they can purchase. Not surprisingly, TJX is one of the two retailers in the US growing despite a tough environment.

 

 

The Toyota Way to Lean Leadership

In partnership with George Trachilis from the Lean Leadership Institute (LLI), I’m making available material from LLI’s “The Toyota Way to Lean Leadership” course. Check back every week for a new chapter from the course.

Week 17: A3 Examples: Standards, Standard Work, and Visual Management
Week 16: More A3 Stories
Week 15: A3 Stories
Week 14: A3 Thinking
Week 13: Why PDCA?
Week 12: Problem Solving to Develop People
Week 11: Root Cause Using 5 Whys
Week 10: Toyota Business Practices – An Example
Week 9: Toyota Business Practices Explained
Week 8: Problem Solving Towards Ideal Part I and Problem Solving Towards Ideal Part II
Week 7: What is Lean? Problem Solving, Improvement, and A3 Thinking
Week 6: Developing People
Week 5: Lean Thinking—Philosophy for the Long-term
Week 4: True North Values
Week 3: Toyota Production System Origins
Week 2: Problem Solving: The Toyota Way
Week 1: Great Company Characteristics