Christmas Scrumtisch

Christmas Scrumtisch #

Today the last Scrumtisch Berlin in 2010 took place in Friedrichshain. Thanks to Marion Eickmann and Andrea Tomasini for organising the Scrum user group regularly for the past years.

Though no presentation had been scheduled ahead of time the Scrumtisch was well attended by over twenty people, mostly from companies based in Berlin who are either using Scrum already or are currently in a transition phase.

We went straight into collecting and voting on topics for discussion. In total we ended up having eight potential topics listed, including but not limited to

Scrum and non-feature teams, does it work - and if, how?
Transitioning to Scrum - what are the stake holders that must be convinced first in a company?
Scrum with teams made of people buying into Scrum and those that don’t - does that work?
Can Scrum be combined with people who want to telecommute?
Scrum and platform development - how does that get combined?
Scrum in systems engineering, embedded development - how to setup teams?

After voting we had the two clear winners discussing Scrum in teams that don’t buy into the method completely as well as telecommuting with Scrum teams.

Scrum with broken teams

The situation described: The attendee proposing the topic has the problem of being Scrum master at a team that does not completely buy into Scrum. There are a few developers who like being self-organising, who love short feedback cycles. However there are a few others who would rather stick with their technological niche, get tasks assigned to them and avoid taking over tasks from others.

During discussion we found out that in this company Scrum had been introduced as a grass-roots movement little over a year ago. The introduction of the method led to success clearly visible in the company. In turn the method was tried on a larger team as well. However at the moment the team is at a point where it is about to break apart: Into developers happy with change, flexible enough to adapt to shift in technology and a second half that would rather continue developing the old way.

One very important point was raised by one of the attendees: With Scrum getting introduced so fast, compared to the length in time the company had been living before, it may well be time to slow down a bit. To sit down with the team in a relaxed environment and find out more on how everyone is assessing the current situation. Find out more on what people like about the new approach, and about what should be changed and still needs improvement. In the end it’s not a process issue but a people problem - there is a need to get the team on-board.

Team-building activities might help as well - let the team experience what it means to be able to rely on each other. What does it mean to learn new things in short time, to co-operate to solve tasks so far untackled?

If team-members start ignoring the sprint backlog working on other tasks instead there is a question about whether there is enough trust in the product-owner’s decisions. On the other hand with pressure resting on the team’s shoulders there might be a need to stop the train, fix all open issues and continue only after the project is back in shape. However also this needs all team members working towards a common goal - with everyone willing to take up any open task.

Scrum and telecommuting

Basically the question was whether it works at all (clear yes from the audience) and if, which best practices to use. To be more precise: Does Scrum still work if some of the team members work from home a few days a week but are in the office all other time. The risk of course lies in loosing information, in the team building common knowledge. And thus becoming less productive.

There are technical tools that can help the process: electronic scrum boards (such as Greenhopper for JIRA or Agilo) as well as tele-conferencing systems, wikis, social networking tools, screen sharing for easier pair programming. All tools used must entail less overhead then the provide in benefit to the team however. Communication will become more costly - however if and to what extend this translates to a loss in productivity varies greatly.

There must be a clear commitment from both sides - the telecommuter as well as the team on-site - to keep the remote person in the loop. Actually it is easier with teams that are completely remote. This experience is sort of familiar from any open source project: With people working in different time zones it comes naturally to take any decision on a mailing list. However with some people having the chance to communicate face-to-face suddenly decisions become way less transparent. At Apache we even go as far as telling people that any decision that is not taken on the mailing list, never really was taken at all. A good insight into how distributed teams at Apache work has been given earlier by Bertrand Delacrétaz.

For team building reasons it may make sense to start out with a co-located team and split off people interested in working from home later on. That way people have a chance to get to know each other face-to-face which makes later digital-only communication way easier.

Thanks again to Marion and Andrea for organising today’s Scrumtisch. If you are using Scrum and happen to be in Berlin - send an e-mail to Marion to let her know you are interested in the event, or simply join us at the published date.