What is "Value"

In the book, The Professional Product Owner (which by the way I recommend each Product Owner and Scrum Master to read) the authors Don McGreal and Ralph Jocham, under the heading "Value Defined" (pg56) discriminate "Value" into three different categories:

Types of Value

The italic quotes in this section are verbatim quotes, and I will comment on them below:

Personal Value = Personal happiness

 As people, anything we consider to be of value ultimately comes down to one elusive element: Happiness. Is money valuable? Only if it makes you happy. More time with your family? Only if it makes you happy ... Time, money, good job, these are only circumstantial evidence of value. We assume having more of them will make us happy.

Business Value = Money

 As companies, anything they consider to be of value ultimately comes down to one elusive element: money. Are happy customers valuable? Only if they pay for your product. Is a good culture valuable? Only if it reduces the cost of attracting and retaining employees. Happy customers, good culture, steamlined processes; these are only circumstantial evidence of value. We assume having more of them will make (and save) us more money.

Nonprofit Value = Improving Society

 An obvious exception is nonprofit organizations (...) where value is about improving society. For nonprofits, money is circumstantial. In fact, revenue while not positively impacting society would be considered negative value.

A myopic definition of Value

The short form would be: "People see value in happiness, businesses in money and nonprofits in improving society."
Personally, I disagree. All three of these statements are myopic. And here are my cases for ponderance:

Basic human needs

Why do people see a doctor? Is it to get well, or is it to be happy?
While there are indeed certain pills that "make people happy", most people would agree that health is a value in and of itself, regardless of whether it's connected to happiness.

The entire Maslow "Hierarchy of Needs" doesn't even contain the term "happiness", and there's a reason. When people's basic needs, such as food, shelter and safety are unmet, happiness is irrelevant. Likewise, it's entirely possible to have psychological needs met without seeing fulfilment - which meets the need, but doesn't result in happiness.

Therefore, people are looking for other things than happiness as well.

Emotional Compass

And finally, to put the nail into the coffin on the happiness argument:
Happiness is but one of many human emotions. When we study the Plutchik Wheel, we discover that there are eight base emotions, with different nuances on each, accompanied by different attitudes, and they can even combine to form yet other emotions. The mix of all of these is what makes us human, a biased pursuit to ultimately have only happiness makes us shallow.

And without going further into details, both Christian and Buddhist teachings contradict the idea that the pursuit of happiness leads to a fulfilled life.

Therefore, happiness is one, but definitely not the only, thing people strive for.

Online Games

Why are "free games" such powerful cash cows? Is it because everyone eventually pays? No!
One of the core tenets of Free-to-Play Games is that you need a massive player base in order to attract some so-called "Whales", that is, people with a high willingness to spend a high amount of money on games. Some games go as far as calculating that they need about ten free players to attract and retain just one paying customer, and maybe one in a hundred of those paying customers is a whale - so basically, your entire business model is built on the idea that 99% of your player base play at or below cost in order to rake in the cash from a few hundred!

Therefore, attracting and maintaining unpaying customers may be crucial to your business model!

Cross Service Subsidization

About a decade ago, Deutsche Bank chose to make their unprofitable private customer banking segment so unattractive that millions of customers simply left.

Too late did they realize that many individuals (myself included) are entrepreneurs who also have a company. And when your bank basically gives you, as a private person, the extended middle finger, you'll consider twice where you, as a businessperson, take your transactions.

The money of this segment wasn't what made this customer group valuable - their entire value was in enabling other business segments!

Therefore, eliminating unprofitable customer segments may be economic suicide!

Interests aren't Improvments

It's not necessary for a Non-Profit Organization to actually want to "improve society". Although a large number of NPO's are formed around a societal goal which they themselves consider an improvement based on their perspective, this isn't the only reason to have an NPO. Indeed, an NPO only means "Not for Profit", which only excludes profit as a motive. And this should also hint that there are indeed other motives which an organization could hold.
Also, according to Wikipedia's definition of an NPO, it's entirely possible for an NPO to further exclusively the self-interests of the organization.

Therefore, "improving society" is neither excluded from being valuable for a for-profit organization, nor is it necessarily valuable for a non-profit organization!

Other types of Value

