April 25, 2012
Day two of trying to live the first principle of the 12 principles of the Agile Manifesto (“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”). So far so good. I spent much of the day co-training a class. It was a unique training because we asked the attendees to pick the topics that were most valuable to them, prioritize them, then taught the material. Finally we finished up with periodic retrospectives throughout the day. It seemed fairly obvious that this was a great example of asking the customer what they value, delivering the value, then checking to see if they thought it was really useful. After an entire rather exhausting day of this, it occurs to me that continuously providing value is actually a dialog (or perhaps an ongoing experiment) that works like this
- Ask what value you can provide
- Attempt to provide that value
- Ask the customer if they got the expected value
- Adjust and repeat
I think that value cycle lies at the heart of a lot of Agile processes. You see this in the sprint reviews and retrospectives on projects. It really is the PDCA cycle all over again. But speaking for myself, I think I’m going to have to modify my approach this week. Here’s a sample:
- Ask friend: How can I provide value
- Friend: Buy me a beer
- Beer provided
- Ask friend: So, how’s that beer?
- Friend: Excellent! Too warm! Too foamy! bitter, etc.
May 23, 2010
There was an article in the CACM recently that caught my attention entitled, “In Praise of Bad Programmers”
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:
- We don’t feel safe talking about our skills with each other
- The team felt some sort of judgement was being made by me
- 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.