We enjoyed preparing and giving this talk very much. Thanks very much to the people who attended and for the interesting questions and discussion, all of which contributed to the talk’s success.

It’s the first time that I have made a presentation using Prezi (http://prezi.com). Prezi allows the presenter to zoom around a large canvas and get away from the intrinsically serial nature of traditional presentation tools. It suits my style and was well received by all that I showed the results to (I’ve heard of some feeling symptoms akin to motion sickness as a result of the zooming and rotation). I’ll be continuing this experiment with my next presentation at Agile Central Europe in Krakow Poland on 8-9th April.

Many thanks also to those who mentioned our talk in their post-gathering round-ups. Here:

http://www.agilitrix.com/2010/03/team-chartering-and-agreements/

and here:

http://www.infoq.com/news/2010/03/scrum-gathering-buzz

An article, co-written by ScrumCenter founders Christoph Mathis and Simon Roberts, describing the Scrum transition at Allianz Deutschland AG, is now available for free download thanks to an agreement with SIGS-DATACOM GmbH.

The article, co-written by Gerhard Hastreiter (Allianz Deutschland AG), Chistoph Mathis (ScrumCenter GmbH) and Simon Roberts (ScrumCenter GmbH), first appeared in the January 2009 edition of ObjektSpektrum and can be found here.

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.

One of the simplest retrospective approaches is to get the team to make three lists:

• Continue – what has worked well and should be continued
• Stop – what has not worked well or has hindered us and should be stopped
• Start – what things have we not been doing which we should start to do

With the support of a facilitator, the team can produce the three lists on three separate flip-chart sheets. However, sometimes the team dynamics makes this difficult, for example if one or more of the team members are very dominant so that other team members are effectively excluded. Brain-writing is one way to help all team members to contribute.

In this article I describe how brain-writing can be applied as part of a Scrum retrospective.

Brain-writing proceeds as follows:

1. Each participant is given a sheet of paper containing a table with three columns “Continue”, “Stop” and “Start” (attached as Powerpoint in English and German).
2. Each team member spends up to 5 minutes writing entries in each column.
3. The sheets are then passed to another participant (e.g. to the left).
4. Each participant reads what has already been written and may then write additional ideas if inspired to do so (5 minute time-box).
5. This continues for at least one round – i.e. until the sheets are back at their starting points.

Once ideas have been generated using brain-writing, the retrospective can continue as follows:

• Consolidate the lists – producing three lists (“Continue, “Stop” and “Start”) on a whiteboard or flip-chart.
• Prioritise the list items by voting with coloured stickers or marker pen “dots” – each participant gets three votes per column.
• From the highest priority items (e.g. the top three items), generate a list of SMART (simple, measureable, achievable, realistic, time-boxed) actions.
• Consider creating Product and/or Sprint backlog items from the actions.

Brain-writing Retrospective Sheet (German and English) – Microsoft Powerpoint

I’ve facilitated several agile projects where the customer or product owner has come up with a user story something like:

As a web site visitor
I want to start typing without having to change focus
so that I can get the results that I need as quickly as possible

This is usually simple to implement (unless you can’t use JavaScript) and provides an immediate reduction in aggravation for users. For some applications this can actually make a difference to the business case. For example, if call handling time for a large scale call centre application can be reduced by just a second, it can result in significant cost reductions over a year.

I encourage all product owners to consider whether there is room for such a feature in their product backlogs!

Blogged with Flock

Tags: userstories, web, agile, Scrum

In traditional software engineering projects, there has been widespread use of peer review (design reviews, code inspections, code walkthroughs etc.) as a means of improving code quality. Pair Programming provides a more efficient means of reviewing both design decisions and code.

Over the last few years I’ve noticed a tendency in many organisations to dispense with code reviews without replacing them with anything, let alone pair programming. If developers don’t think that anyone else will have to read their code, code quality in terms of defect density and ease of maintenance will suffer.

The Toyota Production System and the Toyota Development System, initially developed in the 1940s and 1950s and publicized in the west in the 70s and 80s, were primary inspirations for the Lean and Agile movements. So is “The Toyota Way” responsible for Toyota’s success? According to a report that I overheard on BBC World Service Radio, yes, at least partially. They mentioned the Toyota Production System and stated that it is now used by most automobile manufacturers. Maybe the superficial details of the production system itself are even used by GM, but the Toyota Production System is based on much more which, according to anecdotes that I have heard, has not been adopted by GM.

The Toyota way is based on respect for their workers and embodies important principles such as self-organisation and adaptive processes that are so important when managing complex systems. It also applies the principle of eliminating waste, so if, for example, a machine needs to be moved to enable a team to do its job better, it will happen without jumping through hoops.

All of this does not sit comfortably with a prescriptive command and control approach, yet many Western organisations remain tied to such practices. In many cases, particularly when there is a crisis, the instinct of Western organisations (including governments) is to add additional controls to their processes (in the form of rules, laws etc.). This is often the opposite of what is required – give people the resources that they need, make them feel that they are truly valued and respected and they will deliver the results.

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.

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.