Archive for April, 2009

• Saying Good-bye

  Date: 2009.04.28 | Category: Agile, Coaching, Collaboration, Communication, Team | Response: 0

  For certain two things will always happen on any job  - an opportunity to say “Hello” and a time to say “Good-bye”.  The “Hello” part usually happens in the initial meet-and-greet or interview and is your opportunity to make a first impression.  People know how to do this and are often showing their best behavior.  The good-bye is something that is often neglected or not handled well.  In most cases, people do not know what to do and in many cases teams are dissolved without any closure – people are moved on without any consideration of the real connections they have made with each other and the work they produced.

  Everyone is familiar with Bruce Tuckman’s famous Norming-Forming-Storming-Performing model from the 1960′s, but I doubt many people realize he added a final phase called Adjourning ten years later.  I want to describe a technique I use to help people through the Adjourning phase and allow people to reflect on their experience on a team share what valuable experiences they want to take forward with them.  This exercise is combination of the Locate Strengths and Identify Themes exercises from from Agile Retrospectives by Esther Derby and Diana Larsen.

   

  1. Have the participants break up into pairs and select who will be interviewer and who will be interviewed.  The interviewer should ask four questions (see below) to their partner and only the interview questions.  As the interviewer, one should give their partner their full attention and take notes looking for quotes and key stories to share.  Remember, this is not a conversation, but an interview.  Only ask questions to get more detail, not to share your experience.
  2. After about 15 minutes, partners switch roles.  Conduct another round of interviews for 15 minutes.
  3. When everyone has been interviewed ask each interviewer to report out the answers to the questions to the entire group, making sure to highlight specific stories and examples.  Individuals are not allowed to report their own answers to the questions.
  4. As a group, discuss the common elements and themes in all the interviews.  Write these items on post-it notes (one per post-it note) and place on the meeting wall or whiteboard.  
  5. When all the common themes and elements have been gathered, group the similar post-it notes together.  Ask the group to give names to the groupings.

   

  Here are a few things I have learned that make the experience more meaningful and enjoyable for the participants.

   

  • Provide food and beverages – the obligatory coffee and donuts work, but bringing fresh orange juice and fresh fruit makes the event seem special.
  • Ask for specific anecdotes and the names of individuals who participated – the more specific the stories, the more real they seem and more opportunities for people to be recognized.
  • Adjourn for a meal afterward – take advantage of our natural desire to share a meal with others as a way to show our respect for their contribution and value.

   

  Finally, the interview questions.  Feel free to add your own variations or additional questions

  1. What is it that attracted you to this profession? This company?
  2. On every team, there are high points when things just click.  Think back to when we started working together as a team [PAUSE].  Tell me a story about one of your highlight moments.
  3. What were the circumstances that surrounded that moment?  Who else contributed to that moment for you?
  4. What are three things you want to take forward from our experiences together?

• Happy Anniversary Blog!

  Date: 2009.04.22 | Category: Personal | Response: 0

  Turns out I started this blog on this day one year ago today which also happens to be Earth Day, too!  Just wanted to take a moment to say thanks to my readers and I look forward keeping in touch in the next year.  

  

• Multi-team Retrospectives: Valuable or No?

  Date: 2009.04.09 | Category: Agile, Coaching, Communication | Response: 0

  The folks at Integrum, a rails consulting company, produced a short podcast talking about their challenges running single retrospectives with multiple teams.  One of the comments from early in the podcast was when you have many teams in single retrospective, the participants tend to speak in generalities and skip the details of what happened in their team.  Presumably because that information would not be of interest to the other folks not on their teams.

  I have facilitated both single team and multi-team retrospectives and my experiences match the ones described by the people at Integrum.  I generally prefer to run single team retrospectives, but there are times when a multi-team retrospectives.  In my experience, these are two reasons why I might want to do multi-team retrospectives:

  1. Cross-cutting issues are more important:  when the main issues facing the teams are organizational, run multi-team retrospectives to highlight common obstacles and to look for root causes to these impediments.  In many cases the issues teams want to talk about in a single team retrospective are often times symptoms of these organizational roadblocks.   
  2. Resistance from participants: normally when you ask people to reflect on the way they work and look for ways to improve, they are pretty interested to talk.  The times I have seen resistance to retrospectives are when people have participated in forums, e.g. post mortums or after-action reviews, that are so far removed from the events people are discussing, there is no real impact to their work.  Everyone just knows the information from the session will go in some file, be forgotten and never acted upon.  When I encounter this type of resistance, I use the multi-team retrospective as a way to re-build trust and confidence in the retrospective process.

• People Over Process

  Date: 2009.04.06 | Category: Agile, Transitions | Response: 0

  Max Pool has a great post today on his site highlighting the importance of people in making an organization succeed.  This is one of the reason why this statement leads the Agile Manifesto (it is interesting that I keep coming back to this concept – CEN).

  “Individuals and interactions over process and tools”

  I just want to amplify what Max says – when you act at work to make things better, you choose to improve your organization.  When all you do is sit at your desk and complain to your peers, you choose the status quo.  At some point we have to ask ourselves if we continue to do nothing against the status quo, when do we become enablers of it?

• More People Down on Scrum Certification

  Date: 2009.04.01 | Category: Agile, Scrum | Response: 0

  Guess since it is April Fool’s Day, people feel like it is time to pile on the Scrum certification.  Both Jim Shore and Scott Ambler (in the form of a joke certification) have added to the fray.  I am not so sure why people get worked up about certifications – the value of a certifications lies in what the recipient puts into it.  That is true for something like a CSM or an undergraduate degree.

  I suspect one of the reasons why some people get down on Scrum for their certification programs is because they are successful and lucrative.  If it were not the case, I believe people would not care that much.  I would even go as far to say that the Scrum Alliance has done more to promote Agile than any organization out there.  We should be happy to have this problem, not complain about it.  If it were not for the vast number of newly minted CSM, I doubt that Agile would have pushed across the chasm (note – I guess I am walking away a bit from an earlier post where I said Agile has NOT crossed the chasm).  At least the Scrum Alliance tried to fulfill a need and attempt to stake out some territory in this space before all the vultures swooped in. AFAIK, they trying to inspect-and-adapt their programs and have put in the CST gatekeeper as an attempt to control the quality of their certifications.

  I guess what bothers me the most about these posts is it sounds like people are lumping the Scrum Alliance with the vultures. I don’t believe they have the same motivation (might be having the same effect, but that could be debatable).  I have not seen any actions from the Scrum Alliance which shows this to be the case.  If anyone is to blame for this whole thing it would be Jeff & Ken for coming up with the term “ScrumMaster”.  How do they expect us to say with a straight face we are a “ScrumMaster”?