If I were an Agile Coach, or rather, somebody whose job is to bring or improve ways of working or the way the company operates, there would not be a mention of Agile. No Scrum, no Lean, no nothing. Tell me about your pain, your situation, your context, the reasons you’re trying to change, where you’re trying to change and to whom you want to apply the change. The latter is of utmost importance. First, because it so happens that managers are the ones that hire coaches or consultants. Second, because there are managers who hire the coach to only look down, not up, to fix the workers, since they’re the problem—they’re not efficient enough, not fast enough or not good enough.

If I were that someone who's hired to improve things, I’d like to know if it’s worth it. Are they willing to look at themselves, change habits, and be comfortable being uncomfortable? If not, it’s probably not worth it. Do they want to hire me to implement Scrum, Shape Up or the newest trendy framework? Not worth it, I would rather not be part of making developers more miserable than they already are. Is the manager fixated on making everything and everyone efficient and doing things as fast as possible? I’m out.

I would only work with people that truly want to be helped and are open to trying new things.

There are only a few things I’d care about at a high level, and one of the more important ones is value. The sooner the value, the better. Notice I didn’t write faster, but sooner. Creating value sooner is not the same as building features fast. We could be building features fast and not get any value.

Thinking about ways to create value sooner encourages us to consider what’s stopping the flow or adding friction. What’s value? Value is a bit ethereal. I’ll refer to Ron Jeffries, who writes in The Nature of Software Development, the following:

Value can also be information, doing the ethical thing, protecting the planet, improving working conditions, etc. Whatever value is, we can probably examine what’s stopping it from being realised sooner.

As a coach, my first objective would not be to revolutionise the company’s world. That might be perceived as an aggression. I need to earn people’s trust, and to listen and understand first. It’s incredibly difficult to make any kind of change if nobody trusts you to begin with. It’s important to see below the surface, what’s the working climate, how are people feeling, how do they interact with each other, what are the power dynamics, is there psychological safety?

Whatever story I was told when hired, it probably won’t be the same as the experiences of the people actually doing the work. The manager might’ve told me that collaboration was great, but it turns out nobody talks to each other, or that quality is paramount, but then devs are incentivised to cut corners, or there’s friction.

My second objective would be to surface issues and opportunities for improvement and encourage conversations around them. Maybe people are not ready to talk openly and honestly, due to a low level of safety and a degree of conflict avoidance, and it’s worth making everyone feel safe and getting the tools to deal with conflict before engaging in conversations.

I want people to own the process, I’m not here to order them around or to impose the framework, I’m here to spark the flames of change and to support them in getting to a better place. Is what I’m describing a retro? I want to avoid putting labels on it, since the moment you say retro or any recognisable word, people start to put barriers on it and might follow a script. It is simply a conversation. A conversation about how things are going, how we’re feeling, and what obstacles we’re finding along the way. Nothing’s off the table.

These conversations should be frequent, possibly at a regular cadence, to encourage them, but without constraining them to the events on the calendar. If we need to stop and talk about what’s happening, we talk, we don’t wait.

Not everything has to be solved or fixed all the time because of the conversations. Specially because there’s a tendency for people to obsess with fixing at all cost, missing the forest from the trees, without looking to build deeper understanding. A classical example is a post-mortem after an incident, where the “root causes” have been identified, and the resulting actions actually make the system worst—less resilient, creation of value gets slower—by over indexing on more gates, bureaucracy, or control.

An important aspect of these conversations is that I don’t want to create a constant spiral of dumping and negative thoughts. If that happens, it might indicate bigger problems, that they don’t have agency, that they are already too swamped with problems and probably burnt out… The goal is to enable agency, to make the conversations meaningful. Once people start to see that they can make changes, agree on what to address and that the ball’s actually rolling, it can be a beautiful thing.

As a hypothetical coach trying to improve things, looking at delivery from a technical perspective is paramount. We cannot create value sooner by having our favourite grotesque framework™ in place and wishing for the best. We need to focus on the technical aspects, on technical excellence. The goal is to get the team to release more often, with confidence, on demand, on any day of the week—even on Fridays.

I would love to sit down with the developers and do learning katas around topics they’d want to improve. Maybe they don’t know how to come up with smaller stories, refactor, work in small commits, test properly, etc. I would push for giving teams learning time to improve their craft. The typical thing is to have one hour a day for learning purposes, which is fantastic. On top of it, encouraging a team to work together in both katas and in the real code to apply the patterns they’re learning is even more beneficial.

Let’s jump to something way more controversial in delivery: estimations, deadlines and parallel work. I’ve been meaning to write in detail about estimations in a future article, but for now, as a fake, controversial, and probably unhireable Agile Coach, I’d try something different: if the team, and specially managers and PMs, are willing to experiment for a few iterations, there would be no story pointing and no refinements or planning, at least not in the way everyone do them.

Without getting into too much detail here and simplifying a lot, we—devs, designers, PM, stakeholders—are going to get together, discuss all the valuable things we could do, and out of all those things, we’ll pick the thing that we value the most. From that valuable thing, we’ll choose the first small or tiny bit that we want to get out into the world and start working on it. When the tiny piece is done, we’ll look at it, see if it produced value and learn from it. Do we want to continue with another small piece of what we originally decided to focus on? Maybe after a few pieces are done, we have created enough value and want to shift to other things, perhaps we want to double down or, if we’re lucky, we learn the idea wasn’t good enough and should stop.

Let’s jump into discovery quickly. I would like to get devs involved way earlier into the flow and also at the end of it. No more tickets and full-blown designs being created and thrown to developers with no context. It would be difficult to convince people, and it’s better to start with something small first, a conversation. Another one? Another one indeed. The product manager, the designer, and the devs could get together and quickly go over what they are eager to learn, which people they’re going to interview, what problems are on the radar and want to potentially solve. Same thing with released work, how did it go, was it valuable, what have we learn from it? If this is not possible, potentially the product manager could regularly communicate quick info to the team about the problems they’re looking at, experiments they want to run, things they’ve discovered… just to keep everyone in the loop.

Talking about keeping everyone in the loop, it’s vital that the team communicates regularly on the progress and how the changes align to the company goals. Teams are not a moat. “This is what we’ve done, this is how the numbers are looking, this is what we’ve learned, these are the opportunities we’re looking to solve now and the few insights that we’ve discovered, etc.”.

Now, nothing would be possible if the structures of communication are not addressed. Going back to creating value sooner, how communication disseminates, the amount of cognitive load of teams, and how their structure is an important thing to consider. I would use Team Topologies concepts.

How would I measure success? Value is being created sooner, quality is higher, the teams are happier and healthier.

Lastly, a disclaimer:

I’m not an Agile Coach, I’ve never worked as one and probably don’t intend to be one. Most of the things I’ve mentioned here are way more expansive than what a coach could most likely do, and the levels of influence to do any of those would be higher. I’ve taken the liberty to use this uber powerful and mythological Agile Coach figure to inject some of what I’d love to do in my magical world of shiny, happy developers.

Interesting links

• OKRs are bullshit.

• OKR’s and OKRA. Charles Lambdin describes a few ways OKR’s go wrong and mutate from the original idea. “Time and again large organizations adopt the latest fad, but then drive them through the prism of their existing cultures. The Borg assimilates”.

• Nix Turns 20. What the Hell Is it? I’ve been hearing the word Nix for a while now, and never understood what it was or what’s the difference between it and Docker or other tools. Luckily, Josh Alletto’s post goes into what it is, and while I’m still confused, I’m now intrigued.