Stories that aren't

 Let's take a look at the "User Story Template" (also known as: Connextra Template, by origin) - "As a ... I want ... so that ..." - straightforward enough. It's common in the "Agile" space, and many inexperienced Scrum Masters and coaches learn that teams should formulate their work like this.

The result?

Formally it's correct. It's a "user story" based on the template. 

Now, what's wrong with it? About everything.

Let's leave aside for a minute the fact that this story is as much of an antipattern for "INVEST" as it could be, and focus instead on the use of the template:

1. The "user" isn't a "user". 

If we start calling developers "user", then next thing we know, testers, analysts, and project managers are also "users". It becomes a hollow, meaningless term.

A "user" is someone who actually uses the end product. 

Like ... a Candy Crush user is, for example: the "mother of a small kid who only has 5 minutes before the kids will cry again."

(Of course, developers can be users as well. But that would require them to actually use the product, in which case they wouldn't be a developer, but ... for example, a "mother-of two who sits in front of computer screens all day ..." - if that's your demographic!)

2. The want is a means, not an end

"Wants" should be something that this specific user wants to have and would be willing to use our product for, like "simple and easy fun". No user ever wants a Customer_ref_ID. Maybe they need it to identify themselves, but ... can you name anyone who wants to use a product because it has a Customer_ref_ID? 

Could you imagine running a marketing campaign with the slogan, "We have a Customer_ref_ID" - if not, then you're probably not addressing anything someone wants. 

Take it as a lithmus test for formulating "wants":

If you would feel weird to see it on a billboard on the way to work - it's probably not a proper "want".

 

3. The reason is self-serving and circular.

In more abstract terms, the reason is "so that I have it." - it doesn't explain which problems it solves.  It adds no information. It doesn't help us verify whether we're adding value to the product, and it doesn't help us verify whether we actually need it. It's a fake reason.

Let's, for argument's sake, assume that both the user and the want were valid: we still don't know why you want to refer to the customer by ID, and how that is better than what you're currently doing.

A good reason statement shouldn't repeat the "want", but explain why the "want" is relevant, which problem we're solving, how the world is better after the need is met.

Good reasons invite developers to understand why the user has an unmet need.

The Investment into Quality

If you're setting out to "become Agile", or "more Agile", I would like to say something in words as simple as I can:

Unless you're willing to invest heavily into quality, forget about "Agile".

Now, what I mean with "invest in quality" is not "throwing huge amounts of money into testing", because the investment you will make is actually free, and it doesn't involve hiring additional staff, either: If you're doing it right, you will spend a lot less money to get better results. What you need to invest is attitude, thinking, brainpower, capacity:

Now, let me elaborate:

The commitment to quality

I think that no sane person would say that "we like to produce garbage products." I have never met a  developer who would state on their CV, "I was producing crappy software." Likewise, I have never met a manager who would introduce their line of service as, "We deliver crappy software."

If nobody would say that - then why is it even something to talk about?

Most commitments to quality are just lip service.
You must act upon your commitment.

When I say, "commitment to quality", I mean that everyone, and that is, everyone, must continuously ask, "How do my decisions and actions contribute towards quality, both in a positive and a negative sense?" Any decision that leads to poor outcomes should be reverted, and any action that leads to poor outcomes should be stopped.

Nobody needs to justify themselves for not doing the wrong thing, or not doing something in the wrong way. It should go without saying that "if you see that it's going to end badly, don't do it."

Managers must commit to creating an environment where team members have the freedom to do the right thing. Reciprocally, developers must commit to resolving any problems within their own sphere of control and naming any organizational barrier towards high quality, even if that barrier has been set up by the CEO in person. This must be unpartisan, free from personal preferences or fear (and these three things are already massive barriers to overcome!)

Everyone, and that means absolutely everyone involved, from managers over developers all the way to side stakeholders, must commit to do their best to enable high quality.

Quality thinking

You must turn a commitment into action, and for that, you must understand how to achieve quality. Quality isn't a local thing happening somewhere between a finished product and its users. Quality begins as early as in the ideation, and it never ends as long as the product exists. Quality is everything. It concerns everyone of us, and each of our actions.

Let's start simple, with the choice to add a certain feature to our product: Will it make the product better, or worse? For whom? How? In what way? How does the very decision of adding it affect both the process and the outcome?

The new feature could be a boon for some, and a put-off for others. It could make the product inconsistent with its purpose. It could make it clunky. It could put stress on development. It could have effects that are difficult to discover until it's too late. Could ... now I don't want you to over-think. At least, I want you to ask the questions that need to be asked, instead of simply shoving another piece of work into the pipeline: Oftentimes, the product could be better by removing a feature instead of adding another!

So, who has to think about the quality?

