Results tagged “Coaching”

While on vacation, I pinged a few friends of mine to ask them if they'd give me a LinkedIn recommendation. I'm hearing that people are using LinkedIn as a replacement for resumes, so it seemed like a good idea.

Imagine my surprise when one of my "friends" declined!

Bob -- let's call him that -- is a nice enough guy. Very enthusiastic about software methodology X. Bob was a rabble-rousing advocate of X at my last big client. Bob and I didn't see eye-to-eye -- this isn't my first rodeo and there are lots of solutions to complex problems -- but we got along okay. Sometimes Bob would stand up and espouse X at length, telling us all the world would be better if we all used it. At these times I usually mildly pointed out to Bob that changing the entire world might be a little ambitious for a 12-person team. Sometimes I had poorly performing teams that I was unable to help improve, but Bob never said anything about it. As far as I knew, Bob and I were friends who just had different opinions about software development. After all, we were on an agile team and experts in agile methodologies: if Bob had problems with me or my performance, it shouldn't be a mystery to either one of us.

That was until Bob got elected to chairman of the board of the X Alliance. I'm not sure if that did it for him, but something obviously got him into a snit. The reply I got was "...I'm inclined to decline your request, Daniel. If you care to visit more, call me..."

WTF?

So now I'm on my vacation wondering what the heck is wrong with Bob. But I guess that will have to wait. I honestly don't know what interests me more, why Bob doesn't want to recommend me or why I thought Bob would recommend me when he won't. I think the second question has a lot more potential than the first!

But it got me thinking of the folks I've met who don't like me very much. I've been doing this twenty years. There aren't a lot -- most people could care less about me one way or the other -- but some folks actively dislike me. For each of these folks I've thought long and hard about what our problem was together. Maybe you can get something out of my mistakes.

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.

In theory, practice and theory are the same. In practice they aren't. -- Yogi Berra

There are two kinds of teams and developers in the world: those that are heavily into knowledge and those that are heavily into practice. Both lead to poor performance.

The first kind has read all of the books. Perhaps they've attended some seminars or conferences. They're excited about various ideas they've heard and want to try them out. Discussions about how practical something might be are regarded as counter-productive, or foot-dragging. These teams are knowledge-heavy. Outsiders really admire how smart these people are, but secretly are afraid of letting them around sharp objects, i.e., they don't really trust them.

The second kind isn't much into book-reading. They're just there to execute -- to deliver something. They're focused on the end-results and getting there as quickly as possible. Discussions around new ways of doing things are regarded as frivolous. These teams are practice-heavy. Outsiders are really excited over all the results these people get, but secretly are afraid that the mess and compromises that are being made that are going to cause a lot of problems later, i.e., they don't really trust them.

So -- how to balance knowledge and practice? I apply these principles in order:

When coaching for agile project management, I have led a lot of teams estimating and delivering technology. in addition, I've been asked by several clients to advise them on how to estimate a project. Plus as a hands-on guy, I've had to create estimates and live (or die) by them in real-world teams. Estimation seems like magic to some people. How can you know how big the project is before you even start?

As part of this work, I get asked the same questions over and over again. Here they are, with my answers:

A while back I started on an Agile Coach Code of Conduct. I noticed that after coaching for a while I started to forget basic principles that should be part of every coaching engagement.

So I put this list together to help me (and others) remember what coaching is all about.

Like everything in agile, it's an ideal, not something you can ever perfectly do.

"Well nobody asked you your opinion," the coach glared at me, "so you can sit down and shut up. And if you can't sit down and shut up, you can leave the room."

I could feel everyone's eyes on me for just a second. Then they all found something else interesting to stare at. I glanced at my project manager. She was playing with her pen, her eyes were bug-eyed and her eyebrows raised. She looked as if she expected elephants to fly out from her ears at any moment.

Welcome to my Tuesday morning.

Talk about being completely blindsided -- I had no idea this was coming.

The CrossFire chart allows teams to measure budgeted performance
against traditional agile metrics

Here's a little graph I picked up last week. I don't think anybody else has published this, so I'm calling it a "CrossFire". It was created by a team who had a lot of matrixed team members and wanted to track budgeted performance (the amount of time people reported in the official time-tracking system) with agile performance (iteration burn-down).

Turns out you can find out some very interesting things from these CrossFire graphs.

I've been thinking a lot about agile, whether I want to or not lately.

As an agile coach, my "day" job is training and helping teams get started using agile techniques. Many times these teams come from waterfall backgrounds with lots of paperwork and heavy process. So it's no wonder that agile has taken off in certain spots. When you're taking 2 years to do the same thing other teams can do in 4 months, agile looks like a ray of hope.

Process is all about risk: you do something because you're afraid by not doing it something worse will happen. Everybody has process: it's however your team works -- that's your process.

The problem comes when the entire organization feels like that every team should worry about the same thing. Then we get formalized process, which basically means other people telling you what you should be worried about. (and then making you do stuff that they think will reduce the risk)