Archive for the ‘Collaboration’ Category

• Agile 2009: Debugging Pair Programming & Impact of Gender

  Date: 2009.08.25 | Category: Agile, Collaboration, Conferences, Extreme Programming, Pair Programming | Response: 0

  Mat Wayne ran an interesting session about overcoming resistance to pair programming organized around personas.  On each table there was a description of a different persona and some ideas on why that persona might resist pair programming.  Our job was to discuss in groups why the persona was resisting pair programming and some ideas on how to overcome the resistance.

  I tried to make the case that gender differences was an important consideration in resistance to pair programming.  In a room full of (mostly) men, it was hard to be taken seriously, especially after the few women in the room were pretty vocal opposing my viewpoint.  However, I think the people in that room\conference self-selected to be interesting in pair programming.  The sample was biased toward ignoring the impact of gender on pair programming.  Remember, the purpose of the session was to help people who do not want to do pair programming to become more interested in it.

  After talking with some friends, I think there are more gender dynamics at play when men and women work together programming and some of these might explain why women are not interested in (pair) programming.

  • Pair programming requires two people to work in close proximity.  Some women might not feel comfortable sitting less than two feet from a male co-worker for most of the day or not be interested in the unwanted attention from men.
  • Male programmers have a really strong geek hierarchy thing going on.  The more uber-geek you are, the more status you have and the bigger your voice on the Team.
  • Get more than three men together and you begin to create a “locker room culture” that is a normal part of male bonding.  This is often characterized by seemingly harsh, personal put downs of your ideas by your peers.

  I don’t think any one of these things is a definitive cause, but I do believe they add up and discourage women from participating on programming teams.  As coaches, we need to be mindful of gender and provide a safe environment.  It is not that women need extra help, just men need to be reminded to act like adults.

• Agile 2009: Distributed Agile Development

  Date: 2009.08.24 | Category: Agile, Coaching, Collaboration, Conferences, Team | Response: 0

  After searching and searching for this ballroom (this conference center is a bit of a maze), I finally found this session being held by some folks from Microsoft, Ade Miller.  They were talking mostly about their observations of working with teams in South America, but did talk about working with Teams in Asia.  This session was attractive to me because I was looking to see what other experiences people were having with distributed Teams and if my recent recommendations were on the right track.

  Here is a list of ideas I jotted down while listening:

  • Get good tooling to minimize the difference being in the Team Room and out of the Team Room.
  • Select tools that are adaptive to the Team’s processes and ways of working together.
  • Plan to travel; use the lower rate of the offsite people to offset the travel costs.
  • Always have one guy from overseas in the main office.
  • There will always be people difficult to synch up with due to time zone differences, so nominate a representative in the Team Room to advocate for them.
  • Avoid component-based architecture and thinking to prevent local optimizations.
  • Make sure every Team has a coach to remind them of the underlying principles and values of Agile.
  • Have a list of books that people should read when onboarding.

  As it turns out, I was mostly in the ballpark.

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

• Great Podcast on Retrospectives

  Date: 2009.03.16 | Category: Agile, Collaboration, Communication, Retrospectives | Response: 0

  Wow!  Great information from Linda Rising on how to conduct a retrospective, the exercises she uses and the value of the retrospectives.  Check out this podcast; it is about 90 minutes, but completely worth it.

• Prioritization with Pugh

  Date: 2009.03.03 | Category: Collaboration, Design Excellence, Design for Six Sigma, Lean, Product Owner, Pugh Concept Selection | Response: 0

  I came across a recent blog entry where Brandon Carlson was discussing one technique he used to speed up the prioritization of Product Backlog items with Product Owners.  He describes the scene like this:

  “It was late July and I was sitting through yet another agonizing prioritization meeting. The sounds of debating product stakeholders filled the air, each weighing in on his or her pet feature’s relative merit, desperately trying to inch it toward the beginning of the development queue.”

  Reading further along in the article, you learn they solved this problem by scoring each feature (on a scale of 0 to 3) how well each feature met twenty-two key attributes from the perspective of both the business and the system.  The features that scored the highest were moved to the top of the prioritization queue and the ones which scored the lowest moved to the bottom.  What broke the logjam for them was having the ability to talk about the features using data and moving away from advocacy.

  What Brandon described is essentially Pugh Concept Selection – a Design for Six Sigma tool.  Bernie Thompson gives an excellent description on his blog of using a more “pure” application of Pugh to select between different cell phone plans.  Pugh was originally used to rank various design alternatives during Analyze, but again the Lean world has yet another mature tool that the Agile community can apply in our lightweight environments.

