Scrumtisch Berlin #
After quite some time off I went to the Scrumtisch Berlin. The event was
incredibly well visited - roughly 50 people filled the upper floor at Cafe Hundertwasser. Today’s event was organised
such that participants first collected discussion topics, prioritised them together and then discussed the top three
items in a timebox of 15 minutes each.
Topics collected were:
- Best tricks to make teams self
organised (20 votes)
- What is QA doing fulltime in a team (13 votes)
- Ops and planning in a team (15
votes)
- PO disappears and takes backlog and vision with him - what now? (7 votes)
- Working with
non-Software teams (17 votes)
- Pimp up my retrospective (12 votes)
- Multiple teams on one projects and vice
versa (4 votes)
- IBM doing Scrum/ massive Scrum (9 votes)
- Feature knowledge vs market knowledge - what is
more important in a PO if you have to choose due to people constraints (9 votes)
- How to convince a team to do
more (3 votes)
- Why is agile good (10 votes)
Compared to previous meetings quite some topics repeat. About half of the attendees were there for the first time - so it seems there is a common set of questions people usually run into when rolling out Scrum.
Self organising teams
Seems like this is one of the most common questions run into when rolling out Scrum - how to really get to self organising teams. The question can be answered from two positions: What are the pre-requisites it takes to enable teams to become self organising? How to actually transform teams that are used to a command and control structure and are reluctant to transform?
The discussion, mainly led by Andrea Provaglio, CSM trainer focussed mainly on the first part of the question. Even when limiting discussion that way, the answer will still depend heavily on the organisation structure, number of management levels, team sizes.
Marion made the topic a bit more concrete: Given the flexible vacation planning approach of Netflix, her question was whether that sort of loose approach could work in a typical German company (after all we have 30 instead of <20 vacation days, we have fixed holidays, she as a C?O of course wants to avoid customers being left alone when the whole team is on vacation.) Andrea re-phrased agility a bit here. His proposal was to not allow people to take their time off just anytime but to give them the freedom to figure out when to take time off. He identified five principles for leadership:
- Clearly setting a goal (in that case: Everyone needs to have a vacation plan at a
given date.)
- Provide the team with all resources, information and with the environment they need to accomplish
their task.
- Define constraints (“there must be at least one guy in the office on any given working
day”)
- Check back regularly
- Make yourself available to answer any questions
The discussion on teams reluctant to adopt self organisation was separated out and deferred. His point was mainly about enabling and encouraging self organisation. Enforcing self organisation however is not possible.
Scrum in non-Software teams
Though phrased very broadly the topic quickly turned into a “how to do Scrum for hardware” discussion. Main problem here is that the further down you go the longer design generally takes. Even just routing lines on one decently sized circuit board can take several weeks. Mainly three possible ways out of the problem emerged from the discussion:
- Loosening the definition of done - “potentially shipable” may not mean sellable
or even really shipable. I don’t think one should go down that slippery path. Only by actually shipping can I get the
feedback I need to improve my design. So instead of loosening the definition of done we should instead start thinking
about ways to get faster feedback, reduce risk and introduce shorter iterations.
- Another way is to look for ways
to reduce iteration length, even though we might not get down to software release cycles, and align releases such that
integration can happen earlier.
- The third way out could be to realize that maybe Scrum does not quite fit that
way of working and use a different process instead that still provides the transparency and fast feedback that is
needed (think Kanban).
Overall the most important result of the discussion was that within 15min discussion the issues cannot be solved. After all the solution will depend on what exactly you are working on, who your suppliers are and what your team looks like. Most important is to recognize that there is a problem and to work on removing that impediment - most important is to identify issues and to improve your process.
Operations and planning in Scrum
The last question discussed involved operations and Scrum planning: Given a team that does software development but is interrupted frequently with production issues - how should they work in a Scrum environment.
There are multiple facets to that problem: When it comes to deciding whether to deal with something immediately or not it makes sense to weigh size of the issue against amount of work it takes to resolve it. “Getting things done” states that the minimum size of an issue to deal with instantly is 2min of work. Issue with that is that the assumption of GTD was that issues flow into and inbox that is dealt is when there is time. In production environments however these issues usually trickle in instantly interrupting developers over and over again incurring a huge cost due to task switching.
One way out might be to have an event queue and assign developers (on a rotating basis) to deal with the issues and leave time for others to work in a focused way. Make sure to rotate frequently instead of by sprint - otherwise you run into the problem of making the team unstable thus delivering no stable amount of business value each sprint.
Another obvious way is to account for frequent interruptions and include a buffer for those in your plan. The most important benefit of that approach is to make the cost of this working mode clearly visible to management - leaving the decision how to deal with it up to them.
Other simple fixes include introducing some level of indirection between the actual developer and the customer raising the issue, documenting solutions as well as incoming issues for better visibility, introducing a single point of contact capable of prioritising.
Coming back to vanilla Scrum however there is one interesting observation to be made: The main contract with iterations is for developers to be able to work in a focused way. Instead of having their tasks switched each day they are promised a fixed period of time to solve a given set of stories. In the end a sprint is a compromise between what management may need (change their mind on what is important frequently) and what developers need (working on a set of defined tasks not interrupted by re-priorisation). If the assumption of focus does not longer hold true, Scrum might be the wrong model. If what needs to be done changes daily, Kanban again might be the better option. Still making sure that the cost of task switching is visible is vitally important.
To sum up a very interesting Scrumtisch - in particular as agile methods really seem to become more and more common also in Berlin. Speaking of challenges: As user groups grow sometimes their character changes as well, in particular when built around participation and discussion. It will be interesting to watch Scrumtisch deal with that growth. Maybe at some point splitting the audience and having separate breakout sessions might make sense. Admittedly I’d also love to know more on the background of the audience: How many are actually using Scrum in the trenches vs. teaching Scrum as coaches? How long have they been using Scrum? In what kind of organisation? Maybe a topic for next time.