5 tips for effective sprint demos by distributed teams

Demo during Lego Scrum simulation. Everything goes better with Lego.
Demo during Lego Scrum simulation. Everything goes better with Lego.

What is a sprint demo?

Agile teams using Scrum work in a time box called a sprint to get software built early and often. A meeting is held at the end of each sprint with the whole team including product owner and anyone else who would like to attend. The goals of the demo are to:

  1. Demonstrate work is done done. Nothing like taking work for a test drive to see if there is more than chicken wire holding pieces together. Teams demonstrate that acceptance tests pass. Acceptance tests are the product owner’s requirements for a user story to be considered done. I agree with Ron Jeffries‘ view that acceptance tests provide clarity, remove subjectivity over whether a story is done or not.
  2. Generate new insights. Seeing and interacting with real software leads to new insights. The client might want new features or enhancements, or realize a corrective change in direction is needed. The product owner has new information on a regular basis to adjust priorities going forward.
  3. Progress report. Forget Gantt charts. Seeing the product is the best method for a senior manager to know where the project is at.
  4. Team satisfaction. Demos give the team a sense of accomplishment, satisfaction from positive feedback and the client accepting stories. There is also greater confidence in the project’s direction based on feedback.

How to prepare

One or more persons on the team is responsible for presenting the demo of completed stories to the client and the rest of the team. Note, only completed stories are demoed, no recognition for stuff 90% done.

  1. Don’t use slides, show real working stuff with ‘just enough’ prep work. Preparation should take no more than an hour for a two hour demo.
  2. Plan your demo in advance. Write down the steps you are going to use, and try them out. Make sure the demo is going to work as expected. You’ll look much more professional and the demo will go faster, plus no surprise ‘gotchas’.
  3. Use acceptance tests for the basis of the demonstration. Bonus points for automating those tests ahead of time and running the script (at slower speed) during the demo.
  4. Know your agenda. The simplest approach is to go through completed stories in priority order.

5 tips for demos by distributed teams

Distributed teams face additional hurdles to giving demos… time lags, less interaction, limited presentation options. Here are some tricks I’ve learned after 3 years of facilitating distributed demos:

  1. Test drive without the blindfold. Save time and improve the experience by using a screen sharing tool so everyone can follow along – much better than walking others through a series of clicks and hoping they see want you want them to see. Screen sharing tools that work well and cost little or nothing include Yuuguu, Yugma, and DimDim. Newer versions of Skype offer desktop sharing, though you can’t do video conferencing with Skype at the same time.
  2. Remove distractions. Nothing like having your buddy’s IM rant about last night’s hockey game appear on the screen to lose momentum. Close any applications that use pop-up notifications. You don’t want those interrupting the demo. Better yet, close all applications you won’t need for the demo by default so your machine runs optimally.
  3. Hearing is everything. I’ve suffered through too many conference calls with poor audio quality. While Skype and some conference calling services are free, you get what you pay for in my experience. I’m a fan of HiDef Conferencing, which supports phone and Skype participants on the same call. There have been a number of times where we’ve jumped onto HiDef after a client’s service ran into problems.
  4. Test tools ahead of time. Make sure everyone knows in advance what tools will be used and what they need to do to set them up. Make sure first time users test the tool ahead of time, perhaps a scheduled time before the call so you can help troubleshoot. Avoid the 15 minute scramble at the start of a call to fix issues.
  5. Provide an agenda. If everyone has access to the team task board, use that to walk through the list of stories and their itemized acceptance tests. If not, send out an email beforehand with the list of stories to be shown, and any relevant links that will be shown during the demo. Make it as easy for people to follow along and keep up. Alternatively, show the agenda to everyone after each completed step via screen sharing tool.

Bonus tip: Don’t forget to turn off screen sharing when you are done, before you start reading your email. 🙂

Do you work on a distributed team? What are your tips for giving effective demos?

Weekly post (weekly)

Posted from Diigo. The rest of my favorite links are here.

Options for team task board when one team member remote

Team task board
Team task board

A new client of mine new to Agile has the entire team located in one office except for one person, a DBA living in Texas, one time zone away. I want the local team to benefit from having a highly visible team task board, which usually means cards/stickies posted on the wall like the picture above.

At the other end of the spectrum, the remote member needs to be informed of sprint progress, to know what tasks to do and to update the tasks he is working on. That level of interaction usually means everyone has to use a digital tool, which in this case seems unfair to the local team’s productivity and communication, given all but one are local.

The best solution, of course is to find some way for that person to move locally. It’s not often that will happen, but moving is the first option to consider. The cost of having a remote team member is borne by the full team, so make sure the remote person adds enough value to justify the cost.

I then went on Twitter to ask for suggestions, and got two, based their experiences:

  • Rick Scott (@shadowspar) has worked as a remote team member for several years, mostly as a tester. He suggests using a web cam focused on the task board, or take pictures and post on a project wiki.
  • Andy Brandt (@andybrandt) proposes projecting a digital team board on the wall. The digital tool gives the remote person the means to update his work and get details like acceptance tests to do his work. The local team benefits from a highly visible task board.

