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.