Designers, in design. Developers, as they develop. Testers, as they test (of course). Operators, as they operate. And that's the simple part: "I must be mindful of quality in my work."

Developers have to collaborate with designers. Testers have to do that, too. And Ops. Logically, testers also need to collaborate with developers and Ops. And everyone with the customer. And with management: "We must be mindful of quality in our interactions."

All the time, everyone of us must constantly ask:

"What can I do, both in my own work, and to the work of others, to achieve higher quality outcomes?"

Quality practice

Move beyond words. Learn how to create quality: Design thinking. Behaviour-driven development. Test-Driven design. Clean Code. Stop the line. Data-driven decisions. Measure everything. Quality and Process management. Go-See. Standardization. Simplification. Candid feedback. 

Just to name a few.

If you want to be agile, quality isn't just for testers: It concerns everyone, even the most junior developer and the most senior manager. Even those outside IT. While, obviously, I'm not going to ask a VP of Sales to write Clean Code, I would daresay that if anyone within the organization makes a choice that results in someone else breaking with an essential quality practice, this is going to hurt the company's bottom line. Hence, everyone must have a sufficient grasp on quality practices to maximize the overall outcomes of the company.

Everyone must understand enough about quality practices to do what it takes to get best results.

Capacity for Quality

I'm not going to sugar-coat this: If you don't have processes, infrastructure and code that are designed for quality, you're not going anywhere unless you put some effort into that.

You must allocate a certain amount of capacity for improving and preserving quality.

If your company has been spending $100k on shoddy stuff and could live with it, what's so wrong with spending the same $100k on something of higher quality? Nothing! Never accept shoddy outcomes: "Do more" has lower priority than "do well." Capacity invested into low quality is lost. Capacity invested into high quality is gained.

"But," - I hear you murmur - "We will be slower, and the business / customer can't wait!" - not really. 

Stop thinking about what you deliver in a day or two. Set yourself a horizon of a month, half a year and then a year. Ponder how much effort you invest during that time into fixing bugs, into rework, into unused stuff and into rote work.

Set yourself a target to generate the same business results, without doing any of that wasted work. Then, ask yourself what you would need to get rid of this pointless work. If you manage to cut down on 10% of your current workload, you have gained 10% capacity for improvement. This capacity is now not "free for more poor quality work": It's free for improvement, so that you can do higher quality work that makes people more happy. 

True Story.

Is all of the above a figment of imagination, wishful thinking, idealism?

No. I'm talking about measurable, tangible business outcomes. 

Helping my clients engineer quality, we have significantly reduced defects, non-value adding activity and rework to cut down new feature development lead times by over 50% and expenses by as much as 30%, while reducing cost of failures on business end by seven-digit figures.

The "invest" we needed was about 50% of people's time initially - to change on their thinking, their practice and their environment, and 30% of their time subsequently.

If it was your money: Would you be willing to let people spend more of their time on quality, if the outcome was that you have to spend less money to get more things faster, while earning more money from happier customers, working with happier staff?

Yes, this question is purely rhethorical: "Time spent" is irrelevant if the outcome is "better business"!

Do it.

The case for trainings

 When coaching, especially in large organizations, I very often encounter teams and individuals who have basically been "pushed" into Scrum, SAFe, Kanban or LeSS without ever having attended a training course. While on the one hand, I advocate that "the real deal is what happens in the workplace", I want to make a case why training is absolutely mandatory for new agile organizations and even for those who are just going through a major change. In doing so, I would like to debunk the common "arguments" given by organizations against professional training.

Why not just learn on the job?

It's entirely feasible to successfully adopt a different way of working while doing it. That's how people who devised "Agile" also did it. But it's extremely slow and error-prone. And we re-invent the Wheel. And we may not spot our obvious problems until we hit a brick wall.

A classroom setting allows the trainer to create an environment specifically focused on a certain learning objective, and drive home the point. Encountering a similar scenario "on the job" without any a priori experience will make things appear more complex, which means that it will take significantly more brain power to comprehend.

Of course, an experienced coach will guide their coachees through this situation and the learning process as well, and they will do it in a practical working environment, connected to the real workplace environment. The time factor could easily be twenty-fold, though, because a lot more guidance, explanation and time for reflection is required when the basis just isn't there yet.

What happens in agile training

After this brief introduction, I would like to explore quickly what you get out of a good agile training:

Conveying knowledge

Teaching the roles, artifacts and events of (Large-Scale) Scrum or SAFe doesn't take long.

The formal rules of these frameworks are extremely easy, and it can be done in a few hours. Hence, the issue isn't in standing in front of a class and rattling down the material - the issue is in getting people to find an answer to their own question of, "what should I do?"

Aligning on Roles

It's important that people understand their own role is and that of the people they work with. For untrained people, that's one of the major sources of conflict, because there are unspoken assumptions and conflicts until we had an open conversation. A classroom environment allows people to bring three things together smoothly:

