Awareness

May 28, 2010

I was watching a presentation on risk today and I saw a symmetry between risks and impediments that I had never realized before. With both, the hard part is awareness. Once you’ve discovered a risk or impediment, half the battle is over. Seeing risks before they become impediments is hard. The discovery step is the part where I tend to fall down.

How many times has someone pointed out a risk or impediment and you find yourself palm slapping your face in embarrassment because you missed it (and it was SO obvious)?

When it comes to managing risks and impediments, seeing is often the hardest part.

Advertisements

Bad Programmers

May 23, 2010

There was an article in the CACM recently that caught my attention entitled, “In Praise of Bad Programmers”

Still here?

Apparently the provocative  title really sets off some fire alarms for people. I shared the article, which I personally thought was great, with a team and we discussed it together. I thought the whole conversation went really well and I thought it felt very productive. Afterward, I discovered that everyone in the room had apparently been thinking one thing: “He thinks I’m a bad programmer”. I’m not sure they recalled any of the conversation after reading the article. In fact, I’m quite sure they didn’t.

That reaction probably says a few things about us:

  1. We don’t feel safe talking about our skills with each other
  2. The team felt some sort of judgement was being made by me
  3. How you frame the conversation really does make a difference

Having done this sort of thing for a while, none of the above particularly shocks or surprises me. It’s just a reminder that some conversations with teams are harder than others. You don’t avoid them, but you need to be prepared to set the stage well before the conversation, make sure the team feels safe enough to deal with the conversation, and have a way to check in with them afterward to make sure your read on the conversation isn’t incorrect.

Oh, and if they’re still angry after all that, then it’s really their problem. I’m a coach not a therapist.


Risks, Impediments, & Lessons

May 21, 2010

I was talking to a group the other day about impediments. We were debating the temporal relationship between risks and impediments. We arrived at the following conclusion: Risks are potential threats to our projects that lie in the future. Once they manifest themselves in the present, we call them impediments. And once impediments are resolved and we move on, they become lessons. I’m intentionally not referring to them as “lessons learned” because I’m not sure we always learn from the experience.

So risks exist in the future, impediments exist in the present, and lessons exist in the past. I like the relationships and the terminology – it helps me to understand how to deal with these creatures.


What to do if you’re an A**hole

May 20, 2010

Bill Cosby has a great bit in one of his comedy routines where he talks about getting stoned. He’s having a conversation with a pot head that goes like this (I paraphrase from a rather unreliable memory here…),

“Why do you smoke Marijuana?”
“Dude, because it intensifies your personality!”
“What if you’re an asshole?”

Sometimes I feel like I’m having that conversation with some of the teams that I coach. It goes something like this,

“Why are you doing (name a particular practice)?”
“Because it makes us more agile!”
“What if you’re…”

Seriously folks, sometimes we need to be asked this question.


MBO RIP

May 19, 2010

I’ve worked with MBOs a.k.a. Management By Objectives on and off at a variety of places. Your manager (and presumably their manager) define a set of quantifiable (S.M.A.R.T.) objectives for you to hit in the coming quarter. Then you review them at the end of the quarter. Easy, right?

I must be treating these things wrong. I look at objectives and tend to evaluate them against my current priorities and the current priorities of the company/customer. These priorities tend to change from day to day. So, being an independent minded type, I tend to look at the list and edit as appropriate: this objective is relevant, this one isn’t, and so on. Then comes the review at the end of the quarter and the inevitable question, “Why didn’t you hit objective X?”

Now, admittedly, I might just suck. Or I might have judged a month(s) old objective to be low priority compared to more immediate needs. Now I suppose there are a variety of ways to handle this:

  1. Update and evaluate objectives with greater frequency
  2. Request/Update MBO’s over time
  3. Use another mechanism

You see, what I really want is a higher feedback mechanism that is a bit more relevant to my day to day work. Goals from 6 months ago, even 3 months ago, are seldom relevant. In customer terms, if I even wait as long as two weeks, I’ve very likely lost them already.

So what is the alternative? Honestly, to date in my professional life, short of outright neglect, I haven’t seen any decent ones. Maybe it’s one of those “sound of one hand clapping” Japanese koans: What’s the alternative to MBO’s?


A Few Resources On Agile Risk Management

May 18, 2010

I’ve been spending some time researching impediments and risk management – two topics that I believe are intimately related. I wanted to take a brief moment to share some of the great resources that I have found along the way:

Enjoy!


Teams vs. Work Groups

May 14, 2010

Not all teams should be Agile Teams. There are lots of legitimate groups or organizational structures that are not highly collaborative teams – and really don’t need to be. Case in point: work groups and project teams are different organizations that serve different purposes.

For example, for problems that are very uncertain like R&D projects (i.e. problems that often require extensive discovery and analysis – perhaps even invention), you are probably best served with a dedicated project team that has a loosely managed, tight-knit, highly collaborative organization. You are looking for a lot of creative input and problem solving. Those sorts of teams do well at that.

Contrast that with a project that is challenging, but doesn’t face a lot of complete unknowns. I’m thinking of things that are more operational in nature like system upgrades, hardware upgrades, system migration. The tasks involved are relatively well understood. That’s not to say there is no uncertainty or challenge (I know that’s not true!), but compared to creating a new product, things are relatively clear and straightforward. For these kinds of projects using a workgroup is probably best. You have clear leadership and accountability & you have people who are highly specialized (networking, sys eng, etc.). These people don’t necessarily need really high levels of collaboration. A workgroup is the right way to organize these people.

To me, the point is that you don’t want to get it backwards. Use the best tool for the job. If you have a relatively straightforward problem that doesn’t require high levels of innovation, then for God’s sake, don’t try and build an Agile team out of them! You’ll just irritate and confuse people by sending the message that their specialization isn’t valuable (been there, done that).

On the other hand, if you are looking for a lot of creativity, then using a workgroup is probably not the best way to get the innovative results you are looking for. The creative, collaborative types of people required to do this work will not respond well to a silo’d, top down, organization.

All too often what I see happen is one group pointing at the other and saying, “That’s crazy! How can they work that way? Why don’t they work like us?” The answer is that the groups are trying to solve different problems – each is using the organization that is most appropriate to the problem, and the context that they are working in. We need to understand and respect those differences.