Archive for the ‘Communication’ Category

• Best Links of the Week – Dec 18th 2009

  Date: 2009.12.18 | Category: Agile, Coaching, Communication, Links of the Week, Product Owner, Scrum, ScrumMaster, Team | Response: 0

  Here are links to the best of the blogs for the week of Dec 18th 2009.

  1. A ScrumMaster’s Checklist – a comprehensive checklist from Michael James offering four areas a ScrumMaster should pay attention when coaching: the Team, the Product Owner, the organization and the technical practices.
  2. Agile Leadership: Methodology Ain’t Enough – the Hacker Chick brings us a blog article about the management beliefs and behaviors which support the growth of Agile teams.
  3. When Should QA be Engaged in an Iteration? – Hiren Doshi PMP discusses the role of QA on a Scrum team and tackles the myth that QA folks “have nothing to do until the end of a Sprint”.
  4. Five Reasons to Hire a Coach for Agile Teams – Ester Derby talks about five pitfalls of DIY (Do-It-Yourself) Agile coaching.
  5. Scrum Doesn’t Do Anything – explanation of how Scrum only comes to life when people are added to the framework and the importance of the following the rules by Tobias Mayer.
  6. Practical Agility: On Estimation – Dave Rooney describes the Agile estimation lessons he learned while undergoing a recent move.
  7. Overcoming Technical Challenges for Adopting Agile Methods in the Enterprise – Vijay Narayanan over at InfoQ discusses the importance of having an development environment which supports your Agile process.
  8. Flipping Out – short description of how Flickr uses Continuous Integration and a Single Code Base to add features to their application without branching.

  There was a lot of great stuff to read this week, unfortunately I can only go with eight or so entries.  Cya next week!!

• Developing High-Performing\Agile Teams Review

  Date: 2009.11.16 | Category: Agile, Collaboration, Communication, Team | Response: 0

  Last week, I completed the my Agile Team Training class.  I had a really good turnout (~20) and it was a lot of fun!  While reading the class reviews, a common refrains from the participants were they were surprised at how engaged they were in the simulation and how committed they were to the outcomes.  One participant even wrote these kind words:

  “I was skeptical that it [SIMSOC] would provide any valuable lessons.  I was pleasantly surprised to observe behavior developed that mirrored my professional experience closely enough to be instructive.  I joined in more fully than I anticipated.”

  For those of you that might be curious on what we actually did for the day, here are some photos from the event.

  

  In my experience, having the right venue goes a long way to setting up a good learning experience so I was pleased to have this large space for the class.  This is the great space we had for the event, right on Mission Bay with plenty of natural light, windows looking outside and good food to eat.

   

   

   

  During the simulation participants are divided into different regions.  For this game we had three regions: Green, Yellow and Red.  In this photo, the Red Region trying to understand the SIMSOC rules and figure out a game strategy.  The members of this region quickly coalesced around a common goal, but had some initial difficulties convincing others.  Unfortunately, their riot in the first session was unreported by the head of the mass media (MASMED) and did not have the intended effect of getting the rest of society to pay attention to their concerns.

  While SIMSOC looks like people are just sitting around in chairs all day, the game is much more dynamic than the photos depict.  This a member from the Yellow Region visiting the Green Region to discuss game strategy. Somewhere around the third session, there was freedom of movement and people began meeting face-to-face to discuss issues and share ideas.  Very soon after that, the Red Region proposed a compelling national program to organize the society around and the game came to close during the sixth session.

  Here are some the things the participants learned about teamwork during the class:

  “Maintain the big picture to maximize individual contributions.”

  “We were all seeking cohesiveness and cooperation.”

  “Common goals across teams had an enormous impact of behaviors.”

  “Finding common goals is really needed.”

  “Not reaching out and trusting teams would have made that [reaching our common goal] impossible.”

  “I was pleasantly surprised how cooperative we became with each other.”

  “People do not start out in trust.”

  “Working with different teams [can be challenging] because they have different local goals.”

  “How very important trust is to building high-performing teams.”

  “Define the common goal makes you more efficient and motivates the team.”

  “Trust others on the team, they have best interest in mind.”

  It would say it was a very satisfying, compelling and educational day for everyone. I look forward to the next time I host this game.