• Objective standards
• Their own personal understanding of their own role
• Others' understanding of their own role, especially interactions

Understanding events

There are numerous events in each framework. As a coach, most of the dysfunctions in practice I observe are related to people not having a proper understanding of the intent beind these events. A training environment allows the trainer to let people consider for all of these events:

• Scope
• Participants
• Agenda
• Intended outcome

With people who already practice a framework, trainers will often let participants explain how they conduct these events, then provide corrections and advice in order to help people get more value out of what they've been doing so far.

Constructing artifacts

Regardless of whether you're using an agile approach already or are transitioning from classic project organization to dealing with agile artifacts, the journey is extremely difficult for people who have no understanding on the purpose and contribution of these artifacts. A classroom setting will give people time to learn or reflect upon:

• Intent of each artifact
• Setting up the artifact
• Maximizing effectiveness
• Minimizing handling efforts
• Dealing with typical challenges

People are often amazed when they compare how they're currently working with the ease and seeming effortlessness with which a trainer uses artifacts in a classroom setting to achieve their purpose.

Experience Anchoring

As already mentioned above, the "knowledge" part is the simple part of an agile training. A proper agile training will spend a major portion of its time on creating an "anchor" - letting people try out the approach in a safe environment, so they can draw their own conclusions in comparing this with their own workplace environment.

Living the framework

Small simulations will allow people to try out their framework, and gain some experience with both the ups and downs of the new ways of working. Depending on what participants want to get out of it, they may either use the simulated environment to explore their own role and receive instant feedback, or they can try out a different role and build some empathy.

Communicating and learning

In a training environment, it's expected that people use each exercise and share with the group what they learned, what they would like others to be aware of, and what they would like to keep for the future. This is an extremely good habit for adaptive ways of working, which oftentimes doesn't happen on the job, because people feel it's out of place or don't have time.

Subtle learning

When people don't understand an instruction in a training environment, they will typically just ask the trainer. In the working world, they would often lack the courage to speak up and just try to get through somehow, the problem will only become obvious in retrospect. A training allows people naturally adopt the benefits of the Scrum Values, such as Openness and Courage, and a good trainer will drive home the point that they're already doing it!

Team Formation

Probably the most underestimated aspect of an agile training, and also the reason why I advocate bringing in a trainer rather than sending out people to role-specifics training, is team formation. There's a huge difference in performance between a group of individuals working on the same project (product) and a team (or: team of teams).

Over the course of the training, a trainer can form groups of trainees as teams who will have had ample time to discover and work out the important aspects of their future collaboration: who can expect what from whom, how they will organize themselves - and what is important when. After such a training, people will be pumped and ready to rumble without delay.

Just the benefit of having had people spend a few days to sort out all of their misunderstandings and find a common way forward can pay for a good training with ease: The formal knowledge gained is just the icing on the cake.

Flawed arguments against training

I would like to dissect the most common arguments given against bringing in a trainer and having people attend a formal training, because I believe that there are very, very few solid reasons against kicking off a new agile unit with a good training:

Common reasons

I hear all of these arguments commonly, and none of them hold water when you think about it a little closer:

The cost argument

"People know the price of everything and the value of nothing." - Oscar Wilde

The training costs too much

You will pay for the training one way or another: If you would "save" on the training, you'd have to do it with coaching, parallel to work, and therefore, over a prolonged period of time. The time lost due to friction until people are settled as a team and have found their way to collaborate and contribute will typically exceed a month ... and now think: how much will you spend on coaching during that period?

Effectively, you've got to do the same thing, with the only difference being whether you do it in a classroom or in parallel. The cost will be the same.

We don't have budget

A common problem, specifically in large corporations' IT department. It comes from a cost accounting structure. You may have budget to "do work" (CapEx), but not budget to "set up doing the work more efficiently" (OpEx). It's a dilemma. The solution rests in TCO - total cost of ownership. 

Going the right direction after a training will be faster and cheaper than figuring things out first. Even if you save just 1 Sprint on whatever you intended to do by setting up a training - the gains are X salaries for 1 Sprint, which should be part of your overall budget. 

Start thinking in terms of throughput accounting: if you spend $100k to build something, or you spend $80k to build something, the second option is cheaper. Except that "under the hood", option 2 used training, whereas option 1 burnt the budget on "doing": Does it even matter?

You have the money. You just don't see how you should be allocating it.

People are too busy

Of course they are. Because of your current ways of working. Which is what you want to improve.

If things don't work, why would you want to keep continuing doing the wrong thing, rather than making a full stop, resetting - and starting off with full speed in the right direction?

Other Priorities

