Follow-up on the Scrum Practitioners meeting Oct 15th

Thank you everyone who participated on the Scrum Practitioners meeting on the 15th of October at Axis Communications in Lund.

Some of the things discussed were;

• Distributed Scrum; does it work? A few of the participants had some experience in this, and the opinions were mixed. Bottom line is; yes it is certainly possible to get it to work. I.e. it doesnt automatically fail. It requires work, though. But that is true for any methodology; if you have team members on a distance you have to deal with the overhead cost in terms of extra communication, tools, activities, travel, whatever. Depending on how the distribution looks you can try different approaches; divide into teams per site, or distribute teams and work with conference solutions, digital whiteboards, etc for the daily meetings. Experiment. Distributed teams and distributed Scrum is not ideal, but if you're faced with a situation where you have a distributed team, don't automatically rule out using Scrum.
• How/if sort out design-issues before sprint start? The problem discussed was that of things taking a long time to finish if you do "design stories" in one sprint to discover what/how to implement, and actually implement in in the following sprint. With 4 week sprints it can take you 8 weeks to finish a story, even if it is not that big. The concept of "spikes" was discussed, i.e. prototyping and delivering a piece of working and valuable code in each sprint, rathen than doing "only design" separated from "only development". If you do "design stories" it may be wise to timebox rather than trying to estimate it, because the definition of done for "design" is hard to grasp. Another tip can be to consider shortening the sprints, to e.g. 2-3 weeks instead of 4.
• The problem of traditional, conservative customers, demaning fixed-price-fixed-scope contracts was discussed. The concept of "Money for Nothing and Change for Free" was discussed as an interesting theory. None of the participants had experience with that approach, though.
• Coping with less-than-fulltime resources in a Scrum Team: The problem of traditional customers and product owners who do not realize that Scrum requires a much higher degree of involvement. Not sure we came to any intelligent conclusions on how to address this problem, other than the importance of realizing that it is a problem if the customer/PO is not involved.
  
• Problems with large team size was discussed, and consequently the problem of daily scrums taking too long time.
• Is the traditional project manager automatically the best choice for Scrum Master when introducing Scrum? Not necessarily, was the conclusion. This seems to be the default choice in the industry, but it is not necessarily the best. It depends on your organization, the people, the problem domain, etc. The Scrum Master may be a good choice for the Project Manager, but Scrum Product Owner may be too.
  

Several other interesting things were discussed too, but I will not go into more details here.

I'm looking forward to the next meeting.