Berlin Scrumtisch - open discussion #
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.