This tells me that your organization has a priority issue: If "other things" are more important than coming together to introduce a more effective way of working - then your organization doesn't understand or appreciate effectiveness. We can use the training to set the baseline for fixing this issue, but we won't fix it by continuing to do what we always did!

We can't withdraw X people for 2 full days!

Imagine someone gave you an axe that allowed you to cut trees twice as fast, but it would take Monday and Tuesday to get used to. At the end of the week, you'd already have cut more trees. It's the same with your team(s). The only reason why you can't train them: because you feel the short-term cost is bigger than the long-term benefit. I call this "The tyranny of the Urgent." If you don't break free from that now - why would get better when your team has invested even more time working suboptimally?

As the proverb goes, "The best time to plant a tree is 20 years ago. The second best time is today."

We don't need it!

What do you say to a salesperson when you don't want to take the offer? "No." It's entirely acceptable. At the same time, would you say "no" to yourself when someone was literally offering you free money with no strings attached? 

To not spend money for something that costs you less than it earns you - is economic nonsense.

We'll figure it out by ourselves

That's entirely legitimate. I had the same attitude. And I did. It took me years. If you have those years ... great! Unfortunately, I don't think your comeptitors will wait for you to learn stuff that's well known while they start dominating the market.

People already know Agile

As mentioned above, a good trainer will not focus exclusively on objective knowledge. Instead, the training will form a team (of teams) of people who agree on a common, more effective way of working: If you already had this, why would you need a new way of working?

The flawed underlying assumption

Behind all arguments given against training is a single, unspoken common assumption: "We believe that training doesn't make much of a difference."

I would like to take a jab at this assumption like this: "If you believe your current ways of working are already (almost) as effective as what the trainer would teach you, why do you even want to adopt new ways of working?"

If you believe, however, that the new ways of working will make a significant difference, then I would suggest to figure out the value proposition of a training. Drop the fallacious arguments, talk purely about your needs and expectations.

If you need help building a business case for investing into training, we can do that:

The value of training

Before you think about "training or no training", ponder these questions:

• What's the biggest challenge we have, that we want to solve within our current way of working?
• How would the new way of working deal with this challenge?
• How much does this challenge currently cost us - ever day, every month, per year?
• How much would setting the groundwork with a brief training course help us shave off the current challenge?

The answer to these should help you formulate the business case for a training, and help the trainer manage expectations as well. If like this, you end up with a negative business case for the training, then I would - most likely - not suggest adopting a new way of working at all. The friction of switching ways of working would probably outweigh the expected benefits.

Once we've learned that training is a positive case, look for the following aspects in agile training:

• Will the training address the challenge(s) we want to improve upon?
• Will the trainer be able to relate our situation with the training content?
• Will trainees get specific impulses for things they could start doing differently tomorrow?
• Will the training equip people to apply their learnings outside the classroom?
• Will the training connect people on the work they will be doing? 

If the answer to any of them is "no", either talk again to the trainer or find a different trainer.

Once you are convinced that the answer to all questions is, "yes", then it should be a no-brainer to do whatever it takes to free everyone for a few days to get some proper training. 

Training vs. coaching

What I say in this paragraph is bad business for me - because I'm a coach: I have sufficient experience to claim that the needed duration for coaching - and thus the coaching expenses - will be significantly lower after people had training.

The reason why I say it regardless of the financial impact: the probability of change success goes up dramatically. This, in turn, means that the likelihood that you will discover the value in coaching will go up. And thus, the probability that you will speak favorably of my coaching will also go up.

An expericenced coach would be fully capable of compensating the absence of classroom training and formal education in the coaching work. From an expectation management perspective, I would still advocate for starting with training before coaching, because it's not an either-or situation.

Good training enables better coaching. "No training" means extra money for the coach, and more trouble. The best case scenario is great training followed by great coaching. It produces a win-win-win scenario: you learn more, you save money, and the coach will be more effective faster.

Factors to disregard

A lot could be said on bad decisions when choosing a training. I would just want to highlight a few factors you should simply disregard when deciding on training, because I see many people look for these factors, only to later complain they didn't get their money's worth.

Certification

I have some beef with certs, because - especially for introductory classes, which we're talking about - they do not certify competence. They certify attendance, and you don't need (virtual) pieces of paper. You need people to do work. If your training helps you to do work better, that's great. Certification is a gimmick. It adds no value to a course.

Multipliers

Many organizations are trying to save money by sending a few people to a 2-day course, who are then expected to act as "internal multipliers". One of the key benefits of training is to form teams who can immediately and effectively start working in a new way, You lose this benefit by dispersing people and introduce propagation layers. Those people who will work together should receive training together. And don't limit it to "managers" or "leads" - train everyone!

Standards

A canned and bottled curriculum is a double-edged sword. You need something that people can relate to, something that's actionable in your organization. As such, the trainer must at least be able to pick up your people where they are instead of merely playing off a script. If the script is flexible enough, it's not a disadvantage. Otherwise, the standard creates a problem.

