Archive for the ‘Team’ Category

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

  
  

• The Importance of Balance

  Date: 2009.09.19 | Category: Agile, Team | Response: 0

  Looking through some old notes from China, I noticed there were a number questions about the roles in Scrum, the importance of each role and how each role balances the other.  As a review, here are the three “offical” roles in Scrum and an additional role I consider important for the success of your product as well – stakeholders.

  1. ScrumMaster: their role is to ensure the integrity of the process, that the preconditions for the framework are met, all the roles are filled and the players are following the Laws\Rules (I like to use the terms Laws since in rugby the rules of the game are called Laws – CEN).  They also encourage the Team to self-organize, remove obstacles, teach others about the Scrum and be on the lookout for people trying to minimize the feedback the framework is providing.
  2. Product Owner: the person who defines and orders the list of features (called the Product Backlog) the Team is going to build for the organization.  They are given the authority to make tradeoffs about scope and date within the boundaries of the governance model of their organization.  Often times, Product Owners collaborate with the ScrumMaster to get the most value from the process.  Product Owners can delegate some of their work, but never their responsibility.
  3. Team: the cross-functional group of individuals given the responsibility and authority to turn the Product Backlog into working software.  The Team is urged and guided by their ScrumMaster to strive for continuous improvement and technical excellence.  They work with the Product Owner to determine the best sequence of features for the business.  When an obstacle is identified, the Team always tries to resolve it themselves before calling in their ScrumMaster or other parties.
  4. Stakeholders: anyone who has an interest in the product.  They are outside the Team and as a result, can only influence the Team’s activities at clear checkpoints.

  Scrum, just like every other Agile process, is a carefully balanced framework.  Each practice, guideline, artifact and role are the minimum collection of elements needed to be successful with the framework.  When you fail to fill a role, give one role more weight or weaken a role, all sorts of dysfunctional behavior manifests itself.  In some respects, this is a strength of Scrum because it makes all sort of dysfunctions visible very quickly.  That is why the ScrumMaster role is VERY important.  Their job is to make sure people acknowledge the dysfunctions and try to devise ways to eliminate or minimize the obstacles.  In my experience, this is a full time job.

  One dysfunction Scrum was created to eliminate was the detrimental impact of meddling Stakeholders.  Too many Teams have trashed about trying to implement this great idea or another from competing Stakeholders, that they end up chasing their tail and getting nothing done.  This problem is overcome through a combination of an empowered Product Owner and the Law that you cannot change a Sprint once it has started.   In practice, the diagram shows the new relationship the Stakeholders have with their Scrum teams.  Generally, they do not have a direct line of communication with the Team.  Most communications come to the Team via the Product Owner and the ScrumMaster.  Again, we must balance the need to protect the Team from distractions and the needs of the business to direct the Team.  Scrum provides this balance through the Sprint Review at the end of every Sprint where the Stakeholders are invited to review the product, give feedback, provide oversight and help the Product Owner reprioritize the Product Backlog.  With the Sprint Review, we can provide the proper balance between protecting the Team from distractions and letting the business respond to changing conditions rapidly and effectively.

• The Spirit of Scrum

  Date: 2009.09.11 | Category: Agile, Rugby, Scrum, Team | Response: 0

  I was having a conversation with a manager the other day about the difficulties she was having filling a position.  Everything seemed like an obstacle that could not be overcome – the distances were too far, candidates were good on paper only, not enough time to review their work, etc., etc.  It seemed that no matter the issue, it was going to be impossible for her to succeed.  When you have an attitude like that and where everything is an obstacle, it would be impossible to succeed.

  The Spirit of Scrum borrows heavily from what I call the Spirit of Rugby: teams, composed of players of different physiques and skills, are united by a drive to win through a strong sense of camaraderie, the boundaries of fair play and good sportsmanship.  Teams that are proficient in the basic skills, respect the Laws are embody the Spirit of Rugby are rewarded with victories.  It is no surprise that the number #1 and #2 teams in rugby, South Africa and New Zealand, embody these principles and year after year are ranked as the top teams in the world.  What I have found is the same Spirit of Rugby in the smallest amateur division is the same Spirit of Rugby seen in the international teams.  More so than the Laws, it is the Spirit that connects the amateur teams with the professional teams.

  In Scrum, you need the same spirit in order to succeed.  Everyone on the team has something to contribute and when you compete, you do not hold back.  You leave everything on the pitch.  Half measures do not equal success in rugby nor in business.  Sure, some people may get more glory than others, but their time in the spotlight is due to the hard efforts of the rest of the team.  When the team is united, there are no obstacle can stand in their way.  Just like in rugby, teams that embody the Spirit of Scrum are linked no matter what the size nor the domain.  They are all playing with the same game. 

