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.

Today, the Scrumtisch organised by Marion Eickmann from Agile 42 met in Berlin Friedrichshain. Though no talk was scheduled for this evening the room was packed with guests from various companies and backgrounds interested in participating in discussions on Scrum.

As usual we started collecting topics (timeboxed to five minutes). The list was rather short, however it contained several interesting pieces:

• (6) Management buy-in
  
• (6+) CSP - Certified Scrum Professional - what changes compared to the practitioner?
  
• (4) Roles of Management in Scrum - how do they change?
  
• (13) Coaching self-organising teams - team buy in.
  

Team buy-in

As prioritised by the participants the first topic discussed was on coaching self organising teams - with a heavy focus on team buy-in. The problem described dealt with transforming water fall teams that are used to receiving their work items into self organising teams that voluntarily accept responsibility for the whole project instead of just their own little work package.

The definition of self organising here really is about teams, that have no (and need no) dedicated team leader. On the contrary: leadership is automatically transferred to the person who - based on his skills and experiences - is best suited for the user story that is being implemented at any given time.

The problem the question targets is about teams, that really are not self organising, where developers do not take responsibility for the whole project, but just for their little pieces: They have their gardens - with fences around that protect them from others but also protect themselves from looking into other pieces of the project. Even worse - they tend to take these fences with them as soon as work items change.

Several ways to mitigate the problem were discussed:

• Teams should work in a collaborative environment, should have clear tasks and priorities, whould get some pressure from the outside to get things done.
  
• Some teams need to learn what working in a team - together - really means. It may sound trivial, but what about solving problems together: Spending one day climbing hills?
  
• Committments should not happen on tasks (which by definition are well defined and small) but rather on Features/ user stories. Task breakdown should happen after the committment.
  
• There are patterns to break user stories that are too large into multiple user stories. (Marion: Would be great, if I could add a link here ;) )
  
• Teams need to be coached - not only the scrum master should get education, but the complete team. There are people interested in management that tend to read up on the topic after working hours - however these are rather rare...
  
• Teams must be empowered - they must be responsible for the whole project and for the user stories they commit to. In return they must get what the need to get their tasks done.
  
• Newly formed teams inexperienced with Scrum have to get the chance to make mistakes - to fail - and to learn from hat.
  

A great way to explain Scrum really is as a two-fold process: First half is about getting a product done, reviewing quality by the end of each sprint during the review. Second half is about improving the process to get the product done. Meeting to review the process quality is called retrospective.

Management buy-in

The second topic discussed was on the role of management in scrum - and how to convince management of Scrum. To some extend, Scrum means loosing power and control for management. Instead of micro-manageing people it's suddenly about communicating your vision and scope. To get there, it helps to view lean management as the result of a long transformation:

• First there is hierarchical management - with the manager at the top and employees underneath.
  
• Second there is shared management - with the manager sitting between his employees enabling communication.
  
• Third there is collaborative management - here the manager really is part of the team.
  
• Fourth comes empowering management - this time the manager is only responsible for defining goals.
  
• Last but not least there is lean management - where managers are merely coordinating and communicating the vision of a project.
  

To establish a more agile management form, there are several tasks to keep in mind: First and foremost, do talk to each other. Explain your manager what you are doing and why you are working in pairs, for instance. Being a manager, do not be afraid to ask questions - understanding what your developers do, helps you trust their work. Scrum is established, however there needs to be a clear communication of what managers loose - and what they win instead.

Scaling can only be done via delegation - however people need to learn how to delegate tasks. In technology we are used to learning new stuff every few years. In management this improvement cycle is not yet very common. However especially in IT it should be.

Being able to sell Scrum to customers is yet another problem: You need good marketing to sell Scrum to your customers. "Money for nothing change for free" is a nice to read on formulating agile contracts. Keep in mind, that the only way to really win all benefits is by doing all of Scrum - cherry picking may work to some extend, however you won't get the full benefit from it. In most cases it works worse than traditionally managed projects.

After two very interesting and lively discussions moderated by Andrea Tomasini we finally had pizza, pasta and drinks - taking some of the topics offline.

Looking forward to seeing you in F-Hain for the next Scrumtisch in April.