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 |
Thursday, October 16, 2008
Improving Retrospectives
A friend forwarded this email to me: I just wanted to share a tip that has made a world of difference for our scrum. I read through this book about 4 months ago Woohoo! This is the highest praise an author can receive. (I don't think the activities are cheesy!) And, for your reading pleasure, two recent articles on retrospectives: Making Retrospective Changes Stick Eight Reasons Retrospectives Fail (And What You Can Do About Them) Labels: agile, Retrospectives | Saturday, April 28, 2007
Two more ways to gather data in retrospectives
If you've been holding iteration retrospectives for a while, you know that timelines get old after a while. But when team skip the data part, each person works from his own data (which other people may not know) and his own interpretations (which other people may not share). That means that the team is less likely to come up with actions that have broad support. So here are two more fairly quick ways to gather data for an iteration retrospective. Diana describes FRIM, an activity that looks at the frequency and impact of events, impediments and boons that affected the team during the iteration. Use this as input into analysis and to decide on experiments and changes for the next iteration. Jean Tabaka used a sailing metaphor to gather data at the Retrospective Facilitators Gathering retrospective. She asked us to identify events, interactions, etc that put wind in our sails. Then she asked us when we were in the doldrums, becalmed or held back by tides and current. We put up the "wind in the sails" stuff behind the boat, filling the sail and the doldrums stuff in front of the boat. The metaphor helped keep us out of habitual thinking and automatic categorization. And it was kind of fun. Labels: Retrospectives | Friday, April 20, 2007
Agile Retrospectives review
I just came across this nice review (written by Brad Appleton) of Agile Retrospectives: Making Good Teams Great Labels: Retrospectives | Friday, March 16, 2007
Face to Face Still Matters
There's been a discussion going on the the Retrospectives list on how to do distributed retrospectives and planning meetings. The assumption is that it's cost prohibitive to bring the group together. People always site cost as a barrier. It does cost money to bring people together face to face. There's lodging, airfare, time not spent on billable activities... and all these are easy to count. But what this thinking doesn't take into account are the costs of not having the team face to face for planning and retrospectives: Less collaboration, greater misunderstandings, continuation of us/them dynamics (be they ever so subtle there's always differences in access to power, information, and resources), miscommunication, etc. And there's lost opportunity to build relationships and trust which short-cuts many of those problems. But all those are hard to measure and quantify, and are almost always left out of the cost equation. People look at the costs without any of the benefits. Even when you have access to great technology for planning, retrospectives or other forms of collaboration, face to face is still superior for communication and collaboration in the moment and in building a foundation for future communication. Face to face is superior in building shared commitment and infusing a project with energy. Labels: communication, Retrospectives | Sunday, March 04, 2007
The Prime Directive, continued
Thursday, March 01, 2007
Appreciative Retrospectives
Diana Larsen has an article on Appreciatative Retrospectives posted on the AYE Conference site. Appreciative retrospectives build on strengths and look to create the circumstances that enabled people to be at thier best. (Diana will be one of the guest presenters for the 2007 AYE Conference.) Labels: Retrospectives | Saturday, February 10, 2007
Asking powerful questions
Diana Larsen responded to a question about using questions in a retrospective: Questions should lead the group through the group thinking framework of the retrospective. For example, for a continuous improvement goal: When I want to reflect on a very short period of work--a meeting, a pairing session, a workshop day--I use questions for the entire retrospetive, which may last only a few minutes. Those few minutes can make a big difference in increasing effectiveness, improving results, and maintaining working relationships. For more on using questions to help people think and learn together, check out The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace (ICA Series) Labels: Retrospectives | Friday, February 09, 2007
Prioritizing with dots in a retrospective
People come up with all sorts of ideas and potential changes in retrospectives--usually more than the team can digest in one retrospective or, for changes, more than they can do in the next iteration. I often use dot voting to help the team prioritize and choose what to work on. Usually, I give every one x number of dots (I use a highly unscientific algorithm to determine the number of dots each person receives), then ask people to vote on which they believe will make the biggest difference to the team. Last week I tried a variation on dot voting after the team had come up with a long list of issue to analyze (it was a release retrospective, so they were looking at a few months of work). Rather than use one color as I usually do, I used this scheme: First round: Each person had 4 green dots to mark the issues that would make the biggest difference on the next release. Second round: Each person had 4 orange dots to mark the issues where the people in the room had influence or control. Third round: Each person had 4 yellow dots where to mark where he or she personally had interest and energy to work on an issue. At the end it was clear that there were issues that would make a big difference, but no on had energy to work on them. And it was clear where people felt they could actually make a difference. (Since this was a release retrospective, many of the issues crossed organizational boundaries and couldn't be solved within the team.) Faced with a long list of issues, three-color dot voting worked to winnow the list down to a manageable number of items for the team to tackle. Labels: Retrospectives | |