Scrum Breakfast in Zürich, July 1, 2009, Adapt Scrum to your needs?

It's 10 o'clock, do you know where your children are?

If there's anyone who can answer that question, it's Silvan Mühlemann, co-founder and Head of IT at tilllate, the leading European site dedicated to the subject of Night Life.

Silvan had been interested in Scrum for a long time. He wanted his development group to be more productive and predictable (hitting deadlines) and he wanted to improve the level of trust between management and development. Scrum looked promising, but he wasn't convinced that Scrum by the book would fit in his company. Is it possible to adapt Scrum without losing the advantages of Scrum?


You can expect an interesting discussion on 

• whether Scrum can be modified without being compromized
  
• how easy/difficult it was to deploy Scrum
  
• the effects of Scrum on Team and Management satisfaction

Date: July 1, 2009

Location, namics zürich, konradstrasse 12, 8005 zurich
Doors open at 8.00, talk starts promptly at 8.35

As usual, namics sponsors the Coffee and Gipfeli, and swissITbridge sponsors the webinar (so you can join us from wherever you are.)

Registation on the SwissICT homepage.

Follow the Zurich Lean Agile Scrum Conference on Twitter

Next week, Zurich's first Lean Agile Scrum Conference will take place at the ETH.

We'll be tweeting about the event live at  http://twitter.com/LeanAgileScrum.

If you haven't registered yet, it's not too late. Presently we have over 80 registrations for the main event and 112 registrations for Ken Schwabers Scrum Breakfast Talk 'Done and Not Done.'  That's roughly 10 times the number of participants at the original Scrum Breakfast in October 2007. It should be a great day!

Registration:

• for the conference
• just for the breakfast
  

And even if you can't come, you can follow the event on twitter!

Can Scrum play a key role in fixed price projects achieving their target?

This question came up on the Scrum Development List yesterday. Here's my take on it:

> Can Scrum play a key role in fixed price projects achieving their target?

Absolutely! In fact, the more I think about it, the more I think Scrum is the best way to take on a fixed price project.

The process starts in pre-sales so that you set the expectations with the customer and leave yourself some maneuvering room to even out the risks of various pieces of the project. Some things will go quicker, others slower. You need to make sure that even if some things turn against you, the project as a whole stays within bounds.

Ron Jeffries will probably point out at this point that you need to add good engineering to your sound management practices. An he will be right. So you need good engineers working on your project. If they've been working together for a while, been working on a similar project, or been working with Scrum before, you improve the odds in your favor. If they were involved in the sales process, that's even better.

Basically you strive to deliver Running Tested Features every sprint (and this implies a fair amount of automation in your quality assurance). Every Sprint you deliver functionality to the customer. And you give him his most important features first. Add in some sensible buffers (Must Have / Should Have / Nice to Have) on the feature side and/or some air the schedule side for risk management, and you have the basis for delivering what the customer needs when he needs at.

Why is Scrum better than a waterfall? Scrum delivers functionality at least every month. Tested and Done. Think constant positive velocity. Waterfall has long periods of zero velocity (initial planning phases) and zero or even negative velocity (periods of testing in which the team and customer discover that significant pieces of functionality don't work properly or otherwise do not satisfy customer requirements). Highly variable velocity is a significant risk, because you cannot really predict when the product will be ready.

Having said all that, I'm not sure I'd recommend fix price contracts if you can avoid them. Last week, I published on ASD an analysis of the suitability of various contracting forms  for agile development. I think there are better alternatives for both vendor and customer.

Towards Agile Support

2 years ago, Anton Schultschick, Leader of IT Support for the EE Department of the ETH Zürich attended my /ch/open workshop on Scrum and got curious about Scrum. 6 months ago, he attended my Scrum Jumpstart with the goal of solving a problem: "My support group has to deal with daily business and we have to successfully complete medium term projects. But the needs of daily business are consuming all our time. We keep the IT running, but we have difficulties with projects. How do we reconcile the two?"

The answer wasn't strictly speaking Scrum. Daily business problems require shorter reaction times  than multi-week sprints would allow. But he did bring home many tools which he could apply to the problem. Today he gaves us a look into what he and his team did:

• Big Visible Task Board(s) galore - for project backlog and the individual projects
  
• Weekly iterations for projects 
• Demos instead of reports
• Retrospectives
• Introducing the Product Owner concept into the daily work. Someone who is interested in and will drive results.
  

Some things he did not do: there is no daily scrum for support -- the discussions proved not to be very useful -- and there is no Scrum Master. He did not go for electronic tools (which provoked some interesting discussion, initiated by a Webinar participant, about why should you use the "primitive" tools -- Short answer: the big visible taskboards are better for communicating with and motivating people -- the people who produce a ticket own the ticket.

Personally, I think this could be the start of a "Scrum for Support" (Let's call it "Scrimmage" - you heard it here first) - a few simple rituals, roles and artifacts which help you do Support well. I've heard Kanban is getting attention in this area, so maybe that's the solution. But there is something essential about the rhythm of a sprint, which Kanban, a flow oriented framework is missing.

There were several people in the room confronted with the same problem, so I hope they will find each other on our Community Site, and start a discussion about what a "Scrimmage" could be!

If you're interested in Kanban, check out Karl Scotlands Lean and Kanban 101 Tutorial at the SwissICT Lean Agile Scrum Conference next month in Zürich. I know I'm looking forward to this talk!

Links:

• Anton's Presentation (PDF): Auf dem Weg zum Agilen Support
  
• Swiss Lean Agile Scrum Community Site: leanagilescrum.ning.com
• Lean Agile Scrum Conference in Zürich: http://www.swissict.ch/vomhypezurpraxis

3 Player Ball Point Game

The Ball Point Game (or Tennis Ball Factory, as I like to call it) is one of the most popular games for learning Scrum. This game encapsulates the essence of Scrum like no other: Team-Work, Planning, Retrospectives, Estimating. Continuous Improvement. Everything. But as defined by Boris Gloger, you need 5 people to play. Teaching to a small class, I needed a version which would work with three people. I almost gave up, until I realized that most people have two hands.

The rules of the ball point game are simple: To score a point, everyone in the group must touch the ball once. The ball must have "air time" when the ball is not touching any player. No one may pass the ball to their immediate neighbor. The objective is to score as many points as possible in 2 minutes. The team gets several attempts to improve their score, with a retrospective between each attempt.

If the team is 4 people or less, these rules don't work. The immediate neighbor rule can't be satisfied with 3 people and with 4 people, that rule produces two closed loops.

I modified the game as follows:

1. The restriction on passes to your neighbor was removed
2. Each player must touch the ball twice, once with the left hand, once with the right.
3. A player may not pass the ball to himself
4. The rest is unchanged.
   

I tried it out at a Practical Product Owner Training last week,  and it worked just fine. As usual, the team moved closer together between the first and second attempt. The team improved it's performance dramatically from the first to the fourth attempt. Using the left hand was a challenge, but not insurmountable (lost balls were a topic in the retrospective). An important fun factor for the Scrum Training was preserved, even in the small group.

How did it work: Here is the team in action on their final attempt: