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.
Offshore scrum: A case study in lean thinking
Events, ScrumPresentation at the Scrum Day in Düsseldorf December 2009, by Andrea Tomasini (agile42) and Dave Sharrock (be2)
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.
Download: Offshore scrum: A case study in lean thinking
Interesting Scrumtisch in November – Some content
Scrumtisch BerlinThis 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:
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.
Measuring for Results
EventsAt the first South African Scrum Day, held in Cape Town on 1 September 2009, I gave a talk on the topic of agile metrics. You can just download the slides and save yourself the pain of listening to me!
Review Scrumtisch 16th June
Scrumtisch BerlinComments are very welcome
How we organize the Scrumtisch
Scrumtisch BerlinOf 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
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 :-)
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
ScrumI’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:
So while we continue to battle our demons, how about honestly calling some Scrum implementations SINO (Scrum In Name Only)?