Fun!!!

Training can have fun moments, but I'm highly suspicious of trainings that people unanimously call "fun": If you want fun, send people to Disneyland. Ignore the fun factor.

When a trainer actually breaks with your current paradigms, it will throw you into mental disarray. Anger, sadness and frustration can accompany a great training that really shook your beliefs about work. In some cases, it takes weeks or months until people realize what they learned. During that time, you might see people give both thumbs down on the training, which only shifts once the learning sinks in. Don't let high fun scores attract you to a training, and don't let lower fun scores detract you from it.

Conclusion

A good training will pay for itself - even when you're too busy, even when you think you already "know Agile". And even when you have no money. If the training isn't worth it, then whatever change initiative you're running probably isn't worth it, either. Hence, training can be a great lithmus test to see whether you should proceed.

You will save time, you will gain productivity, and you will also have a better bottom line when you achieve the same (or better) results after a training.

Continuous Problem Solving

"What do you even do as a Agile Coach?" - well, that's easy: I help you on your journey towards better, more effective ways of working. And how do I do that? 

Well, I will start using this simple 4-step process:

The problem solving process

Step 1: The Biggest Problem

When I come in, you will have many problems. One, or just a few, will be the biggest. Let's forget the others for now. Why? Because it's better to get one problem solved than to have no problem solved, and by its very nature, solving the biggest problem will make the biggest difference.

How do we identify the biggest problem in the presence of a myriad of issues?

It's not quite as simple as "brainstorming and dot-voting": sometimes, we need both loads of data and the perspectives of many people who may not be in the room. And sometimes, nobody sees or addresses the elephant in the room. When facilitiation isn't enough, I may gather and/or analyze data, interview different stakeholders or simply connect some bits and pieces to form an image to get a conversation going. And if that still isn't enough, I'll propose to you a shortlist of problems that you can pick from.

Step 2: Root Cause

If you had a simple solution, you probably would already have fixed it. So there's a deeper cause to your problem, and we need to address it to make some relevant progress. At times, we must move your process to an entirely different level, because we can't solve the root cause - we must avoid it!

How do we find the root cause?

Simple tools include 5-Whys or, again, brainstorming and dot-voting. These are often insufficient, because once again, if we knew the cause, we would probably already have addressed it.

I'm not a big fan of "Five Why" analysis for organizational issues, because the technique usually suggests a point-based root cause, whereas the root cause may be hidden in a web of causes, and even then, it could be a network effect leading to the problem we observe. And sometimes, identifying the cause is easier for an outsider who isn't stuck in a presumed "inevitability". If that's the case, I will give you my opinion. (Although I could be wrong. Everyone can always be wrong.)

And sometimes, I frankly don't know. If, for example, the root cause is part of your internal accounting processes, I can at best tell you it's there, but what exactly - I'm not an expert on that. we'll need to call the experts in.

Step 3: Action Plan

How do we deal with the root cause, how do we get better? You may have ideas, and I also have ideas. You may lack the experience and/or expertise, and I may have it. Let's bring all of that to the table, and turn that into an action plan. 

I could propose an action plan, although you need to accept it. If you have counter-suggestions or alternatives that you consider better, go for it. I'm indifferent to whether you go with my proposal or your own: what matters is that you get some traction and start moving the big bricks.

What's most important about the action plan: it's your action plan. You own it, and you execute upon it. I will support you with whatever I can contribute that you need: facilitation, tracking, communication, workshops and sessions. Depending on how much support you need, I may also compile the outcome of all of this for inspection.

Again, like in step 2, there are problems where I can propose an approach based on my experience, and some where I'll have to pass. For example, if your biggest issue is a proprietary compiler for a proprietary programming language, I can only suggest you get an expert from the vendor to help you on the issue.

Step 4: Reflection

So you did something, or we did something. If it was a good plan, something should be visibly better now, otherwise - what did we miss, what should we do about it?

Is our problem still as big as before, or has it become smaller? How much? Did we create other problems?

I'll support you with methods, structure and facilitation in this process. And, like mentioned before, with compilations of results and outcomes. As needed, I will add my insights and opinions.

But ... how about "Agile"?

"How does that help us introduce Scrum, Kanban, LeSS or SAFe", you may ask? It may not. Or it may. For certain, it will make you more agile, i.e. improve your ability to "change direction at a high speed." 

Agile frameworks are entirely in the solution space, i.e. step 3. 

If Scrum helps you solve your biggest problem, and you need someone to teach you how to Scrum, that's what I'll do.

If User Story Mapping solves your biggest problem, that's what we'll do.

If Pair Programming solves your biggest problem and you don't know how to do it, I'll grab the keyboard with you.