• QFD & Agile Process Roll Out

  Date: 2009.01.06 | Category: Agile, Agile SD, Collaboration, Design for Six Sigma, Presentations, Scorecards, Transitions, Voice of the Customer | Response: 0

  I have been wanting to blog on my last presentation at XPSD for a while, but have been so busy with the Holiday Season – so here are my thoughts on how to use the Design for Six Sigma (DfSS) quality function deployment (QFD) tool to gather the Voice of the Customer data around creating a customized Agile process for your organization based on the issues your organization faces and deriving meaningful measures which will allow your group to monitor and track the roll out.

  Step 1 - The first thing you need to do is collect the Voice of the Customer (VOC) about what you want your new process to do.  So, to look forward, we need to look back for a little bit.  Gather all the people who will be participating in the process change and ask them some variation on these two questions:

  1. What is your biggest pain point with the current process?
  2. What is the number one thing you would change about the current process?

  To gather the VOC data, I used the Wall of Wonder - allow people to work in small groups quietly for a few minutes, capture each comment on a Post-it note and hang them up on the Wall.

  Step 2 -The next step is to group the VOC data into logical categories using an affinity diagram.  I find the best way to do this is ask the participants to get out of their seats and rearrange the items on the Wall of Wonder until everyone is satisfied with the groupings.  In DfSS parlance, each of these categories is called a user need.  A user need is simply trait the new development process must satisfy in order to be considered successful.

  After we have labeled all the groupings, I ask the participants to force rank the user needs with the most important traits of the new process receiving the highest ranking.  In my example, addressing issues surrounding requirements and adequate resources were the highest priority for the new process.  You can also rank the user needs from 1 to 5 and allow some user needs to have equal wights.

  Step 3 - Once we have ranked user needs, we enter them into the rows of the QFD chart (Room 1 in DfSS language).  Either as a big group or smaller work teams, I then ask the participants to think about what sorts of requirements the new process must have in order to meet our user needs.  This is the point where someone (usually an engineer) gives a solution to the problem and I need to remind the participants that requirements are solution agnostic.  The requirements are then listed as columns along the top of the QFD chart (Room 2).  Requirements are allowed to fulfill more than one user need, but more on that in Step 4.

  Step 4 - OK, we have our user needs which define the characteristics that our new process must provide our organization and we have requirements that fulfill those user needs.  How do we make sense of the requirements and find out which requirements are critical to the success of our new development process?  Or put in the language of DfSS, what requirements are critical-to-quality (CTQ)?

  To find the CTQ, we first need to complete the interrelation matrix between the user needs and the requirements (Room 3).  For each requirement we need to identify the degree they are related to each user need using the scale of 9 (strongly related), 3 (moderately related), 1 (weakly related) or 0 (not related).  It is best not to spend too much time discussing each of the relationships since they are a lot of boxes to fill in, so a tool like Planning Poker helps move things along.

  Step 5 - Next we rank the requirements by multiplying the interrelatedness score of each requirement with the user need ranking in each row and sum each requirement-user need product into a total at the foot of the column.  This example shows how we arrived at the total of 162 for the “on-time delivery” requirement:

    Total = [3 x 8] + [9 x 7] + [3 x 6] + [9 x 5] + [0 x 4] + [3 x 3] + [0 x 2] + [1 x 3]
          = 24 + 63 + 18 + 45 + 0 + 9 + 0 + 3
          = 162

  Repeat for each column to rank the requirements from high to low.  The requirements with the highest score are the CTQ and are the MOSTimportant requirements our process must fulfill in order for the roll out to be a success.  Or put another way, these requirements provide us the most leverage on making a successful product for our customers.  If we cannot meet these requirements, it does not matter what process we use – we have a very low probability of making a product that will satisfy our customers.

  Step 6 - The final step is to derive our measures that allow us to monitor our CTQ with a scorecard.  In order for measures to be meaningful, they need to tie to something that the organization or customer (this even better) cares about.  It is time well spent to create the measures as a group and reach consensus that the measures are indeed meaningful and what the organization chooses to evaluate itself against, otherwise people will game the scorecards and there will be no accountability.  I find it useful to have about 50% of the measures tied to the customer so they process is grounded in the market.  Too much process transformation is done for the sake of the organization and the improving the customer or the bottom line is often an afterthought.

  So where’s the beef?  Really – the word Agile has not even been mentioned up until this point.  Actually, that is the point.  A lot of Agile transitions start out backwards – we want to do Scrum\XP\whatever, so let’s find our problem.  QFD says let us examine and analyze our problem, find out what is most important for US and monitor those items with a scorecard to know if we are on track or not.  This approach is superior because once we have the QFD and the scorecard, we can then begin to think about what Agile process and\or practices that allow us to meet our CTQ and enhance our measures.

  Maybe for your organization, you have a CTQ around requirements, then perhaps you can try our user stories and see if they move your metrics?  Perhaps you have another CTQ around quality, then maybe having cross-functional team moves that metric?  The beauty of the QFD is it allows you to mix-and-match to meet your objectives, not what it says in some book.  At least now you have thoughtful information to help you tailor your Agile approach and an objective way to know if the change you are making are having the intended affect.

