Tag: distributed

5 tips for effective sprint demos by distributed teams

Posted on by in Agile
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?

Options for team task board when one team member remote

Posted on by in Agile
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.  🙂

Challenges Distributed Agile Teams Face, and Ways to Overcome Them

Posted on by in Agile
Notes taken from Agile 2008 sessions on distributed Agile: “What Makes Distributed Agile Projects Succeed (or Fail)?” workshop by Chris Sims and Panel discussion on troubleshooting distributed agile team projects

Things panel found most surprising about distributed Agile (DA)

  • There are people at the other side!
  • DA can work well once the proper process and tools are in place
  • We can learn from teams in other places
  • Agile helps to ease cultural, time burdens through increased communication

What makes DA harder than co-located teams

  • Planning overhead is higher for distributed teams. May need to stretch out length of iterations, to adjust for the additional overhead needed for distributed communication
  • Standup and meetings in general take more time
  • Don’t act like your project is co-located – pay the tax for distribution
    • Executable requirements may help a lot – Fitness tests
    • Mini-specs for user stories – need to communicate more in writing with remote people
    • Use acceptance tests to drive story clarity
    • Have developers review tasks ahead of time to prevent blocking
    • Involve everyone iteration planning

What is most important to succeeding with DA

  • Unanimous: Need to get people together to build relationships, get more collaboration. Plan for at least 2-3 times / year. This also helps to understand cultural differences. Build in the cost of these trips into rates.
  • Leverage technology to bring people closer together – video top choice for people on panel. Use video to see each other, point to documents being discussed
  • Strong engineering practices – continuous integration, TDD, pairing, refactoring – on some teams, you can’t go home with anything that doesn’t build
  • Invest in coaching. You can improve scrm abilities by going down and training, spending time. Identify leadership within teams, and work with leaders to be a local proxy scrum master
  • Take time to understand cultural differences – inward (your own), outward (other cultures)
  • Need a well defined definition of done for team to follow.
  • The best way to build teams is through work. Succeeding (or failing) together at something draws everyone closer.

Other tips and observations

  • Time box discussions after standup if they tend to run too long.
  • Decide if people are suited to agile. Do they take pride in and ownership of their work? Do they show initiative? Are they technically strong?
  • A local proxy product owner is helpful
  • Take time to share about culture. Do things like share recipes, talk about movies, etc.
  • Get pictures of team members and look at them when collaborating.
  • Use remote pairing – avoid isolation
    • VNC and Skype are one option
    • When pairing isn’t possible then use code reviews to ensure *some* kind of review happens.
  • Ade Miller in his session notes observes that distributed teams are more dysfunctional than co-located teams. The act of distributing a team simply adds to any existing problems it might have.
    • Be prepared to do additional work to negate the impact of team distribution.
    • Articulate this work and cost to the business. It’s all about delivering maximum value to the customer not about hourly rates of individuals. Overall is the team delivering more value?