If your biggest problem is the lack of an overarching structure and you decide to go with SAFe, I'll set up SAFe with you. Or LeSS, if you consider that the better alternative.

What I won't do, however, is to just dump "X" onto you when that wouldn't deal with your biggest problem. I won't do it, is because people will not see the value of "X", and there's even a high probability that "X" will be blocked by whatever your biggest problem is.

The abuse of Cynefin

Scrum has been the tact giver for "Agile" for a long time. And Scrum is all about empiricism. And this "empiricism" has become a problem in recent years: Self-proclaimed, unqualified "coaches and trainers" proclaim that current organizational processes don't help, and hordes of incompetent "Agilists" swarm the market, only to wreak havoc on unsuspecting organizations.

Based on a mis-representation of Cynefin, people abuse Scrum and ditch available knowledge wholesale, because ... "In the Complex Domain, you don't know until you tried."

Now, is Scrum or the Cynefin framework really the cause of this problem? Not really - they are merely the door-opener for the snake oil sellers. And given Cynefin's and Scrum's easy appearance, people don't spot the trap until they fell for it. These frameworks are so popular and so easy to abuse, and it's really difficult for someone who sees them for the first time to discern what's correct and what is a mis-application.

Cynefin Framework by Dave Snowden

Now, let me describe the chain of "Cynefin Reasoning" that leads us down the wrong path:

"Knowledge Work (e.g. Development) isn't simple. It happens in the Complex domain. In the Complex domain, we have unorder where the relationship between cause and effect can only be perceived in retrospect and the results are unpredictable. Complex systems are dispositional and not causal. Hence, we cannot rely on good or best practices. Instead, we need to create safe to fail experiments and not attempt to create fail safe design."

It's a flawed understanding of Cynefin, combined with a false dichotomy that becomes a toxic soup. Here's why:

1. Just because something isn't simple doesn't mean it's automatically "complex". There's the entire domain of Complicated problems that's blissfully ignored, and even "Complex" is a category of varying degrees of complexity.
2. The idea that existing knowledge is entirely inapplicable doesn't describe the "Complex" domain - that would be the "Chaotic" domain: We can predict the outcome of a software development process pretty well. What we can't predict quite so accurately are customer reception and market conditions, but even there, we have quite elaborate mechanisms.
3. A shallow "dip into chaos" doesn't mean we should engulf, immerse or drown ourselves in chaos. Whenever we can prevent chaos, we're well advised to do so.
4. A scientific approach would rely on so-called "experimental conditions" where we fix all but the one variable under examination. If we let go of all control variables, we really won't be able to predict anything any more ("Chaos"). The latter is pretty pointless, and it can be avoided in knowledge work.
5. Just because something is "complex" doesn't mean we have no reliable process and are fully reliant on empiricism. To retain control, we need to minimize the impact of uncontrolled factors. For example, we would never have a smartphone if we didn't know exactly how to build computers, exactly how to build mobile networks, exactly how to mass-produce microtechnology, and those things would be a nightmare to use if we didn't know exactly how to build software that doesn't crash. It's complex, but it relies on a lot of things we precisely understand, and operating in this domain without high degrees of knowledge would be economic suicide.

And that's where we get into the mess today often called "Agile":

People don't understand what they're doing, because it's not a requirement to get into an "Agile" role. Fake "Trainers" without development experience make it look like that's not required - because, "hey, we got Empiricism". We encounter so-called "Agile Coaches" who don't know the building blocks of a functional company, we have to put up with 2-day "Scrum Masters" who don't know how to build a team, and see misplaced "Product Owners" who don't know what makes a product successful. And that's just scraping the surface.

Does this sound familiar?
"We don't need market research, probabilistic forecasting or demand control: Let's just write a User Story and put it into the backlog!" - "There's an entire science around Demand Management" - "Who needs that? Let's just incrementally Inspect and Adapt!"
Product Management, Quality Management, Process Management, Delivery Management, Operations Management, People Management, Finance Management, Sales Management ... we know a lot about these things! In the "Agile" community, however, there's a growing number of people who meet these with resentment, ideology and opinion: "managers are worthless anyways, so let's shoot all of that to the moon and apply empiricism!" 

The knowledge is discarded wholesale under the pretext of Cynefin - complexity and empiricism become the arguments against existing knowledge. "Inspect and Adapt" trumps science. Hence, "Agile" gets a free pass for obliterating functioning organizations: people with zero understanding of a domain "coach" long-term experts who have academically studied a subject, read the books, and gotten their share of field experience - and some even have the galls to claim that "coaching in the absence of knowledge works better, because it allows the coach to be unbiased!"

Thus, we set the playing field for quacks who will dismiss all scientific achievements and progress we have made in software engineering, bringing on the mumbojumbo, kumbayah, post-its and canned bikablo doodles: those professionals who did put in the hard work become indiscernable from quacks, organizations and individuals decline, order descends into chaos.

