Tag Archives: training

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.

Agile Means Doing New Things Even When You’re Happy

I’ve spent some time lately on a book about how to really implement agile — not something that cheerleads agile, but something that rather takes a long, hard honest look at all the various ways we screw things up.

One of those ways is our ability not to be able to accurately predict whether a change will have a positive effect on our team or not. It’s very easy when talking about something, say TDD, to sit around and list the seven million reasons why it won’t work for us. What’s much more difficult is to honestly try something new with an open mind and see what happens.

The scary parts are 1) Nobody is immune to this, and 2) It works for all kinds of changes, not just the “right” ones.

Maybe your team might work better without TDD. Are you willing to try that?

We cheat. Instead of honestly trying new things, we take up mentally-easy positions and defend them. One of those positions might be to try everything that you read in a book and sounds great. This is sort of a chaotic model, where everything is always in flux. One position might be that you’re plenty happy with the way you’re doing things now, so why change anything? This model is rigid and brittle. Then there are the folks who have a bible of sorts that they use to determine which changes to try or not. Did Ken Schwaber say it was cool? Kent Beck? Uncle Bob? Cohn? Then we’re definitely trying it! Otherwise? Not so much.

It seems like it’s very difficult to reach a happy middle-ground: trying some things every now and then — not too much to have complete chaos, yet not too little to get in a rut. Trying out things we hear about — but not because of the social standing of those telling us.

This fault is built into the human mind: we are herd and troupe animals at heart. It’s not a bug, it’s a feature! All of these attributes create real-world primate survival skills.

I was thinking about this last week as I introduced Agile to some folks in a nearby town. I was using somebody else’s presentation, and he called for bringing in Play-Dough and some other stuff. I hadn’t used it before, but I figured “what the heck?”

It worked very well, and now I’m a big believer. I couldn’t help but wonder how many of those lectures I have given without the Play-Dough gimmick and how many more people I could have helped had I switched earlier. You never know.

You see, I was happy with the previous way I was giving the presentation. I had thought about various ways to change, but that was all I did — think about it. I never actually tried to change. It was much easier just critiquing the idea from afar.

The ironic thing is that I see this behavior in teams all of the time: I’ll introduce a new concept and they’ll insist that it’s not going to help anything. This is one of the reasons we use coaches to implement Agile. A big part of being a coach is helping people practice things they think will not work — until they finally figure out how great its working. Then they wonder why you didn’t tell them in the first place.

People are funny animals.

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.

Markham’s Scale of Ignorance

Yesterday a couple of readers gave me grief for all the “knowns”, “unknown knowns”, “unknown unknowns”, etc.. On top of that , the definitions got a little loose in the essay.

So instead of fixing the essay (Gad no! This is the internet! 2-hours work constitutes long-term commitment) I thought I would enumerate the scale of what you can know and what you can’t. I’m probably reinventing something from somewhere, but I think these distinctions are important enough to restate. One of the authors from the articles I quote came to the conclusion that you can deal with any amount of unknowns simply by knowing the questions. Hell no. That’s totally whacked.

Ten years ago I sat in the office of a high-ranking procurement officer in the military. He was a fast-riser, had a masters in mathematics and was a very sharp guy. I was explaining to him that the way the software development was going on a certain project was troublesome. The people, technology, process, environment, and bureaucracy were not working together. Instead various misunderstandings, agendas, confusion, and ignorance was causing chaos and poor performance.

It was a complicated discussion, made more so because each of the varying factors – people, technology, process, bureaucracy, environment – were pretty dang complicated in their own right. The way they all worked together — or were supposed to work together — was even more complex. Remember, this guy was probably a genius. Literally responsible for tens of billions of dollars. But he had no concept of what he didn’t know. It was like trying to explain String Theory to Julius Caesar. We just had no place to meet. Sure, given a few weeks of gaining some common understanding, this guy would be teaching me something. There was no stupidity at work — he was a brilliant man. He wasn’t even classically ignorant — it wasn’t like I could give him a class and a couple of tests and somehow that would fix things. We simply couldn’t communicate.

I’ll never forget what he said.

“I’m not sure I’m following you completely, but you see, I’m on top of the whole thing. I can ask any questions I like and get an answer”

My thoughts were: yes! But you neither know the correct questions, what the answers might imply, or how the answers to one question might lead to other questions!

Simply asking and answering questions is not enough. This guy had the magic power — whatever he asked, you can be sure that somebody was going to work as hard as they could to come up with an answer. And the project was still hosed up.

So in the interest of simplifying the discussion of how ignorant we all are in various ways, I propose the following scale:

Continue reading

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.