My thoughts on these approaches:

  • Rick’s suggestion is ok for seeing the overall picture, but doesn’t go far enough. It’s hard to see all the details on stickies from a picture, and acceptance tests are often written on the back side of a user story card. Writing all details on the front is an easy modification, but that doesn’t solve the problem of seeing everything clearly. The remote member still has no easy way to update his progress either.
  • Andy’s idea seems like a good compromise. Everyone can access and read / update the same information. The local team has their highly visible task board. The key drawback is all changes are made through a tool. Mike Cohn feels that the difference between the two approaches is dramatic.

Idea: Synchronize physical with digital

I asked Mike Cohn for his insights on this topic, and he responded with a great post. The solution he proposes is to have the Scrum Master synchronize a physical task board for the local team and an electronic version for the remote person:

A shared spreadsheet is normally sufficient for this, but some teams opt for a more specialized tool, which is fine. Many tools offer 5-10 user free licenses and since the tool is only needed by the ScrumMaster and one remote employees, the free license is adequate.

Mike then suggests using a marker system to minimize the effort needed to keep the two versions in synch. The Scrum Master then only has to update the flagged tasks, saving her time. This can be done using post-its or coloured dots. The Scrum Master simply removes the markers after updating the tasks.

Derek Mahlitz, a Scrum Master for a team with one remote member confirms this approach is effective for his team:

We do this exact process for my team. We have 7 members in 1 office in NY and 1 member at home in FL. The collocated team updates our task board and I (SM) replicate in an Excel spreadsheet that is stored in our sharepoint solution. That way he can keep up with the tasks. We also do video for daily standup and all collocated team members have webcams for quick meetings throughout the day with FL home worker. We are a year into scrum and this has worked great without issue.

Out of all the solutions I’ve heard, Mike Cohn’s seems like the best approach without extravagant spending on touch screen surface hardware. My client suggested trying a Wii controller to update a web-based task board projected on a wall. Can’t go wrong in trying that.  🙂

Plone-attitude of gratitude

Photo courtesy Mr. Topf http://www.flickr.com/photos/mrtopf/
Plone Conf 2007. Photo courtesy Mr. Topf http://www.flickr.com/photos/mrtopf/

How can I continue to stay connected and to give back to a community that has given me so much?

I’ve been wrestling with that question for a while. My connection to Plone the product is becoming less and less. I don’t use Plone in my work any more, now that my focus is on training and coaching Scrum, an Agile software development framework.

Meanwhile, my ties to Plone the community remain. I’ve been fortunate to work for companies that do build Plone solutions: Jazkarta, ifPeople and currently Web Collective, and am exploring options with a few others. Each company is doing amazing work, progressive in spirit and deed. That higher purpose thinking pervades the community, and is another tie that binds me.

So I find myself in this awkward situation – how to contribute and remain connected without immersing myself in the technology that binds everyone else together?

plone-1
Then, my last day at the Plone Symposium, an idea came to me – donate 1% of all Plone-related earnings to the Plone Foundation. Yeah, I like that. Any time I work with an organization offering Plone-related services, the 1% pledge applies. And just for fun, let’s make it retroactive to the start of this year, So far, then, that donation totals over US $125, maybe enough for printing some new Plone schwag from the great minds at SixFeetUp.

I don’t know where my Plone-enabled journey will go from here. After 6 years, I hope we’ll dance for a few more. We’ve got more world changing to do.

Weekly post (weekly)

Posted from Diigo. The rest of my favorite links are here.

Weekly post (weekly)

Posted from Diigo. The rest of my favorite links are here.

Sault’s Twittering class grows

Michael Purvis (@MichaelPurvisOK), report with the Sault Star wrote a piece on the growing local use of Twitter. I was the lucky one to get my photo snapped. He shares the stories of:

  • an elementary teacher connecting with experts in education
  • a naturopath sharing tips and suggestions on health topics as a way to promote her business
  • a professor who dialogues with students and connects with other parents of autistic children
  • the Sault Star which now posts links to a selected list of stories and events (Michael manages this, too)

I discover new people from the Sault on Twitter every week, and the rate of adoption is increasing. I’m following about 60 people from the area at the moment. Some of these people have become good friends, even though we’ve never met.

The reality though is that only about 5% of Twitter users really understand how to use and benefit from the tool. Many give up before getting to that point.

One way I’m trying to give back to the community is by sharing knowledge of how businesses and individuals can benefit from social media. I’ve given one course on Twitter as well as a session on social media for small businesses. I’m considering offering the course again, so please contact me if you are interested.

There is also an upcoming Tweetup for people using or are interested in Twitter to connect. Register now as seating is limited.

Read the full article: Sault’s Twittering class grows (via Sault Star)

Weekly post (weekly)

Posted from Diigo. The rest of my favorite links are here.

Agile Estimation [Video]

I consider Mike Cohn one of the best on the topic of Agile estimation. His 90 min presentation on how to estimate is well worth your time. I took his one day course and all of the material in the presentation appears to come from that course.

Mike is truly inspired to find the best ways to estimate. He once forced each of his teams to pick a different method of estimating, too see which would win out a la Estimating Survivor.

Learn why relative estimating is better than absolute, how too much information can lead to poorer estimates and get good at (planning) poker plus a whole lot more.