• “My Name is Carlton Nettleton…

  Date: 2008.11.25 | Category: Agile, Collaboration, Communication | Response: 0

  “… I have been with the company for about a year and I am an Agile coach helping people improve their software products by focusing on communication and collaboration.”

  is just about the worst way to do introductions in a big group setting.  Why?  Well, think back to the last time you were in a situation where you were asked to introduce yourself to a bunch of strangers…

  • If you were the first person called on, you probably were struck dumb at first; the total deer-in-headlights experience.  When you finally did speak, you felt tongue-tied and probably did not know how much detail to give, when to stop or what the facilitator was even asking.  Of course, once you were out of the spotlight you knew exactly what to say quickly and succinctly, but there no second chances for first impressions.
  • If you were some where later in the order, you probably were relieved and then had that “Oh crap, I’m next” feeling.  Instead of listening to what the other people ahead of you were saying, you probably spent that time thinking about what you were going to say, likely drawing a blank until the person next to you started talking, getting very nervous until you blurted something out.  In effect, short circuiting the introduction process.  Once finished, you likely were thinking “That was OK, but it least it was not bad as hers”.

   

  Next time you need to do introductions try this short exercise of pair interviews as a much more meaningful and rich format for introductions:

  1. Ask people to form pairs with a person they do not know\normally work with.
  2. Allow people 7 to 10 minutes to interview each other and take notes if needed.
  3. After the timebox is complete, ask each person in the pair to introduce the other.

  The pair interview exercise does not put people on the spot, allows people to gather their thoughts and then to showcase themselves as the interesting and accomplished people they are.

• Picking The Right Tool

  Date: 2008.11.21 | Category: Agile, Coaching, Collaboration, Tools | Response: 0

  Last week, I ran a “lessons learned” exercise using the Wall of Wonder.  There were some issues around trust and safety with this group and I did not think the venue of “lessons learned” was the right forum to confront these issues.  So, when one of the participants piped in with a suggestion to do the exercise anonymously, I figured it was worth a try.

  First off, let me say there is a time and a place for anonymous feedback, especially when you think the results will be skewed one way or another on how one or two key actors will respond.  In this case, it probably would have been a good idea to do anonymous feedback, just not with the tool I selected.  The tool I selected relied on people owning their comments by reading them out loud and then answering questions posed by the group in order to provide clarification or further refinement.  Wall of Wonder is designed to generate a free flow group discussion and analysis of ideas in rapid succession.

  By running the exercise anonymously, what I ended up with were a bunch of post-it notes gathered from everyone, reading them out loud and asking people if they wanted to comment on what they thought the author intended.  It had a less than satisfactory result; people were trying to guess at the author’s intent and not revealing their own thoughts and feelings.  Well…that is not exactly true, it was just very indirect.

  So, next time you think you might want to gather anonymous data, don’t use a group exercise like Wall of Wonder.  Try things like secret balloting\anonymous dot voting on pre-selected topics or even a Triple Nickels exercise.  Just select the right tool for the job at hand.