Tag Archives: coaching

Good Coaching Means Being an Example

In the Agile coaching game, many times we coaches work as close as we can to several teams at one time. We’re there to provide structure, feedback, and a mentored learning environment as teams move to more agility. And of course, like any consultant, we’re paid smart friends. The client’s needs come ahead of our own.

But the goal is for the teams to become more Agile: to work better, faster, and have a happier work life and life balance.

So I was wondering how to handle a question we received a few weeks back. A friend and I were doing some Intro to Agile courses, and during one of the free-form discussions somebody flagged me over.

“So which is it?” he asked, “You told me we were supposed to have the sprint close, retro, and sprint planning all in the same day. This other guy says you split them up.”

He pointed at my friend. He was clearly frustrated.

I looked at my friend. I felt that the advice he was giving was not-so-good, but it was also important not to argue randomly in front of the client. On one hand I felt we were going the wrong way. On the other hand if we were to make the training too chaotic, nobody would get anything out of it.

“Hey, i do it this way,” I said, “and here’s the reasons”

“We’ve always told them this other way,” my friend said.

My friend and I kinda looked at each other. Both of us wondering: are we going to get into a long, boisterous discussion here? Is this the place?

So I looked back to the guy. I said “Look, I still feel my way is better, but it’s not that important thing. I like strawberry ice cream, you like chocolate. Let’s do it the way it’s always been done and see how it goes. We can always adapt later.”

There are a lot of coaches that would have a problem with this. Every little thing they coach is terribly important, and it must be done a certain way.

I’m not one of those people, and more to the point, when we coach we need to be an example. Do we want our teams full of people who either a) disagree all of the time and refuse to back down, or b) are so apathetic they can’t have an opinion on anything?

Of course not. And so we shouldn’t model that behavior. We should have “fierce opinions, lightly held” — be willing to explain and advocate, at length, why we feel a certain way. But never let that get in the way of things moving forward or the spirit of the team. Keep perspective.

I think a lot of time coaches (and the rest of us) get hung up on the details of coaching and forget the purpose of coaching.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Video Series Kicks-Off

A month ago I was talking to a client when the subject of Agile reporting came up. There was a lot of discussion around tools and meetings and all sorts of complexity that might occur in a large Agile program.

Feeling a bit flustered, I walked away and started drawing on a nearby whiteboard. What’s the maximum amount of visual indicators you would need to run a large, complex Agile program? It’s a small, finite number, and maybe by just getting it all out on the wall it would be clear that the real work is in running the program, not all the tooling and pretty displays. You should be able to capture, report, and analyze program status in just a few minutes per day. The rest of your time should be spent, well, working.

Took about an hour to draw it all up, and folks liked it enough to put a big “Don’t Erase!” on the board. Last I saw it was still on there.

But what really sucked was that I could see myself having the same exact conversation with another client in a month or two’s time. And having to draw it all over again. Was there some way to capture these kinds of whiteboard chats so they could be reused and shared more easily?

Turns out yes, yes there was. Using a graphics tablet and some software, I could capture a whiteboard chat and not have to repeat it. Way cool.

So then I thought, what’s the most helpful question I could answer for folks on the net? Something that they would have a difficult time getting from others?

I felt the answer was “How to prepare for Agile Adoption” because there are so many opinions, it’s tried so many different ways, and vendors have a conflict of interest — many times they’d much rather take your business and hope they can straighten things out later than tell you up front you’re doing it wrong — especially if you’re willing to sign the contract with somebody else. By being a talking head I could offer up my years of experience and not have “skin in the game”. I’m just sharing what I’ve seen.

Well this was getting to be a lot more fun than electric cooking, so, of course, I had to do a few more. After all, what would be the fun in just two? Today I finished up “Scrum Vs. Kanban”, which is a look at the two methodologies and how to apply them in your organization.

I have a list of a dozen or so topics I’d like to do, but I’m not sure if I’ll be able to do all of them. This is a new format for me and I like it because it combines teaching, movie-making, and technology development.

For those of you interested in the business side of things, the videos provide a calling card for me, they point traffic at my micro-publishing site, Tiny Giant Books, and since they’re about management in general and not some specific technology, hopefully they should hang around on the web for a long time.

But the biggest reason to do these is that all the pieces just came together. I had the tools, the material was already put together, I had deep knowledge in an area that many might find useful, and it looked like an opportunity to help lots of folks. It was just a no-brainer kind of moment.