"Agile" has become a habitat for the same kind of science denialism as Anti-Vaxxers or Flat-Earthers: Except it's more subtle to spot, because the bodies of knowledge these people despise are the invisible fields in knowledge work. And Cynefin has been their door-opener.

Let me conclude with a question: "How will you approach complexity?"

ROCE Clusters - categorizing benefits

There seems to be a huge misunderstanding in the Agile Community about what is actually a "benefit". We quickly get into a false dichotomy where people argue that only ledger impact or only innovation should be considered relevant. Let's break with that. There are many types of benefits:

Different ROCE clusters

Before we begin: In no form or fashion would I claim that this is a comprehensive list of clusters, nor that there are no other ways to generate benefits within a cluster than those described: This article is an attempt to defuse the myopic perspective that there is only one way to look at benefits. 

Usually, an initiative aims at a number of ROCE clusters simultaneously. As a Product Manager, you must understand the clusters you're affecting, both directly and indirectly. In such a case, you need to define the target order: what's your primary focus, what consequential effects do you expect?

For each cluster in question, you need some metrics to measure whether you're making progress on your initiative. Financial metrics tend to be the easiest, with capability building metrics being the hardest to figure out.

ROCE Clusters

Every initiative you're pursuing should belong to at least one ROCE cluster. For example, "Reduce server outages for our Online Game from 8 hours a week to 10 minutes a month, to avoid losses caused by offering voucher compensations worth $150,000 a month."

ROCE clustering is very useful in that it can be aggregated quickly to a Portfolio level and gives you a pretty good overview of where you are spending your money: how much do you invest into patching holes, how expensive is your new strategy, and: are you innovating enough? 

If your portfolio contains only a few clusters, you may have a massive strategic problem.

This article describes seven different clusters and some metrics you may pursue within these clusters. You may find different or additional metrics, or you may find some metrics applicable to a different cluster, and you may find that a cluster not listed here is missing for your own organization. 

If you wish to adopt ROCE clustering in your organization, you may need to identify those clusters relevant to your own organization.

Ledger Benefits

Although the most desirable benefits from an accounting perspective, these tend to be the most elusive in practice, as they are often more consequential to other benefits than direct.

The two most common ledger benefits we are looking for are:

• Profits
• Savings

Loss Avoidance

To discriminate this from "savings", let's first define "loss": Loss is an evitable part of your business that only exists because something is messed up.

Common sources of losses are:

• Fines
• Write-Downs
• Cancellations
• Compensations

Capability Building

The problem with Capabilities is that you can't really translate them into money: they translate into future benefits. This makes capability building very risky, because you don't know if it pays off until it does. And that may be years into the future.

Here are some kinds of capabilities you may invest into:

• Strategic Enablement
• Support Infrastructure
• Network Effects

Innovation

Why should we innovate? The modern business-oriented approach is to look at a problem you observe, then solve it. New solutions to known problems are the most common form of innovation, and most companies innovate mostly in a form of local optimization, i.e. solving their own problems. New products often appear on the market when they solve someone else's problem. But there are also other forms of innovation - those which only serve as a foundation for building solutions to problems. This gives us the most common forms of innovation:

• Solving Process Problems
• Solving People Problems
• Solving Market Problems
• Base Innovation

Demand Shaping

It may sound odd, but sometimes, we invest money not to build some product, but to shape demand for an existing product. Demand shaping allows us to optimize the value generation of our products and services - which includes reducing overproduction and overcharging on the one hand, and stress and overburden on the other. It comes in three forms:

• Increasing Demand
• Stabilizing Demand
• Reducing Demand

I would like to go specifically into point 3 - reducing demand. That's an especially good idea on something called "failure demand", i.e. when a service unit (e.g. Complaints, Repairs) faces high demand due to something else not working. It's also an important preventive measure when over-demand would lead to negative business outcomes, such as loss of trust.

Risk Management

Risk Management could include anything that reduces impact and/or probability of anything that affects either us or our customers. Probably the most famous risk management product is insurance, which does nothing other than moving financial risks from our clients onto ourselves. It doesn't reduce probability, only impact.

The most common types of risk we're dealing with are:

• Business Risk
• Operational Risk
• Market Risk

Compliance

The last cluster this article covers is compliance with rules and regulations - in this cluster, we can't win, we can only minimize losses. So, how much should we spend on compliance? As little as possible, and whenever we do, we should try to combine it with at least one other cluster.

Compliance isn't as much about solving problems, as it is about meeting minimum requirements from:

• Laws & Legal
• Market Regulations
• Standards
• Safety & Security

Summary

