Use tools to keep the whole team engaged.

Use tools to keep the whole team engaged.

Distributed Agile planning is not any different from non-distributed in terms of its goal and process.  What should be different are the techniques and amount of facilitation.  Before we go further, I do not think there is any reason planning can’t be done amongst a distributed team. I do not believe there is any need to change the time parameters.  However, both of these statements are true only if the team stays engaged and the Scrum Master provides active facilitation.  The single biggest hurdle when a distributed team is involved in planning is keeping everyone engaged.

Visualization is a powerful tool to help foster engagement.  There are two types of visualization that are important.  The first and simplest is that all team members should be able to clearly see what is being discussed.  For example, I recently participated in an internal sprint planning meeting.  We used a screen sharing software that everyone on the team used.  As a story was discussed and planned, we brought it up on the screen so that everyone in the session could refer to the same set of words. Tasks, as they were identified, were typed directly into a shared document on the screen.  A second form of visualization relates to the team.  Use video on top of any screen sharing tools.  Seeing people as they discuss a point or talk about a story imparts significantly more information that just hearing them.  Think of how different the typical experience is when listening to radio compared to television.

IT personnel tend to be gadget and tool aficionados.  While a good tool for seeing the backlog or Kanban board is critical (emphasis on good, there are some re-purposed waterfall tools I would avoid like the plague . . . actually I might consider the plague first), the process needs to be simple enough that the set up time does not eclipse the planning time.  Tools like mind mapping software can be very useful to quickly capture and organize information. I personally use several including FreeMind (free and open source).  Another simple tool is Mountain Goat Software’s planning poker site at www.planningpoker.com.  I strongly suggest Scrum Masters (or coaches) walk through the tool suite they will use during planning before “going” live.  A simple check list of tools I use is:

  1. Screen Sharing Software: Tool examples include Webex or the like
  2. Video: Software examples include Skype Pro and OOvOO.
  3. Backlog/Kanban Boards: Examples include LeanKit, Kanbannery and Trello.
  4. Mind Mapping Tools: Examples include iTHoughts, FreeMind and Astah.
  5. Planning Poker Tool: www.planningpoker.com
  6. Egg timer (or sometimes the timer on my phone)
  7. DECENT PHONES

The last item is capitalized because all bets are off if team members can’t hear each other.

Once the team has gotten over the hurdle of using the communication tools, the final problem is one of facilitation.  The Scrum Master needs to facilitate the process with special emphasis on making sure everyone participates and stays engaged.  They also need to pay attention to pace.  I use an egg timer to remind everyone of both the overall time box and the time box needed for planning each unit of work.

In distributed Agile, the planning process does not change.  However, keeping everyone engaged might be more difficult. The Scrum Master can make engagement more likely by making the process as easy as possible and making the process as personal as possible.  Planning is still a whole team sport, make sure that the whole team participates, no matter where they are.

Barnacles attach to ships and add drag

Barnacles attach to ships and add drag

In earlier entries of the Daily Process Thoughts, I believe we have established that basic Scrum process can be defined using three roles, five events and three artifacts. This is the Scrum canon, much like the canon of stories that make up the Sherlock Holmes series. Many organizations and consultants have added practices to Scrum in order to meet specific needs (if those needs are real or perceived is an open question).  At the Scrum Gathering in Las Vegas in 2013, Dr. Alistair Cockburn called these additions barnacles; Ken Schwaber has written extensively about “Scrum buts. . .” and “Scrum ands. . .”. Barnacles grow on the hull of ships and create drag, slowing the ship or requiring greater energy to drive the same distance. However for all of the downsides of a barnacles they serve a purpose, deliver a benefit, or they would not exist in nature.  The additions to Scrum must compete and deliver value or they will be swept aside.  Several of the more common barnacles are related to defining and estimating work. They include:

  • User Stories, phrased in the now classic “persona, goal, benefit” format, are an addition to the canon of Scrum.  User stories provide a disciplined framework for describing units of work, which improves communication.
  • Story Cards, which generally include the user story, acceptance criteria, size and other ancillary pieces of information, provide a means to the organize units of work a team will be working on.  Organization of information provides a means of visualizing gaps and keeping track of work items so they can be communicated (and in my case, so they don’t get lost).
  • Story Points, are a representation of the size of a user story or any unit of work based on the collective understanding of the team that is being tasked to deliver the work.  The use of story points provides a team with a consistent scale that helps team members communicate about their perception of size.
  • Planning poker, a variant of the Delphi estimation process, acts as mechanism to structure the discussion of size and estimation within Agile teams to increase communication, ensure all relevant voices are heard and to control paralysis by filibuster.

Add to the potential additions technical practices like Test Driven Development, Behavior Driven Development, Continuous Builds and hybrids like Scrumban and the number of potential barnacles can grow quite large.  That is the nature of a framework.  Techniques, practices and processes are bolted on to the framework first to see if they improve performance.  As practitioners and methodologists we must insure that only those that provide tangible, demonstrable value are allowed to stay bolted.  Remember that each organization and team may require more or less barnacles to be effective.  Like the Sherlock Holmes stories, others have extended the canon with their own stories, practices and process.  Some are valuable and find traction, while others are experiments that have run their course.