If you have any ideas for topics or feedback from the videos you’ve watched, let me know! I’m enjoying learning this new media, and it the more feedback I get the better the result for everybody.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

How Can I Help?

I’ve decided the most important conversational phrase in the English language is “How can I help?”

I don’t come to this decision lightly. There were several others that almost made it.

“I love you” was a top contender, but it says more about my own personal feelings than my relationship to the world.

“Let me help” also didn’t make it. It focuses more on my taking control of things.

“Try this” was big, but it was more of a plea for validation than anything else. I know more than you. Listen to me and you’ll do better. Nope, at times this might be true, but it’s backwards. My relationship to knowledge is nowhere near as important as my relationship to the person I’m talking to.

“We can do better” was also easily in the top ten. I think I’ll put that at #2. It reminds me that we are all in this together, and that there is always room for growth.

Nope. “How can I help” says it just the right way. If you will tell me how you think I can help, I’m willing to give it a shot. I subvert my own interests to yours. Tell me what you’d like. How can I help?

I do a lot of things — write, speak, train, consult, coach, manage, and so forth. I find most all of them are some version of “How can I help?” I also find that when I start drifting to any of the other phrases, such as “Let me help”, or “We can do better”, I always start drifting away from the true core of what I’m doing. I become a lesser person.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

It’s the Small Things

One of the things I’m noticing with some of my fellow coaches is their desire to work at the program and enterprise level. It seems there’s nothing like coaching a bunch of teams at once to really get your feet wet. Things look better at scale!

Well yes, and no. I’ve been fortunate to have several work experiences with teams and organizations of all sizes. Last year I worked with a team of two guys in a broom closet. A couple of years before that, I worked with an organization that had over 20K IT folks working almost a thousand projects. On six different occasions I’ve had the pleasure of helping to set up and run programs — teams of teams. A couple of times more than one program at a time.

I’m not trying to brag, just let you know that I have had the relevant experience to talk about this. I’ve been there, done that. While yes, it’s kinda cool working with groups of teams, it’s also very easy to make a lot of mistakes that you never realize you are making. Here are the most common ones.

  1. Premature optimization. The first thing large groups of teams want to know is: what’s the standard? Because you can’t manage a lot of people without processes and standards. (At least in their minds)

    Coming from Agile, many of us know better than to focus too much on process, but clients insist. They want job aids for everything from stand-ups to sprint closings. They expect coaches to all deliver identical advice on any topic.

    This is a really bad trap, because the entire premise of Agile is that individual teams and situations are so varied that we must push a lot of process decisions onto the individual teams. The purpose of our Agile rituals and delvierables is to identify the work and possible paths for solutions: what problems do we face? What types of actions might help the most?

  2. Us versus Them. One of the worst things that happens, often without the coach even knowing it, is that they begin to fall into an “us vs. them” attitude. Who are these teams? How come they keep doing stupid stuff? Why won’t they listen? Over time, you subtly stop being a servant for the teams and start wondering why the nincompoops just won’t do what they’re supposed to do.
  3. Tools will fix anything. Once we get sufficiently detached from the actual problems the teams are facing (and this can happen inside the team, you don’t need a program for it) we start buying into the idea that the tool can fix the behavior problem. Need folks to start making comments when checking code in? Just force it to happen! It’s magic — because you’re not actually dealing with the problem, just the symptom. You’re using a hammer that’s close-by to pound on a problem that’s close-by. Many times the thing you are pounding on is fitting a square peg into a round hole.

The more I work with both large and small groups, the more convinced I become that the vast majority of problems organizations face are at the team and individual level. If teams don’t provide timely and accurate information to people outside the team who need it? You’ve got junk. If teams don’t manage their quality and testing? You’ve got junk. If teams don’t communicate and problem-solve effectively? You’ve got junk. If teams keep trudging along punching the clock without creatively re-framing their problems in order to make life easier? You’ve got junk.

So yes, it’s lots of fun to be helping and working on a 100,000-hour+ program. It’s even more fun to be helping set enterprise policy. But those things are way less important — and way more likely to actually hurt things instead of helping — than the small things that the teams and developers do everyday.

Trust me, it’s the small things.

Note: One of the things most people fail to understand about groups of people is how naturally decentralized they are, even in highly-centralized organizations. People think “We’ll just make a policy to do X” without any idea of how it actually is going to play out. People think if somebody is in charge of a large group of people that they can just tell folks what to do. There’s a ton of myths about how large groups of people are actually led — enough for another entry!

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Trusting the System