Is money, or bottom line, the best measure for company value? I consider this view myopic.

"We're in business to earn money, and we build products to earn money, hence the best product is the one that earns most money." That's common thinking, but it's not that easy and probably the reason why so many companies get in trouble on a strategic level.

Personal Values

People value a whole range of things, and happiness is just one of them. There are a wide range of things people can value that neither directly nor indirectly translate to happiness. Instead, the validity of these values depends on a person's core belief system, which is not the same for every person.

Here are just a small number of things which people might value that have at best extremely fuzzy links to happiness:

• Health
• Life
• Compassion
• Kindness
• Integrity
• Respect
• Religion
• Patriotism
• Environmentalism

I would like to argue, based on the standpoint of the authors, which shows the absurdity of the concept of taking individual happiness as ultimate measure: 

• Is another person's life valuable, even if it doesn't make you happy?
• Is respect towards other people valuable, even when they don't make you happy?
• Should we do something about climate change, even if it means that you may have to stop doing something that currently makes you happy?

With the argument that "only what makes you happy has value", we create a corrupt, unsustainable society!

Although each person has their own set of core beliefs, I think I made the point that adopting the core belief of "do whatever makes you happy and ignore everything that doesn't" could lead to an entirely broken moral compass.

Strategic Values

When I was an inexperienced agile coach, I used to abide in the narrow definition of value that everything can ultimately be translated into fiscal value. I was quickly taught something else. Managers in organizations see a huge variety of "strategic values" that are extremely difficult to express in terms of money, just to list a few of them:

• Brand
• Reach
• Dominance
• Exclusivity
• Publicity
• Influence
• Reputation
• Visibility
• Networks
• Recommendations
• Partnerships
• Alliances
• Capability
• Scalability
• Descalability
• Flexibility

While some of those things could indeed translate to money in the long term, it's about impossible to relate a single backlog item's contribution to any of the above to a meaningful fiscal quantity.

Conclusion

Ultimately, if we stick to an overly narrow, dogmatic definition of "Value", we lose opportunities and might be acting against the best interests of ourselves, our organization, our society and eventually of humanity.

Instead, we might want to reflect on this one simple point and explore: "What do we consider valuable - and why?"
The answer will be different for different people, different teams and different organizations, and change over time.

Coaching tool: The ORG team building model

How do you build high performing teams? In this article, I will describe the three-factor model which can help focus your attention.

The model is extremely simple to memorize, although it requires a lot of thought and attention to practice.

The model

Outcomes, Relationships and Growth are highly interrelated: Poor relationships lead to poor outcomes, whereas good outcomes bond the team, and growth is usually required to get the next great otucome.
It's impossible to separate the three, although managers often focus solely on process and outcome - a huge mistake!

Outcomes

Future outcomes are goals or side effects, and past outcomes would classify as achievements or failures.
With a new team, we have a couple goals. By turning them into results, we create a basis for inspection and adaption.

We can look at outcomes in many ways, just to name a few examples:

1. Performance: Value, Customer Satisfaction, Quality, ROI
2. Process: Behaviours, Practices, Tools, Flow
3. People: Mindset, Expertise, Happiness, Teamwork, Relationships (there we go, recursion!)

One important side note on process outcomes: Dysfunctional behavior is most often an indicator of at least one dysfunctional relationship, which is why behaviour (both of the person and the system) is classified as an "outcome".

Relationships

Relationships are the basis of every group effort. Healthy relationships propel performance, whereas unhealthy relationships constantly divert attention away from outcomes. Therefore, investing into healthy relationships both within and around the team is essential to success.

We can also look at relationships in different ways, here again some examples:

1. Trust: Reliability, Confidence, Mutuality
2. Psychological Safety: Addressing and resolving conflicts, allowing vulnerability, permitting mistakes
3. Collaboration: Commitment, Teamwork, addressing weaknesses and being supportive

Creating and growing a base of trust can be done by setting common goals (ref. "Outcomes") and achieving them together. 

Growth

As a wise person once told me, "We are all where we are, who we are and what we are. Growth is a lifelong process, but not everybody grows. Wouldn't it be sad to stand in front of the grave of an 80-year-old person and the inscription read: No growth. This person hasn't grown in the last 50 years?"

