Sunday, June 27, 2010

What is the REAL problem?

I was reading a post by Rajesh Setty recently entitled "The problem is never the problem." It brought to mind the hardest recent interpersonal/team challenge I've had to deal with at work. The ostensible issue was around the security implementation in a new tool.

The real issue, as best I could determine, was that some of the people involved don't trust each other very much. We had to address the trust issue before we were able to deal with the technical issues.

Friday, June 18, 2010

Do you know who your real customer is?

I was reading Seth Godin today and found a post that spoke to my experiences running an agile team over the past few years.

His statement was, "If you are working hard to please the wrong people, you'll fail."

My team builds tools for internal use. I've struggled to figure out which customer I should be please. Should I be trying to please the testers who use are tools? Should I be trying to please the test managers? Should I be trying to please the dev managers? Should I be trying to please my boss (hard to go wrong there)?

At various points, I've emphasized one customer over the over. And it has changed over time. It's a source of tension for myself, and to a lesser extent for my team.

Which customer are you trying to please? Is it the same all the time, or does it change with the wind?

Friday, June 11, 2010

Decisions have costs; change is expensive

I've read some fascinating things lately about the energy cost (as measured by brain imaging) of making decisions, resisting temptation, and why that makes it hard for individuals to change their behavior.

I have vivid recollections of being exhausted by all the decisions I had to make setting up a new household. Some of the decisions had significant consequences--which house was I going to rent? Others were utterly trivial--which of the 16 different kinds of kitchen trash cans that they sell at Home Depot was I going to buy? And the funny thing was that make a bunch of inconsequential decisions was far more draining than making a couple of important ones. Apparently now there is science to back up my personal beliefs about that.

I'm not quite sure how to apply all this to Agile/Lean software development. I think the best match might be in the arena of Real Options. They conciously choose to delay decisions. Hopefully in additional to better information, they will have fully re-charged brains when the have to make the final choices.