I remember when I first learned and really grokeed Object-Oriented Analysis and Design. I had read a bunch of books. I had even designed and coded some systems. Some had went well, but some, well, were a bit more complex than they needed to be. See “Architecture Astronaut

Then one day I picked up use cases. Not the god-awful templated 30-page nightmare that most companies make out of use-cases; the real deal. trigger-actor-goal-context process analysis. The kind you can do on a napkin. Maybe sketch something on the back of it if you’re having problems. Specifically, how process analysis fits into Object-Oriented Analysis. Process analysis tells you what needs to happen. OOA tells you what are the logical pieces to make it happen. Semi-structured, all from plain English.

I realized at that point that both OOA and process analysis helped me do one very important thing: I no longer had to keep the entire problem in my head at one time. I had a system that I could use to pick up any problem and drive it towards some kind of resolution. It might be an ugly resolution, but I could get there. I didn’t have to be a genius to solve tough business problems. I just had to follow the system.

I had a similar experience with Agile. As a young PM, I had a desire to plan out everything my team was doing. After all, the more I planned, the less risk there was, right? How could you do anything truly complex and important without having a detailed plan of how you were going to attack it?

At the time, I hated making developers suffer, so I held back. I would secretly plan a bit out ahead in order to make myself feel better, but unless we needed it, I let the team do their work. This wasn’t out of any feelings of comfort. Heck, I spent most of my time as a PM worried about the 17 thousand ways things could go wrong. It was the mid 90s, and we were charging tons of money to solve complex problems. Lots could go wrong.

But what I found out over time, as I adopted more and more “Agile” practices without even knowing it (“Agile” didn’t exist at the time), was that all of my planning was really just a Stupid Human Trick. I felt that by treating people like computers, by programming out everything that was going to happen, that somehow I was reducing risk. But what really happened was that people would always find the problems I missed, and if I left them alone, would go fix them. Turns out people were pretty good at identifying and structuring their own work as they went along. Much better than I was by myself, doing it for them.

Eventually I learned there was a system. There was a minimum amount of structure that I could (had) to provide for teams to succeed. As long as I did that, they would always rock and roll. My job as a PM (and later SM) was to get obstacles out of the way, provided the most minimum amount of structure necessary, and watch the magic happen.

I didn’t have to be a genius to solve tough technology development problems. I just had to follow the system.

As a coach, when I explain these and other concepts like them to folks, many times I get the “crazy uncle” smile. Yes, Daniel, they say, of course it’s all that. (Meanwhile wondering how much I am billing and how did we get stuck with this nice, but misguided guy who thinks the world works on magic)

I think it’s one of those things you have to see to believe. Once you tackle a super-complex business problem using simple tools, you realize you can do this over and over again. Just trust the system. Once you see a team solve a ton of development problems while delivering a product the customer wants, you realize you can do this over and over again. Just trust the system.

Yes, we take this too far. Sometimes people don’t really understand that there is a balance between structure and chaos. Sometimes they want to say silly things like “It’s emergent” to describe conversations and processes they don’t understand. When you see the magician do a few tricks, you might start thinking he can do anything. He cannot.

But most people have the opposite problem. They come from school, where you had to understand the complete problem and solution to get a grade. They want to do well where they are, so they want to be able to describe just how each piece of the process works to create a solution. It is completely counter-intuitive to think that by doing simple things in a system, you can achieve enormously complex goals. But for many of the really cool things in life, that’s how it works.

Trust the system.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Coaching Coaching Teams

If you work IT long enough, you go meta. That is, at some point you’re not doing the thing, you’re doing the thing about the thing.

Here’s an example I shared with my audience today about what happens when you coach teams that coach.

Many times, the coaching team is brought in under a Statement of Work, or SOW. The whole purpose of a SOW is to describe exactly what the team will be doing. And most every time you will have a contact that will prioritize work and define “done”. So you have a backlog, a budget, a Product Owner, and a highly-skilled team (after all, this is a coaching team — these guys know what the heck they’re doing!) What could go wrong?

I think people think that having a great team means having really smart people work on a clear list of things with somebody telling them when they’re “done enough” is all they need — but that’s not true. For instance, lots of startups who are funded by VCs do a lot of activity and yet get nothing done. Activity does not equal progress! You can have structural problems with your list of things to do that can’t be overcome by any degree of technology or smarts.

Activity does not equal value.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.