• Developing High-Performing Teams on Nov 12th

  Date: 2009.10.18 | Category: Agile, Communication, Team, Training | Response: 0

  Does this sound like your team?

  • Boring stand-up meetings that never end.
  • You need ten people in the room to make a decision.
  • Planning meetings are just about handing out work assignments.
  • Everyone has a different reason for why the current release is important.
  • Difficulty expressing your ideas at the whiteboard or in front of the computer.
  • An upset stomach just thinking about having to work with the “difficult” person.
  • Just writing the code people tell you to write and not contributing to the design.
  • Rather be at an all-hands meeting than a code review.
  • Blind to what other teams in your company are doing.
  • Having nothing to say at retrospectives.

  If your team feels listless and like more of the same but with all these new “Agile” labels attached, then perhaps you could use a refresher of some essential interpersonal skills to improve your daily interactions with your peers and management.

  In this one-day course, we will reawaken the parts of your brain which govern communication, observation, collaboration, conflict resolution, teamwork, decision making, facilitation, critical thinking and listening.  Through the use of simulations, we will strengthen these skills, give you a chance to try out a few new ones and prepare you to become a contributing member of a collaborative, self-organizing team.  Oh, did I mention it is going to be a lot of fun?

  Sign up today!

  Your day will start off with some basic introductory exercises and explanations and then we begin the first session of the simulation, named SIMSOC.  SIMSOC (pronounced sim-sock) can be thought of as a live-action version of “The Sims” combined with the cutthroat drama of “Survivor”.  The goal of each session is to remain “alive” and further your personal goals.  Some patterns of behavior will be more successful than others and it is up to you to discover the right strategy so you remain alive by the close of the day.  At the conclusion, you will be able to identify the forces at work in the simulation, how they are relevant to the workplace, the key interpersonal skills needed for a collaborative, self-organizing team and what you can do to make your Team better.

  Your facilitator will be Carlton Nettleton, President of Look Forward Consulting (www.lookforwardconsulting.com) .  Carlton has been coaching individuals and teams on how to implement Agile principles and practices and is passionate about helping your business and team succeed. He has nearly ten years of experience working with software products and services in both a technical and business capacity from small start-ups to FDA regulated medical products.

  Sign up today!

• Exciting New Agile Team Training Available

  Date: 2009.10.12 | Category: Agile, Collaboration, Communication, Team, Training | Response: 0

  

  On November 12th, I will be facilitating a first of its kind training for Agile Team members.   Through the use of simulation, I will help the participants reawaken dormant skills such as how to communicate with your peers, give (and receive) feedback, conflict resolution, decision making and other key soft skills each Team member needs to function in a fast-moving Agile Team.  At the completion of this one-day course, I hope to give participants a better appreciation of what skills are needed to communicate effectively, solve problems collaboratively, identify common communication patterns (and anti-patterns) and the application in the participant’s workplace.  Also, this is going to be a lot of fun.

  In my work with Agile teams, I have observed that the greatest improvements of Team come when teaching the Team members soft skills.  These soft skills are more valuable because they allow Team members to connect with each other as individuals and foster true ownership of the work.  Too often people come to work on auto-pilot, go through the motions of their career and go home profoundly dissatisfied.  In my opinion, much of this can be traced back to a poor work environment which encourages isolation from the people we work with and the work we do.

  With the Agile community’s strong emphasis on “individuals and interactions”, you would think as a community we would have some trainings that help people improve their soft skills, yet that is not the case.   Over the past couple of years, we have seen an explosion of training provided for leaders of Agile teams – the Certified ScrumMaster program is an excellent example – or we teach Team members technical skills – the classic two-day TDD class.  These are all really good things to teach people and they are useful to know.  They form a solid foundation for technical excellence and help create and sustain the Team environment.  However, they don’t teach people how to work together as a Team.

  The simulation, named SIMSOC*, will begin the conversation of “How are we going to work together?  How are we going to make this time we spend together more valuable?”.  SIMSOC (pronounced sim-sock) can be thought of as a live-action version of “The Sims” combined with the cutthroat drama of “Survivor”.  The goal of each session is to remain “alive” and further your personal goals.  Some patterns of behavior will be more successful than others and it will be up to the participants to discover the the right strategy to remain alive by the end of the day.  No two strategies will be the same and there are no pre-planned outcomes.  Apart from a few basic “natural laws’, the participants are free to do as they choose, which creates fertile opportunities for cooperation and conflict.  By the end of the day, I hope to arm the participants with an alert mind, some valuable experiences on what types of communication and collaboration strategies which work and curiosity about the next steps they need to take to build and grow that awesome team that makes you excited to get up and go to work each day.

  * SIMSOC was created by noted sociologist Dr. William Gamson to examine the role of leadership organization, power and social change and has been in use for over 40 years in both the business and educational world.

  
  

