Inductive Bias

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.

This evening the Berlin Scrumtisch took place in Friedrichshain. More than thirty participants followed Marion's invitation for discussions on Scrum, wine and pizza at Vecchia Trattoria.

As there were several new participants, Felix started out with a very brief summary of the very core concepts of Scrum itself: Most important to know is the basic assumption of Scrum, that is planning ahead of time in a very detailed way is impossible. Defining goals and letting those who do the acutal work take the decisions on how to reach that goal is way easier and more promising. The whole process relies on fast feedback loops enabling developers and business people to run experiments on how to improve their work in a controlled environment.

Scrum comes with three roles: The development team responsible for delivering quality software, the product owner responsible for defining development goals that maximise return on investment and the scrum master as the moderator and facilitator who takes care that the roles and rituals are not broken.

Scrum comes with three plus one rituals: The daily standup (about 15min) used by the development team to get everyone up to date on a daily basis on everyone's status, the Scrum Review and the Scrum Planning. In addition very important each sprint includes a retrospective that serves the purpose of improving the scrum team's processes.

Scrum comes with three artifacts: The sorted product backlog of all user stories, the sprint backlog and the burndown chart showing the team's progress.

However Scrum is just a framework - it tells you more on the goals, but less on exactly how to reach them. It should serve as a basis to adapt one's processes to the project's needs.



In the usual meetup planning phase we collected potential topics for discussions and ranked them by voting on them in the end. The topics proposed were:

• Applications of Scrum for non-software-development projects.
  
• How to convince teams of Scrum?
  
• Awareness of the definition of done.
  
• How to integrate testers in a team, extended by discussing the values of cross-functional teams.
  
• How to be a tech PO.
  
• Adding agile/XP to Scrum.
  
• How to keep the team on focus.
  
• Decision making in self organising teams.
  
• Bonus HR in Scrum.
  

The topics rated highest were on raising the awareness for the definition of done and on decision making in self organising teams.

Definition of done

To introduce the topic, Felix repeated the goal of Scrum teams to deliver potentially quality - ahem - shipable software. ;) The problem of the guest and his co-workers was described as follows: Teams have definitions that are inconsistant not only across teams but also within teams.

Ultimately the goal of the definition of done is to enable teams to produce shipable software. One option to make the team aware of the need for better quality software might be to make them feel the pain their releases cause. It does not help to dictate a company-wide definition of done: It's up to the team to define it. However to learn more on what shipable means the team must be allowed to make mistakes. They will fail - but learn from that failure as soon as they feel and see what gets influenced by their mistakes. As a resulst, they will refine their definition of done.

As the person to make happy in Scrum iterations is the PO, this could mean that the PO simply does not accept features, after all he is the one to define what shipable means. One factor that is a pre-condition for teams to be able to learn is to keep them stable. Learning needs time - teams need to be allowed to evolve. If yesterday's team does not feel the pain their mistakes caused just because the team does not exist anymore or has been reconfigured - how would people be able to learn at all?

Decision making in self organising teams

The person proposing this question has the problem that in his teams some developers turn into leaders dictating the way software gets implemented. Other team members rarely join into that discussion and close to never take decisions. The result are endless discussions w/o real results.

The first idea that came up was for the Scrum Master to act as moderator. Marion came up with the proposal to use well known mediation techniques. She promised to share the links - would be great to have them published on the Scrumtisch Berlin blog as well. Thilo mentioned there are courses on mediation and moderation that can help him play that role.

As for long discussions: Felix mentioned a few typical patterns (or anti-patterns) that tend to lead to developers discussing endlessly:

• Fear: fear of punishment for taking the wrong decision usually leads developers to avoid decisions altogether. Fix for that would be establishing and open culture that allows for failure and that enables people to learn from failure.
  
• Striving for the 100% solution: Developers are not used to incremental thinking and try to solve all problems at once. Fix would be to teach them they get time for refactoring and are thus not punished for adhering to the YAGNI principle.
  
• Personal conflicts in teams can lead to the described situation as well and can only be fixed by double-checking the team configuration, potentially changing it.
  

There is a very good book by Cohen on "Succeeding with agile" that has a whole chapter on what makes a good Scrum Master. Checking these properties against your chosen Scrum master might help as well.


When discussing this topic we soon discovered one problem with the team configuration as-is: Scrum masters used to be system architects or senior software developers - that is, highly respected, influencial people. Maybe simply re-configuring teams might help already.

Thanks to Marion for organising the evening - and thanks to all attendees for your questions and input on discussion topics. Looking forward to the next edition of the Scrumtisch.

Disclaimer: I usually just take notes on an old-fashioned paper-notebook, typing stuff into the blog after the meeting is over. Only reason I do it the same evening is the goal of keeping the list of draft postings as short as possible.