Offshore scrum: A case study in lean thinking

Presentation at the Scrum Day in Düsseldorf December 2009, by Andrea Tomasini (agile42) and Dave Sharrock (be2)

Scrum Day Düsseldorf Scrum Day Presentation

Abstract of the speech

While the cost argument for moving traditional development teams offshore is well-known (and generally, still quite strong), the difficulty of maintaining high bandwidth communication with offshore teams using agile development methods has often been considered a substantial barrier to effective development. At be2, a Munich-based online international matchmaking service with an IT organisation based in Armenia, we choose to challenge these assumptions. With the help of agile42, a pilot agile project with two development teams was planned working with the product teams with the most critical business requirement, a complete rebuild of the core service estimated to take over six months before any major result was delivered to our customers. At the end of the pilot release sprint, the first changes to the site were live barely six weeks into the project. And as we start the final transition of the remaining teams, the pilot teams have continued development sprints with the result that the next release includes the majority of the planned design changes, just two months into development. We will present a review of the agile techniques we used, and those we adapted , to achieve a successful transition to scrum-based development. We will focus on the benefits and difficulties of building and maintaining offshore agile teams, and provide some insight into overcoming the challenges of offshore agile development.

DownloadOffshore scrum: A case study in lean thinking

Interesting Scrumtisch in November – Some content

This evening agile42 organised another successful Scrumtisch: Usually we either meet for timeboxed discussions on Scrum and agile development questions or a speaker is invited to present his favourite Scrum or Lean or Agile topic.

Today Markus Frick gave a presentation of how Scrum was introduced at SAP, a German software company. They started implementing Scrum in a “small” team of about 60 people, organised in about six to seven teams. The idea was to get people together who are already sort of familiar with agile technologies and let them evaluate what works in the companies context at what doesn’t. The conversion started with trainings, teams were organised by features as opposed to components. The main goal was to get people to learn Scrum and then spread the idea across the whole company.

Soon upper management were fascinated by the methodology – not shortly after that the goal was reset to converting 2500 employees working at four different locations (Bangalore, Berlin, Waldorf and Sofia/France) on diverse topics ranging from developers to managers to agile methods. The question thus turned from scaling Scrum to quickly scaling the conversion process: Where do we get enough trainers? Where does Scrum expertise come from? How should communication be organised? How do we adapt our sales and governance processes?

The way to do this chosen back then was to use Scrum itself for the conversion process. That is to introduce teams for training and conversion and let them work according to a backlog. Also managers were set up to participate by organising work according to a backlog containing management tasks. This first led to quite some confusion: Conversion does take time and working according to sprint backlogs makes it pretty much obvious how much time it actually takes and how much time people really spent on these tasks. On the other hand, the whole process was made very transparent for everyone – and open for participation.

The process started about two years ago – it has not finished to date and processes continue to evolve, get improved and refined as people go along. A very rough estimation was that it might take another three years to get to a stable, clean state. However most – if not all – problems were not caused by Scrum. They were made visible and trackable by Scrum.

The main take-home messages were that Scrum does bring improvement:

  • It makes goals transparent and communicates clearly the current state.
  • You get a short feedback cycle so people actually see where problems are.
  • It inherently allows for reflection and analysis of problems.
  • As introduced here it also made the work of management people transparent by making backlog and velocity of managers accessible by everyone.
  • Internal training helped to get feedback from teams who are already practicing what is introduced.

Among the people who were very skeptical there usually were quite a few people from middle management. Uncertain about how future development should work they usually feared a loss in influence. Most positive feedback came from developers themselves: After explaining what Scrum is all about, which includes shore release cycles and fast feedback, most developers that were in the teams already for quite some time reacted by stating that this basically resembled development “in the good old days” with a bit of development process added on top.

If you are interested in hearing more stories on how Scrum is or was introduced in companies of various sizes, I would like to recommend visiting the German Scrum Day in Düsseldorf. The talk by Thilo Fromm gives a nice overview of how a transition from traditional Waterfall to Scrum can look like. And agile42 Andrea Tomasini will talk about the Scrum implementation in distributed teams at be2 ltd.

Review Scrumtisch 16th June

Hi everybody, I think you agree, that the presentation of Philippe Kuchten yesterday was great, very informative and interesting. Here are some pictures and the link to the presentation from the Scrumtisch yesterday.
20 Attendees at the Scrumtisch Berlin in June
Philippe Kruchten was talking about: What color has your backlog
Interesting discussions and great food and drinks
Philippe held the presentation at the Orlando Scrum Gathering too. Here you can download the presentation
Comments are very welcome

How we organize the Scrumtisch

Some information on what you can expect when visiting the Berlin Scrumtisch.
  1. Finding the topics
    Of course, we appreciate proposals upfront for the upcoming Scrumtisch, but mostly people are busy and therefore we collect wishes and questions at the beginning of the event. We write these questions on the “wall” and after we prioritize them. We can make use of an electrostatic whiteboard, and a projector, so if you want to prepare something, you are really welcome, just post your idea into the Scrumtisch website
  2. Timeboxed discussion
    The 2 highest prioritized “Topics” will be discussed. The others are ending up in a backlog for the next Scrumtisch. We focus on each of the 2 topics for 30 min. One of the group is moderating the discussion and takes notes, ideas and hints on the wall. Someone should also take care of writing things down and posting them on the Blog, but unfortunately not always happen… we can improve this :-)
  3. Open talks and good food
    After the “official” part of the Scrumtisch we are just sitting together, talking in small groups about the topics or other issues, and enjoying very nice italian food & drinks.

So everybody is welcome to join the scrumtisch, share experiences and lear new things.

Keep it lean and agile :-)

Lamentations of flaccid Scrum and a case for SINO

I’ve been updating myself on the activites in the Prince2 camp to update this project management framework. One thing that stuck is the lamentations about the large number of PINO projects. PINO is an acronym (actually an initialism) for Prince In Name Only. In the Scrum world this has commonly been called ScrumButt, drawn from “we’re doing Scrum, but…” as well as the frequent desire to kick such teams in the butt!

Martin Fowler, one of the Agile Manifesto signatories has blogged recently on “flaccid Scrum”. FWIW, I agree with him.

We must constantly remind ourselves (and those whom we seek to influence) that:

    • Scrum is silent on which “software engineering” practices to use, but not on their use.

 

    • We must continuously assess our way of working against the Agile principles.

 

    • Undone work (aka technical debt) will continue to cripple delivery of value as long as we continue allow it to accumulate.

 

    • Scrum is just a tool to expose deficiencies and dysfunction in the team and the organisation – the problems remain ours to tackle and solve.

So while we continue to battle our demons, how about honestly calling some Scrum implementations SINO (Scrum In Name Only)?