• Dog Psychics for Your Agile Team

  Date: 2009.09.21 | Category: Agile, Communication, Conferences, Transitions | Response: 0

  I was having a really interesting conversation with Susan Elliot Sim at Agile Open SoCal.  I was asking her why is it so difficult to get peer-reviewed articles published on Agile.  She responded by telling me this story, with the instruction to identify the emotions you feel when hearing\reading the story:

  “Suppose I told you I was going to tell you that in order to understand what is wrong with your dog – he’s been limping and you think something is wrong with his leg – we are going to take him to a dog psychic in Nevada and this dog psychic is extremely good, highly recommended and gets great results and you take your dog there.

  You ask the dog psychic, ‘Can you ask the dog if his leg hurts?’.

  The dog psychic talks to your dog and turns to you to say – channeling your dog, ‘Well…thank you for asking about my leg, but that is not what’s bothering me.  It’s my back.  It hurts a lot when I jump up and down off the bed, especially on cold mornings, so could you please get me a ramp to make that easier?’

  ‘Also, I really like it when you come home to play with me during the day and I remember that time we went to the park and chased the birds in the pond, so let’s do more of that.’

  ‘Oh, and I really don’t like that dog food we have been eating all these years.  Yes, I know that I eat it all up and I probably shouldn’t have, but I didn’t want to hurt your feelings cause you do so many nice things for me.  However, since we are finally having a conversation after all these years, I thought you should know.’

  And you respond to your dog, ‘Oh my God!  I never knew you felt this way about so many things.  When we get home, I am going to make all these changes.  I am so glad I spoke with this dog psychic!’”

  So how did you feel after hearing this story?  It is a bit farfetched isn’t it?

  According to Susan, this is experience is very similar to what academic researchers think about Agile – it is nothing more than dog psychics.  That you really have to believe in dog psychics in order to get any value out of them.  In addition, the people who believe dog psychics sound a bit evangelical in talking about how great dog psychics are and yet there is no (scientific) evidence on the mechanics of dog psychics.  I thought this anecdote is a really good concept to keep in mind when we encounter skeptical people; sometimes we just sound loony.

• Agile 2009: My Greatest Coaching Mistakes 2000-2009

  Date: 2009.08.25 | Category: Agile, Coaching, Communication, Conferences | Response: 0

  Stopped in today to J.B. Rainsberger’s interesting discussion about his big misses in the last nine or so years.  He used an interesting format of people sitting in a circle instead of sitting around conference room tables.  Here is a list of the interesting ideas I jotted down while listening to the conversation.

  • Practices like pair programming, timeboxes, iterations, user stories, release planning, etc. are neither good nor bad.  They are either appropriate for the environment or not.
  • One resistant person is more than enough to bring down an Agile team.  It is better to have people who have a similar style work together and form your Agile team around them.
  • If you are going to do something a stakeholder does not expect – like deliver early or spend time fixing broken tests – be sure to give them advance warning.  In low trust environments, this can be a good first step in building trust.
  • If the response of someone is not what you expected, you need to spend time understanding the significance of what you said and how it was interpreted by the listener.  Consider the worst possible interpretation of your actions to reduce the number of communication surprises.
  • Use smaller user stories when a Team is beginning with Agile to build a sense of accomplishment with the Team.  As they become more experienced and skilled, use bigger stories.
  • Training is about increasing your capability and improving your skills.  Coaching is about reducing interference and improving the signal-to-noise ratio.
  • Coaching is about giving people a new way of working together.  All the Agile tools and practices are worthless if people cannot talk with each other.

• Speaking @ XPSD on Sept 3rd

  Date: 2009.08.14 | Category: Agile, Agile SD, Coaching, Collaboration, Communication, Presentations, Scrum, Team | Response: 0

  Just wanted to let people know that I will be the speaker at the XPSD meeting in September.  I will be talking about my experiences coaching Scrum teams in China and my insights on what essential skills a ScrumMaster needs to be successful.

  Update: this was postponed until Oct 1st due to my knee surgery.  The topic will be the same – CEN 09/03/2009

• Why I Encourage Small Teams

  Date: 2009.05.27 | Category: Agile, Collaboration, Communication, Extreme Programming, Scrum, Team | Response: 0

  Yesterday, I was having a conversation with a colleague about an issue she was struggling with.  She was describing to me how management sometimes has the notion that if we just double the project, say from 10 people to 20 people, we will get double the output.  In the classic Mythical Man Month by Fred Brooks, he made the bold statement that resources do no combine linearly.  Brooks documented his observation with a formula that describes, in part, how the exponential increase in communication pathways as the team size grows, is responsible for his observation.

   

       Communication pathways = [n * (n-1)]/2

  

   

  In my colleague’s example, the number of  communication pathways increase non-linearly from 45 to 190 after the team doubles in size.  Or if you want percentages, changing the team size from 10 to 20 is a 400% increase in communication overhead.  Wow!  I would call that communication overload.

  As a response to this observation, Agile teams and projects almost always try to keep the team size around 8 plus or minus 2.  When team sizes exceed this, it is impossible for people to maintain a network of communication links with all the participants.  

  OK, mister big shot consultant, how do you deal with big teams of, say, let’s pick a number, a hundred people? My first answer would be to subdivide the hundred people into smaller units each with 6 to 10 people, or create about about 10 to 12 teams.  Of course, now you have the added difficulty of coordinating that many teams, but no one said management was easy.  However, would you rather coordinate 55 communication pathways between 11 teams or 4950 communication pathways between a 100 individuals?

• 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?

• 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.