• Importance of the Definition of Done

  Date: 2009.09.04 | Category: Agile, Coaching, Scrum, ScrumMaster, Team | Response: 0

  I was looking back at some old notes of mine from China and I came across a number of questions from the people I worked with about the Definition of Done.  The Definition of Done (DoD) is a very important concept in Scrum and not spending time to construct a DoD is a common mistake with new Scrum teams.

  In my opinion, the DoD provides visibility and alignment on just exactly what it takes to get a user story completed in an organization.  It could almost be seen as a unstructured value-stream map.  We write down the DoD to illuminate any hidden queues in the organization and to make visible the real effort it takes to complete a user story.  It is also there to protect the Team since it cannot be changed during a Sprint.  Nothing irritates me more as a Team member, or a ScrumMaster, to move the goalposts of a Sprint after it has begun, i.e. adding a new auditing requirement to the DoD.

  The DoD is NOT the same as the acceptance criteria for a user story.  The DoD is an engineering checklist for the cross-functional Team.  The acceptance criteria is the checklist Product Owner and stakeholders use to know if a user story is complete.  They assume all the items in the DoD are complete and if they are not (that is called Design Debt), the Team cannot demo the feature at Sprint Review.  You can think of the DoD as the pre-requisites that need to be finished before a story may be shown at Sprint Review.

  Finally, I have found it better for individual Teams to come up with their own DoD rather than be handed one from management.  When first working with a Team, it is normally better to document what the Team is doing and label that it’s DoD and add to it over time rather than forcing some onerous DoD created by some disconnected process people who don’t even do the work onto an uncertain Team.  Of course, there are some basic standards (code reviews, some form of pair programming, unit testing, etc., etc.) that must be in all DoD, but I find most Teams will include them on their own.

  So what to do when your company has 12 versions of the DoD floating around?  Well, that is why you have ScrumMasters.  It is their job to get the various Team DoD in alignment, not the process goons.  The process goons have good stuff to add to the DoD and Scrum is about collaboration, not forcing other people to do your will.  If the process groups want Teams to do extra work, their requests on the Team are made visible just like everyone other.

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

• Letting Go of the Past

  Date: 2009.02.23 | Category: Agile, Coaching, Team, Transitions | Response: 0

  Sometimes when I meet with people who want to do Scrum (or anything Agile), they have a hard time looking beyond the past to a new way of making products.  They resist any change to the way things are done because they are often times too wrapped up in their old patterns of behavior.  I understand where this form of resistance originates – these individuals have been so involved with their the organization and its dysfunctions, they have forgotten that things can be different.  They have forgotten that things were different some time ago and their organization used to be “cool”.  What many people do not truly understand is they really do have the power to make their organization “cool” again and that if they really want something to change, it will change.

  It is no mistake that the very first line of the Agile Manifesto reads:

  Individuals and interactions over process and tools

  One of the main themes in Agile is about individuals making a better professional life for themselves.  Apart from our families, our professional life is the second largest use of our time on this planet.  The relationships and interactions we have at work have some of the most far reaching influences over our lives, yet we all act as if we are passive actors in our professional lives.  If we are unhappy about our work life, we own some of responsibility for current state of affairs.  The powerful thing about Agile is we can decide to make the future better.     

  In a recent example, I was coaching a group of programmers on how they can use Scrum to develop a new product.  They were very early in the development of their project and we were trying to reach a consensus of  how we will work together in the future.  I was struck by how many of the obstacles they were discussing which were result of “marketing”.  If “marketing” only did this or provided us with that or gave us what we asked for – you get the picture.  It’s not us that have the problems, its them.  While there was some truth to their analysis, but as in any good dysfunctional relationship both sides share equal blame for the situation.  What I found surprising was these programmers had ceded all their power for change to “marketing”.  If you believed them, nothing would change until you got buy-in from “marketing”.  As a result, they were stuck.  

  I think I made a breakthrough with these folks because by the end of the workshop, they were very interested in finding measures which helped them see if they were on the right track for change or off in the weeds.  Anytime the participants in a workshop want to stay for a couple more hours to define metrics is sure sign of ownership.

• Without Trust…

  Date: 2008.10.27 | Category: Agile, Collaboration, Conferences, Team | Response: 0

  …you cannot have collaboration.

  My first stop at the SD Best Practices 2008 was a tutorial called “Collaboration Works!” by Ellen Gottesdiener.  I am familiar with many collaboration techniques, but I was looking for some additional tools and tricks (which I will include as separate posts later) and maybe sometime insight on some tricky issues from work.   Ellen asked everyone what their personal goal for the workshop was and mine was: “learn how to foster commitment in an environment of jaded people” (which might speak more to the goal owner than the actual people he works with).

  I have spent a lot of effort lately trying to help people act more collaboratively, but they often hold back and are tentative.  True collaboration is elusive.  It seems as if there is often something (or someone) else “in the room” acting as an obstacle to collaboration.  Maybe it is me – ya never know, so I asked Ellen what she might identify as the problem.  Her answer was that a prerequisite for collaboration is trust.  That if there is no trust among the team member and\or between the team and management, there will be no collaboration.

  Duh!  Trust - you have to have trust first! The issue had been staring me in the face for a long time, but Ellen finally gave me a word for it -trust.

  We had a further dialgoue trying to dig deeper on how to overcome this obstacles.  She suggested that one needs to build safety within the team first before they have the capacity to share with management.   If the team did not feel safe with each other, they will not give management their candid opinions.  Her recommendation was to use visioning, chartering and retrospectives as tools to bring feedback to management that the team has issues around trust.  She also mentioned that incongruent behavior from management, i.e. “no overtime, but stay late to get it done”, will also further erode trust.