ROCE Clusters aren't benefits, they help you categorize your benefits in a way that it becomes obvious where your portfolio budget is going and where you're looking for improvement.

You will still need an appropriate benefit hypothesis and actionable metrics to turn this into a relevant business practice. But that's another topic for another article.

Philosophy in Organizational Change

Yes, I'm opening a can of worms here. "We are here to work, not to philosophize!" - is that really so?
Before exploring this question, let me start by clearing up the common misgiving people have about "philosophy": this isn't idle chatter. Philosophy is all about "knowledge" - how we arrive at the conclusions we do, and what leads us to do the things we do. For example: We talk a lot about vision, strategy and values. But: How do we interpret our vision? What makes a good strategy? And how do we turn our values into behaviour? We need philosophy to move beyond the bla-bla!

I'm not exploring the entire domain of philosophy, only a few things that are really important when dealing with organizational change. And I'm just going to touch "What's in it - for you? Why should you care?" rather than explaining any details. All I'm trying to achieve is get your interest in the topic sparked. You'll have to do your reading by yourself.

Ethics

Every organization has its own set of implicit and explicit values and norms. Which ones do we have, why do we have them, and do they serve us in the way they should? How do they inform our choices?
What does it take to arrive at a different set of values and/or norms?

For example: If our organization values "being busy" - how could we move to "producing value" instead?

Logic

There are tons of illogical things going on around us every day, and nobody seems to care.

The majority could be wrong. And might doesn't make right. Just because something is right, doesn't mean it's true and vice versa. When something doesn't follow from the premise: can you spot it, and where would that lead you?

Sound reasoning leads us to make better decisions. How good is our organization at reasoning?

For example: Just because there's an unspoken consensus in your organization that you "don't deploy on a Friday", doesn't mean it's an indisputable fact: Why can't we deploy every day?

Knowledge

Did you ever "know" something was the right way to do things, only to find someone did the opposite - and got better results? Most of what we know is little more than contextual snapshots of momentary experiences, turned by our brains into immutable "facts". And while there are definitely some things where scrutiny just leads us off a wild goose hunt, there are other so-called "facts" that we must discard in order to grow. But how can you discern?

For example: We know for certain that there's a legal reason to archive every contract in written form. But ... how does a paperless, totally virtual company do business in compliance with the law?

Ontology

"What is ..." - the way we define things informs how we think about them. What is "value", what is "performance", what is "success?" - Do you have the necessary means to ask the right questions that allow you to align people around a common understanding, weed out misunderstandings, and provide a more focused definition that allows people to overcome their own mental barriers?

For example: As long as everyone has a different understanding of "Value", it becomes pretty hard to maximize value creation. How would you - properly - define it?

Philosophy of Language

Our lanugage affects our thinking, which affects our reality. The words we use have the power to unite, divide, shape or reform. The subconscious effect of our lanugage is that simple things could become possible or impossible, easy or hard. Our lanugage can create insurmountable barriers or build inviting bridges. How much of what we consider "real" in our organization is just so because we choose to use words the way we do?

For example: The most nefarious element we see in many organizations is calling people, "resources". It's not merely de-humanizing - it has practical impact: "Resources" are assumed to be interchangeable for one of equal type. That leads us to move people across projects in an attempt to optimize "utilization" - which significantly reduces performance, and thereby, drives cost and risk through the roof! 

Philosophy of Law

Ethics informs our norms and values. And what happens when we transgress those? Which one are we willing to sacrifice when two norms are in conflict? Based on what reasoning can we trade off one value for the other? 

For example: Who can decide whether it's okay to put a risky feature live that could either increase value or make customers unhappy? Can I, as an individual, place the value of learning above the risk? What consequences will my choices and actions have? 

Philosophy of Politics

Power rests where it does. We can choose to re-distribute it, but would that even be a good idea?
What's the relationship between a company and its employees or between "manager" and "worker"? What does security and individual freedom mean? How do we trade off between these, and what consequences do that have?

For example: By giving people a corset of processes, we offer a sense of security by working in accordance with known, explicit regulations - while stealing their freedom to do the right thing for the benefit of the organization. 

Game Theory

Every day, in every one of our actions, we weigh off alternatives. The course of action we choose is ultimately that which benefits us most. How do we set up systems where individual, group and organizational goals align with each other - and how do we ensure that everyone benefits most from actually pursuing these goals? Every system can be gamed, then how do we ensure that when it's gamed, we still end up where we want to?

For example: By measuring "Velocity", we might end up rewarding doing a lot of useless work, or by inflating the actual effort. None of that helps us. Then - what should we measure instead?

Conclusion

I hope that this teaser is enough to get you interested in learning more about the domain of philosophy, spend time on equipping yourself with understanding and methods to approach each of these topics, and begin leading the important discussions that will improve clarity, transparency and mutual understanding within your organization.