Growth areas we can look into might be:

1. Organizational: Team, Company, Market
2. Personal: Skills, Understanding, Social
3. Professional: Salary, networking (see - we have relationships again!), achievements (and there's outcomes!)

Healthy growth picks up people where they are, happens at a pace people can bear with, and helps them move into a direction they want to be.

Time orientation

The model is applied differently in past, present and future orientation.

Future

Since a new team starts with a future, we'll look at the future first:

1. What will be the desirable and probable outcomes of our actions?
2. Which relationships would we want to have (within and outside the team)?
3. In which areas do we want to grow?

Even this can be separated into subsets of Near Future, Mid-Term and Distant Future.

Present

In the present, a possible set of questions would be:

1. Which outcomes are we currently working towards and what are we getting?
2. Which positive and negative aspects do our relationships have?
3. In which direction are we growing and where should we be growing?

Past

The past helps us understand why we are where we currently are:

1. Which outcomes did we get, which were desirable and which not?
2. Why are our relationships the way they are?
3. Where did we grow and where didn't we?

Analyzing the past is about finding change potential to move into a better direction from now on, so while positive aspects help us identify drivers, negative aspects help us identify areas with need of attention.

How to use the ORG model

As a process

The meta process is quite simple and contains an infinite loop:

1. OUTCOMES: Start by defining goals, i.e. "indended outcomes".
2. Bring people together to achieve those goals (the team).
3. RELATIONSHIPS: Let the people figure out how they want to achieve those goals.
4. GROWTH: Observe where issues arise and work towards beneficial change.
5. OUTCOMES: If goals change or new goals (e.g. growth or relationship goals) become necessary, set new goals.
6. Repeat at 3.

In team building

When setting up a new team, remember: You have no outcomes, growth or relationships to build on yet.

1. Define the long-term OUTCOMES for the team, i.e. "Why the team exists".
2. Set clear, achievable short-term OUTCOMES to achieve in a short period of time.
3. Bring the right people together and see which RELATIONSHIPS form.
   Strengthen desirable relationships.
4. Generate team GROWTH while achieving these OUTCOMES.

I have seen great leaders define the main goal of a first iteration with a new team primarily as people outcomes: Build relationships, get to know each other and the product vision. Performance outcomes are still important, but achieving these can wait.

Inspect and Adapt

As mentioned in the "Time Dimension", we can constantly reflect on past-present and future ORG states, refocus and make adjustments as needed. A Scrum team might want to use ORG during Planning, Reviews and Retrospectives to determine a course of action, learn where they got and adjust course.

Coaching

Your coaching effort can be distributed across the three different dimensions of ORG.
Ideally, you balance out all three dimensions, neglecting none.
In practice, this will be a pendulum swinging between all three, and the one with the least attention is the most likely to become your next problem.

As a coach, if you realize that you're neglecting one dimension, you can pro-actively plan your next steps to build a higher performing team.

Download

Printable materials for ORG workshop facilitation can be found here: Download.

Eight signs that your quality sucks

Sustainable high quality is essential for the success of your product. When I get hired as an Agile Coach, I often encounter that quality isn't at all where people think it is, and in this article, I'll expose some of the key clues that quality sucks and the product has a huge pile of technical debt attached.

To tell you how obvious problems can be, I will exclude the options of "looking at the product" and "looking at the code", because that would be too easy.

When I see these signs, I will immediately drill in and go for the root cause with just a handful of questions, because the symptoms are dead give-aways of poor quality.

If you see one of these symptoms, that might be coincidence. If you see two or more, there's something fishy. And if you see all of them and don't have quality issues, I would surely like to hear from you, because I'd really love to learn how that is possible.

So here's my list of hints that you need to work on your product quality:

Pseudo Done

When teams play ticket ping pong and spend large amounts of time "fixing" things after an allegedly "Done" feature goes into test (or: live) then I first ask about their Definition of Done. Usually, they either have none - or one they don't live by...

Sticking to Formalities

Sometimes, I see fake User Stories like, "As an API, I want to be informed about changes to the database so that I can process the new data." or lists of wishy-washy Acceptance Criteria like, "Buttons are implemented". When teams and/or organizations don't even understand the "Why" behind simple tools and practices, how can they understand what's value for the product?

Not Releasing

If you haven't released in months, you're stacking up assumptions until you get into dreamland. You assume that you understand what users want and users assume that everything is going to be great. The release will later bring you down to reality, often with sore disappointment, massive rework and a hard course correction.

Top-Down Process

When people who don't actually do the work define how, what or when work should be done, I don't need further evidence. I'll need just a handful of "Why" and "How" questions that will make it glaringly obvious to everyone that things haven't been thought through and the outcome isn't going to be what it was supposed to be.

Snooze Refinement

When the only persons talking during Refinement are the Product Owner and the Lead Developer while everyone else remains silent and near motionless or no user joins the show, it's very likely that developers don't really understand what's the best way to translate demand into reults, and the outcome will be accordingly.

Reviews

When your Reviews are a glamour show where only the sunny side of the product is presented, issues are masked or users don't get to actually touch the product until much later, you have no idea what quality level you're actually on. If you do indeed get feedback, but that has no effect on your backlog, you're closing your eyes to some very unpleasant facts.

Pointless Retrospectives

How can breakthrough improvement happen when by sticking to existing processes, tools and dogma? Many teams only do miniscule, cosmetic improvements without ever fundamentally questioning what they're doing or how they're doing it. If quality isn't increasing dramatically, it's declining in comparison to everything around - which, a few years down the line, will make a product obsolete.

Low Morale

Developers who do a great job and produce a great poduct tend to be proud of what they do. When most of what I hear boils down to complaints and frustration, I already know that the product sucks. Are developers forced to build the wrong thing, are they building it wrong, don't they understand what the right thing is? I don't know - but I know if they continue doing what they do, the product won't last long.

And then what?

What can you do if you observe any of these symptoms?
Ask yourself: "Why? Why do we have this situation, what causes it?"

The root cause isn't always the same, so a discovery journey is always in order - and then you get to decide what to do with the problem.

Don't get fooled by Fake Agile

Whichever consultancy sells this model, DO NOT let them anywhere near your IT!

So, I've come across this visual buzzword bingo in three major corporations already, and all of them believe that this is "how to do Agile". And all of them are looking for "Agile Coaches" to help them implement this garbage.

This is still the same old silo thinking that never worked.

There is so much wrong with this model that it would take an entire series of articles to explain.
Long story short: all the heavy buzzwords on this image merely relabel the same old dysfunctional Waterfall. In Bullet points:

• "Design Thinking" isn't Design Thinking,
• "Agile" isn't Agile,
• "DevOps" isn't Devops. and 
• Product Owners and Scrum Masters aren't, either.

Here is a video resource addressing this model:

• The "Agile Factory" - Not Agile, Not Lean
• The "Agile Factory" - Inherently Flow Challenged
• The "Agile Factory" - Moving towards Scrum

I have no idea which consultancy is running around and selling this "Agile Factory Model" to corporations, but here's a piece of advice:

• If someone is trying to sell you this thing to you as "Agile", do what HR always does: "Thank you very much for coming. We will call you, do not call us ..."
• If someone within your organization is proposing to implement this model, send them to a Scrum - or preferably LeSS - training!
• If someone is actually taking steps to "implement" this thing within your organization, put them on a more helpful project. Counting the holes in the ceiling, for example.

If this has just saved you a couple millions in consulting fees, you're welcome.

10 Bad reasons to choose Kanban over Scrum

"We're using Kanban instead of Scrum" - a common sentence, Especially since I do SAFe consulting, I hear this one quite frequently. Most reasons provided for this are anywhere between highly and extremely doubtful, and in many cases reveal ignorance both of Kanban and Scrum alike.

So here are my top 10 bad reasons for using Kanban instead of Scrum:

#1 - Our Consultant told us so

There's so much wrong with this sentence that it can't be fit into a single sentence.
First and foremost, if your consultant - after some short observations - knows your process better than you do, then you should seriously question what you're doing.
Also, a team should strive to be autonomous in decision making, and if your best reason for a decision is because someone else told you so, then you have absolutely no valid reason: you haven't understood what is best for your own good!

#2 - We had to choose

"Scrum or Kanban" is a false dichotomy. It's like saying, "Do you want a beverage or lunch?" - why not combine?
You can easily and very well combine Scrum with Kanban, as they address different problem domains. Whereas Scrum's primary concern is the nature of teamwork, Kanban focuses mainly on the flow of work. Especially Scrum.org has been investing significant effort in recent years to put together a "Professional Scrum with Kanban" curriculum which makes exactly this point.

#3 - 1 month is too short

A common argument I hear is that "we can't get anything Done in 4 weeks." 

Sorry to say, if you're not getting anything Done in 4 weeks, chances are you're not doing Kanban either. Kanban is flow optimization, and if you sit back content with a cycle time of more than 30 days when other development professionals can easily do 1 week (or less), you're just being lazy. 

While some organizations are indeed so impedited that everything is moving slowly, working relentlessly to make the problems visible and finding creative solutions to make progress is essential to succeed in the long term.

#4 - Our work is too complex

"We do really complex stuff here, much more complex than anyone else!" - Every team which has ever mentioned this argument to me was applying a "special pleading" fallacy, usually oblivious of what other problem domains look like. 

I will admit that Logistics is complex. As is social media, telco, fintech and science. Scrum is specifically made for complex problem solving, so that's simply not a valid reason.

#5 - Our stories are too big

This argument translates to: "We set up a board and put a sticky on that won't be moving for a month and call this Kanban," Well, I hate to break the news: it isn't. Kanban is about managing the flow of work, and a Kanban board where nothing is moving hides transparency and makes optimization impossible.

I remember working with a corporation where team members adamantly insisted that stories estimated to take 4-6 months were already atomic and impossible to split any further. We took a few items from their backlog into a workshop and a 6-month user story was decomposed into almost 70 workable, individual slices of value. The biggest could be delivered in a few days, some within hours. Unsurprisingly, the entire package of all relevant items estimated to less than one month!

#6 - Requirements from all sides

If this is your reason for not using Scrum, you're defaulting! One of the main reasons for having a Product Owner in Scrum is to solve the problem that everyone thinks their specific problem is Priority 1. Where a requirement comes from doesn't matter - there's always one thing that is the best thing to do right now. Even in Kanban, an understanding of what is the most important thing is extremely helpful in order to "stop starting, start finishing". 

#7 - Maintenance is unplannable

Teams which operate on a live system oftentimes get exposed to unplanned work - bug fixes, support tickets, maintenance and whatever. My first question here is: "Why is maintenance so high?" Could taking time off the busywork treadmill help fix systemic issues reduce the amount of maintenance? I have seen such teams who purposely shifted towards Scrum and taking just a fraction of their capacity to address fundamental issues - they benefitted greatly!

#8 - Requirements change too fast

To me, this begs the question: "Are you getting things finished before the requirements change?"

Usually teams answer, "No", and then I seriously question why you're doing what you're doing. Scrum might help you sort out what's worth taking into account, trashing all whimsical ideas that are forgotten faster than they were proposed.
Just as an added side note, Scrum's sprint plan isn't immutable: There is nothing in Scrum which prevents you from integrating new information and opportunities as they arise.

#9 - Too many meetings

Scrum's events all serve a purpose of inspecting and adapting - not losing focus or track in a changing environment. There is no reason for Scrum events to fill their entire timebox and there's no need to do them in a specific way.
As long as you know why you're doing what, get frequent user feedback, improve your process and outcomes and keep the team synchronized, you're quite compatible with Scrum. If you are missing out on any of these items, your problem isn't the amount of meetings!

#10 - We don't do User Stories

I have no idea where the idea originates that Scrum teams must use User Stories, estimate in Story Points, create Burndown charts or whatnotever. When your reason against Scrum is a practice such as these, the short answer is that Scrum is neutral to practice. Scrum is merely mentioning "backlog items". These can be stories, requirements, bugs, defects, ideas or whatever else floats your boat.
Some teams find value in the User Story approach, others don't. Some estimate in Story Points, others in ideal days, yet others in amount of backlog items. All of these are valid from a Scrum perspective, although some may be more helpful than others.

Wrapping up

The discussion "Scrum or Kanban (or both)" is quite valuable for teams to determine how they want to organize themselves. Unfortunately, the discussion is often not factual and highly biased. It is often led with huge understanding deficits both regarding Kanban and Scrum.

There are a lot more bad reasons for preferring Kanban over Scrum than mentioned in this article, and there are also some good reasons for doing so. When your team mentions any of the items in this post, it's good to be suspicious and ask probing questions. Most likely you will uncover that Scrum is just a pretext and there is something else going on.

Expose the root cause and deal with it, because otherwise, critical problems might linger unaddressed.

Five sentences that will kill your Agile Transformation

There are some massive faux-pas statements with which senior management, potentially without even realizing, can kill an Agile Transformation within less than five seconds.

I normally avoid the term "Agile Transformation", because I think the idea itself is a dangerous suggestion that this is a time-limited process which can be completed to create a final stage, but let's look beyond that for a moment to focus on organizations who have explicitly started an Agile Transformation initiative.

While there are a near-infinite amount of ways to mess up something as complicated as Organizational Change Management, here are five sentences that can put an entire initiative to a screeching halt:

"Fund the change from your project budget"

There's no easier way to apply Larman's Laws than to apply existing accounting structures to an Agile Transformation. What do you think will be the outcome of such a transformation program, except an organization that still has the same line / project matrix organization which created the entire mess you're currently in?
And which project manager in their right mind would spend their project budget on necessary changes that will come into fruition much after the project deadline is reached?

The proper statement would be: "We have to re-examine our entire accounting structure in the mid term, and we will create a specific change fund for this initiative."

"Limit scope to IT"

Ignoring both the impact and consequence of an artificial limitation of scope fundamentally contradicts the concept of systems thinking, which relies on acknowleding both the implicit and explicit relationships of the whole system.
I always use the clockwork metaphor: If you try to speed up a single cog, there are three likely outcomes: The surrounding cogs will absorb the change, the watch will tick wrong, or the cog will break. IT is a cog of an organization, and the results will be accordingly.
If you have this approach in mind, either abandon the idea or the change altogether. It will save you a lot of pain later on.

The proper statement would be: "Start where you are, and when you hit an organizational boundary, pull in people as necessary."

"You can do this"

What sounds like a great motivational statement betrays yet another pillar of systems thinking: Management was responsible for creating the current status quo, and unless management actively contributes in changing this status quo, it will remain unchanged.
As long as management doesn't do their part, statements like "We trust you on this" are adding insult to injury, setting teams up for failure, creating negativity and bad blood in the long term.
If you're a manager and not going all-in, you are going to be an impediment!

I'll take it with Deming:

"Support of top management is not sufficient. It is not enough that top management commit themselves for life to quality and productivity. They must know what it is that they are committed to — that is, what they must do. These obligations can not be delegated. Support is not enough: action is required." - W.E. Deming

The proper statement would be: "We can do this."

"We're already good"

I am baffled when I ask managers what they expect from their agile transformation, and they limit their answer to this sentence: "We're already good, we're just looking for ways to become more efficient."

While I'm not going to argue whether they're indeed good, the attitude behind this sentence will make it extremely difficult to realize that an agile transformation is not needed if indicators like Customer Satisfaction, Time-To-Market and Product Viability are good. If these things are not good, then "getting more efficient" is entirely the wrong direction!

"This is not important"

It's a jaw-dropping moment to sit in a room with over one hundred developers, hearing a Senior Manager introduce the new way of working to the audience with the words, "SAFe is not important". Okay. SAFe is a placeholder, it could be any other framework as well.

Well, if it isn't, why did you opt to go this route for your agile transformation? Did you bother defining your organizational goals, current deficits, map them with the different frameworks and see which approach is most suitable to meet your needs?
If you didn't do that, you simply didn't do your homework, and you shouldn't have chosen a specific framework before doing that!
And if you did that, you might as well inspire people by giving them something to aspire, rather than planting a dismissive notion in their minds!

The proper statement would be: "We chose this framework as a basis to reach our goals - and we will relentlessly Inspect, Adapt and Improve to get better every day!"

In Summary

A Whole Systems Approach is fundamental to any organizational change initiative, be it Agile or otherwise. When managers reveal that they either haven't considered the systemic impact, or simply don't care, they give everyone a good reason to doubt the success of the change from Day One.