insights you can use |
|
|
"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm) Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers) Archives May 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 April 2006 March 2006 February 2006 January 2006 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 Contents (c) 2003-2006 Esther Derby I also publish a quarterly newsletter for people who manage in software organizations. If you'd like to receive the newsletter, drop me an email. It's on paper, so please include surface coordinates - name and full address.
Syndicate this site (XML)
Links |
Saturday, October 30, 2004
remember writing is hard work (code or prose)
Stephen Wilbers is a writing consultant. He wrote an column on effective writing in the local paper for many years and offered this advice on editing in his farewell column(published in the Minneapolis StarTribune 10/29/04):
Substitute few words and this advice fits for commenting on code, too. Good points to remember for pairing, technical reviews, and inspections. | Thursday, October 21, 2004
Talk, talk, talk
A couple of weeks ago, I attended a fund raiser and was seated next to a person I didn't know. I struck up a conversation, asked a few questions, and learned that the person next to me was a manager in a IT department. This week, I had lunch with another manager in a high-tech firm. Here's what struck me about these conversations: In both cases, the other person did the bulk of the talking. The first manager didn't ask any questions; the second manager asked one question. In both cases, it was hard to get a word in edgewise. Now, these were both social situations, and these two people may be very different at work. Then again, maybe they're not -- a leopard does not generally change his spots. If these managers do all the talking when the meet with the people on their teams, how do they know what team members are working on? How do they learn where team members are struggling, what their strengths are, and what they want to do with their careers? It's a puzzle. Managers, coaches, and technical leaders do need to talk -- to explain company and department goals, communicate important information and tie tasks to strategy. When they aren't doing that, managers need to ask questions and listen. The proportion should be somewhere around 30% talk and 70% listen. Tim Bacon posted a great set of questions for managers/coaches here. | Sunday, October 10, 2004
Notes on Retrospectives from my open session at Better Software Conference
A couple of weeks ago, at the Better Software Conference in San Jose, I lead an informal session on Retrospectives. I agreed to put the notes from our session up on my blog. This is a combination of the notes and my editorial comments :-) I use a framework for retrospectives, regardless of how long they are. My framework comes out of the ICA Focused Conversation method, which is based on empirical knowledge of how humans process information. Start with the data (Objective level) Then find out how people responded emotionally (Reflective level) Step back and look at the interplay of the data and responses to figure out the significance to the group (Interpretive level) Decide what to do (Decisional level) The short form is: What? – Gut? – So what? – Now what? No matter how long your retrospective is, or how much time your retrospective covers, going through each of these steps helps the group take a learning journey together. Choose exercises based the context of the group, the duration of the project/iteration and the time dedicated to the retrospective. In our session, we shared exercises we’ve used at each level. I’ve made some notes about adapting for an iteration retrospective at the bottom of the post. Objective: the data about the project
How are the data structures holding up? What were the major refactorings? Reflective: what life was like on this project I know, I know: some people aren’t comfortable talking about emotions ( I very seldom use the “F” word –Feelings— when I do retrospectives). And it’s critical to surface emotional responses – this is where we learn what was important to people. Reflective data tell me where people’s energy is and where there’s likely to be some juice for learning.
Interpretive: what do we make of the data so far. Insights and meaning to the group This is where most people start post project reviews. My experience is that you get much deeper insights – and more group support for those insights – when you start with the data and emotional responses. Some questions to ask at this level are: What did we do well that we want to continue? What would we do differently (knowing what we know now)? What did we learn? What still puzzles us? This was the best project because … (list the reasons). This was the worst project because … (list the reasons). What would we do exactly the same? What would we stop doing? What was really good? What are suggestions for improvement? Decisional: taking insights into action For a retrospective covering a longer period of time consider these strategies: For iteration retrospectives after an iteration of 1 week to 30 days try exercises that combine Objective and Reflective levels:
How well we are doing on core practices and How well we’d like to do next iteration
Interpretive What could we do smarter next time? What was really good? What are suggestions for improvement? Decisional What would we do exactly the same? What would we stop doing? Further resources: Project Retrospectives: A Handbook for Team Reviews. Norm Kerth Facilitators Guide to Participatory Decision Making. Sam Kaner et al. The Art of Focused Conversation. Brian Stanchfield, ed. Requirements by Collaboration. Ellen Gottesdiener Singing the Songs of Project Retrospectives in Cutter IT Journal (mining patterns in retros). Linda Rising and Esther Derby Note There's something funny going on with blogger, most of the tool bars are missing. I'll add links and pictures (fingers crossed) later. And spell check. | |