At the German Scrum Open Space conference on 11th July, Christoph Mathis and I presented our ideas on sustainable Enterprise Scrum transitions.
The ideas are based on our experiences leading the successful Scrum transition at Allianz Deutchland over the last 1.5 years and identifies some of the key success factors and pitfalls as well as outlining the approach.
We”ve adopted a beacons (German Leuchtfeuer) metaphor since our approach is based on successively illuminating different parts of the project and governance landscape of the organisation. Key success factors that we described include support from top management and the use of the right mix of training, coaching and mentoring for the people involved in the transition.
We’re speaking at several conferences and meetings over the coming months (including the Stockholm Scrum Gathering, XP Days Germany in Hamburg, OOP 2009 in Munich and Peter Stevens’ Scrum Breakfast in Zurich) where we will be discussing these and related topics. In the meantime, our slides are available and we welcome questions.
I recently led a test-driven development (TDD) workshop for the team that I am currently coaching. We’ve been working together for several Sprints (every Sprint bar none has resulted in valuable functionality that has been put into production). We’ve previously looked at unit tests in detail and I had made a strong recommendation to try to write the tests before the code under test. Over the last couple of Sprints, the quantity and quality of unit tests in the product has increased dramatically.
One of the outcomes of our last retrospective was that the team requested that we revisit the area, this time focusing on TDD. So I scheduled a couple of hours for a workshop.
I kicked the workshop off with a few slides to explain the philosophy behind TDD, explaining that TDD is not just about testing (or even mainly about testing) but has a great deal to do with design and documenting what services the code provides. I found a quote from Bob Martin that I really like:
“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function”.
The introduction led to an extensive discussion about the pros and cons of TDD. In this type of situation, I’m not looking to convince people that a particular technique is valuable (you can’t make people believe in something) but to get them to try it out and then reflect on whether it works for them and the team.
I fired up Eclipse and went through some examples (based on material from Frank Westphal’s excellent book Testgetriebene Entwicklung mit JUnit und FIT).
By the end of the workshop, everyone had agreed to give TDD a try in the current Sprint. As normal, we’ll reflect on our experiences at our end of Sprint retrospective.
I was recently invited to do another talk on agile methods at the Center for Digital Technology and Management in Munich, Germany.
This time, the talk covered the following areas:
- user stories
- agile estimating and planning
After examining some of the characteristics of good user stories, the students practiced writing some (with “As a …, I want …, so that …” clauses and acceptance tests on the back).
We then used the planning poker technique to estimate some user stories for the team’s first Sprint.
Once gain, thanks very much to Ana Balevic for organising and hosting the talk and to the students for some interesting questions and discussion.
I was recently invited to talk about Scrum and SOA at the Center for Digital Technology and Management in Munich, Germany. The CDTM is a partnership between two Munich universities and cooperates closely with industry. It’s aim is to “prepare the students for future leadership positions in their professional career.”
The talk was provided as a part of a course that introduces students to an agile approach to SOA development. During the course, real functionality will be developed and demonstrated to industry partners.
The talk covered the following areas:
- What is agile?
- Why do we do agile software development (what are the issues with traditional methods and how does agile make it better in many cases)?
- The agile manifesto, key values, principles and practices.
- Key success factors and pitfalls for agile projects.
- An introduction to Scrum.
- The Dysfunctional Scrum exercise.
- Case studies – different ways of approaching building an SOA-based system using Scrum, based on my experience coaching different projects and teams.
Thanks very much to Ana Balevic for organising and hosting the talk and to the students for some very interesting questions and discussion.
I’ve got reasonably fast Wi-Fi in my Pension room in Ismaning, near Munich. 3 Euros a day (excluding room).
A wonderfully sunny snowy morning in Ismaning near Munich.
The estimates are starting to converge but there are still some significant differences. The participants are discussing the high and low estimates.
It’s the end of the first week with a new client in Munich. Despite the storm on Thursday (didn’t impact Munich too much apart from the S-Bahn being suspended from 20:00 on Thursday night) we’ve made some great progress.
I’ve tried to do a lot of listening this week and have taken part in several meetings as an observer. Some of the other activities this week have included:
- Team formation. The pilot project will be reasonably large with in excess of 10 active team members. My recommendation has been to split this team into 2 Scrum teams, each of which sits together and tackles vertical slices of functionality based initially on particular functional areas. This recommendation has been, in principle, taken on board. We’re still sorting out some of the seating arrangements.
- Training workshops. We’ve identified three days of training to which the team members will be invited. The first of these, focussing on agile values and principles took place on Thursday. Unfortunately, the exercise that I usually like new agile inductees to do on the first day (based on the well-known XP Game), had to be abandoned due to the storm warning. We captured lots of useful insight into some of the key issues that will be encountered as this client tries to introduce agile methods. I’ll be maintaining a log of these issues and tracking how we address them. The next workshop will on Friday next week when we’ll be taking a closer look at Scrum and User Stories and putting the theory into practice with a fun exercise.
- Product backlog. We’ve started to create the product backlog. Today I facilitated a User Story writing workshop for one of the functional areas. This had real customer involvement and produced some really useful results. It went quite slowly but definitely a good start and subsequent workshops will get faster.
Other Munich observations:
- I last worked in Munich in 1993. Either it’s changed a lot or I have, or perhaps we both have. It seems much more open and more multi-cultural and a more comfortable place to be. I feel good here.
- I’ve been staying in the Derag Max Emmanuel Hotel in the Munich area Haidhausen. My room is effectively a small apartment with its own mini-kitchen and even a small terrace. Very good value (80 Euro a night), clean and comfortable – recommended. I found the hotel through ratestogo.com. All other web sites that I tried when looking for accommodation had very limited availability due to the Bau 2007 trade fair that has been taking place this week. The web site was uncomplicated, they have a fair concellation policy and they had accomodation available when others didn’t – also recommended.
agile, scrum, muenchen, munich
Monday was the first full day with my new customer in Munich. I’m going to be here on and off for the next 5 to 6 months helping a part of a large organisation transition to agile methods. It’s looking really interesting. Although this is going to be a challenging assignment (most agile transitions are!), there seems to be a genuine desire to give things a try. I have the feeling that we (that is the team including myself) are going to be able to make considerable improvements over their current process (by taking baby steps) and have a lot of fun at the same time.