Storytime: A developer turned coach

It all started so innocently. Until I got a team to lead.

My story starts like probably millions of others. You graduate from some kind of computer-related college, start programming, learn a language or a library, build some stuff, and you’re a happy camper for a couple of these first years. But then many of us get into that team lead role – and life finally begins 🙂

Then came a couple of courses and coaching camps with absolutely one of the best agile coaches and trainers on the planet, and my mind was finally opened.

Some of you probably don’t feel like reading about someone else’s struggles and epiphanies, but hang on because you’re about to read some raw stuff. My mistakes and lessons can help you make fewer mistakes of your own.

Are you still with me? Great. 👍 Then grab a coffee, make yourself comfortable, and start scrolling as my epiphanies unfold.

Epiphany #1: Scrum is about behavior change

This is still vivid in my memory as if it happened yesterday, only it happened in 2015.

I talked with my trainer about a burndown chart and how my team didn’t care about plotting it. Stupid, right? Plotting a burndown being a problem? “C’mon man, let it go,” I hear you say, but I was a proper Boy Scout, so it bothered me.

My trainer asked me, “Why is that a problem?”.

Right then and there, I was knocked out of my shoes, floating in empty space. Ehm, “What do you mean, they’re supposed to plot the burndown! That’s mandatory!” I was desperately trying to grab onto something. He rephrased his question: “What problem is plotting a burndown supposed to solve?”.

What kinda question is that?! I was still unable to grab onto…anything.

A bit of extremely uncomfortable back-and-forth—because it was all happening publicly in a group training—made me realize that the burndown shape—if it’s flatlining or somehow out of whack—is a good conversation starter about who’s doing what and a trigger to get people into reorganizing.

And by “behavior,” I don’t mean just reshuffling tasks and giving advice. It’s about going out of your way to help a fellow team member by unexpectedly pairing with them for three hours, talking with a PO on re-planning, or redesigning a feature mid-sprint.

You know, big stuff like that. Yeah, yeah, “what a junior,” I hear you say 🙂

And that was the beginning. Slowly, my eyes opened; man, I was in for a ride. 🎢

Epiphany #2: This Scrum thing is a very serious matter

It happened on a training course during a sprint review module. We were building a Lego city as many future CSMs did, and we didn’t finish it on time and didn’t really care about the quality.

We always have the next sprint to fix it, don’t we? 🙂

At the end of the module, the trainer came and played the stakeholder role. He looked at our city, did some minor stress tests on the buildings, and asked questions, such as, “Why doesn’t this house have a roof?” and “These house doors are not big enough for a Lego figurine to pass through them”,“Why does the road end up in a house?”.

Yeah, okay. These are all valid questions, but what struck me was the dead seriousness with which he asked them. I remember thinking, “Jeez, man, why must you be so serious? We’re playing here.” 

Then I realized that it’s no-excuses mandatory for every product increment to be of high quality and done.

Everything else just flowed from there, especially how we refined, planned, did daily work, and tested. It was a game-changer.

Epiphany #3: You can’t change people

A year or two into my journey, I was blessed with all the knowledge I gathered because, hey, I was hanging with the world’s elite trainers and about to solve all the world’s problems.

This was it—my moment to shine. I was ready!!! Now, the only thing is to teach everyone everything.

And off I went on my merry way. You don’t need to think hard to realize I crashed badly.

💥 Crash #1

I came into a new team and a new room, which was set up so that everyone was looking at each other face-to-face with monitors in between. This means you had to get up to see what’s on someone else’s screen rather than just leaning aside or rotating your chair. Yes, we programmers are a lazy bunch, and we often hate to get out of our chairs. Raise your hand if you do. Yeah, thought so 😀

Immediately, I thought, “This can’t possibly be good for teamwork,” and I poked the team with, “The table arrangement isn’t really doing much for your teamwork, is it?”.

I was aiming for “individuals and interactions,” but it turned out completely wrong. Yeah, they didn’t care that I had all these educations in my back pocket, or even if I knew what was best for them – which I didn’t. Needless to say, the desks stayed where they were, and I didn’t start from the ground floor, so to speak. I started from the basement.

💥 Crash #2

A particular project was underway, and the team structure and the whole organization didn’t fit the problem. So I talked to my PO, the program manager, with all the right arguments – frequent integration, colocation, cross-functional teams, knowledge transfers, etc. – only to be shut down like a simple light switch.

The project was already set up—for failure, it later turned out—with multiple vendors on it, a couple of dozen people settled in their teams, components to build, team leads defined, progress reports defined, and WIP limits unexisting, all according to the client’s culture. Were they willing to reorganize all that because a developer suggested so?

It was David vs. Goliath, but this time, David lost. Power structures, politics, career plans, promotions, culture—I was going against all that. We were all working to make the project successful and were willing to set aside our egos and old ways of work, I naively thought.

The lesson? Don’t be naive, assuming people’s motivations even if you think the situation is dead simple.

💥 Crash #3

The biggest crash happened when I was co-training with my colleague at a client.

At that point, we’d been working together for a while, and I did not like his coaching style.

He was pretty monotone in his speech, always used more words than necessary, and had no life in him at all. This frustrated me beyond belief, especially because I saw clients had the same impression. I tried to tell him, but he was completely oblivious. And it burned in me this desire to change him. It was huge.

Then, one day, I was reflecting and visualizing that fire. It was bigger than a house. I looked directly at it and finally came to a very frustrating realization that I was completely powerless over him. Submission, humility, and silence took center stage.

It took a bit to make peace with that realization, but right when I thought all the doors were closed, a new one opened. And no, I didn’t do anything to my colleague, I just let him be – which had fascinating consequences. Suddenly, a new level of acknowledgment of his entire being appeared out of nowhere. Strange, huh?

And that door? We’ll get there, hang on a bit 🙂

Moments of Zen and The Perfect Storm

Today, I live by the fact that I can’t change other people. But sometimes, I can change myself. The cool thing is that other people can do that as well. (Duh!)

But the conditions have to be right: inspiration, timing, where they are in life, and even their adult development stage (for lack of a better word), amongst a myriad of other things.

A perfect storm has to happen; all I can do is inspire and fuel it with some coaching. That’s it. That’s the door – inspiration and perhaps an invitation.

Everything else is outside my range, and I would probably be on the verge of disrespecting that person.

Back to Basics 🎯

I had all these very humane and deeply humbling experiences while developing the practical side of agile coaching.

I was learning all the methods: Scrum, Kanban, XP, all the templates like Lean Canvas, Business Canvas, Lean A5, coaching cards and tools, scaling frameworks like Less, Nexus, Scrum@Scale, all the culture, psychological, and facilitation stuff, and all the tools and technical practices.

I gotta stop, or I’ll lose my breath, and you’ll get dizzy! 😀

You’ll laugh your butt off, but I’ve read Herman Hesse’s “Journey To The East” to understand servant leadership. I even read a bit of Brothers Karamazov to learn about freedom – and how most people don’t really want it because it never comes without responsibility. I also heard Moby Dick is recommended reading for future agile coaches, but that’s still pending 🙂