Monday, October 31, 2011

An Agile Transition done Right



A little over a year, I kicked off an agile change program at a leading swiss devices company. Two weeks ago, I had a chance to visit them during an open house on their new premisses.

This company was fully committed to walk the talk, they decided to do what needed doing.


In August 2010, we started of with a five day PSD (Java) Scrum.org training. I trained 12 very strong developers of various expericene levels. This training was intended to ascertain whether they really want to work in an agile manner. Brave move from management, but to no surprise the developers fell in love with Agile and Scrum and were hooked on day three of the five day training. This training is excellent!
After the developers gave their thumbs up, it took about a month to set everything in motion. This is is a mid size company with over 300 employees at their head quarters. Once we got the ball rolling the company was ready. They had torn down walls to create right sized team rooms, organized great Story Boards or shall I say walls. Again, they were serious. In the first two weeks, apart from coaching the teams, I trained ten people as Scrum Master (PSM) and ten more as Product Owner (PSPO). We didn't really know who is going to fulfill which role, we just knew that the future person would be coming from those groups. Also, the intention was to really create an agile culture and what could be better then to reach out and train and convince as many people as possible. After that I gave about ten introductions to Scrum, each lasting about two hours; the target audience was marketing, sales, support and other departments on the projects periphery.
For the frist two sprints -- 2 weeks in duration -- I was coaching a 100%. Essentially being a Scrum Master. After two Sprints I was only around at the beginning and at the end of the Sprint. During my absence the teams had the chance to walk on their own without training wheels, getting first-hand experience into when they started to struggle. After 5 Sprints the teams decided on their own who should replace me as the Scrum Master. In the remaing four Sprints, I worked closely together with my replacements. My presence became less and less. At the end it was about 20% of the time. By the end of last year, they didn't need me anymore and I moved on.
This whole engagment lasted about four month in calendar time and about two month of coaching from my side.

Now, during the open hours, I had the chance to meetup with a couple of guys from the old teams and we chatted a little. It was a great to see, that all of them really had drunken the agile CoolAid. They did not roll back one inch - instead they kept on pushing hard. Now, there are three teams and more coming soon.
For me and my company effective agile. this coaching approach has become my favorite modus operandi for change engagements.


By the way, the last two releases were two and six weeks early! It humbles me to know, that I was the initation.

Thursday, October 20, 2011

The right Sprint Length

In order to keep the blog short here is the answer:


     Let the Development Team decide


If you are curious why this is the answer then keep on reading.

Again and again, I hear from outsiders that we should extend our Sprint length. Usually, I like to work with two weeks. When I ask for a reason, the answer is typically the following: 'With all the meetings you don't have time to do real work, so I think you should add another week or maybe even two!'.

Interesting statement, but completely wrong and obviously from someone who does not understand Scrum. 

Here is Why:
1)  Apart from the 15 min Daily Scrum all meeting durations are proportional to the Sprint length. The Product Backlog grooming which is paramount to an executable Product Backlog and often neglected in literature is about 5% of the Sprint length in average by my experience 
Here a chart showing how the meeting time per day actually slightly increases when the Sprint is longer





2)  All of the above meetings are real work and important. They are the empirical process controls you need when you work in complex environments and domains. Especially the Daily Scrum is the catalyst for an effective and hence productive working day. The Daily Scrum is not disruptive it creates focus and team spirit. I just read the slides of a recent talk of Tobias Mayer. He stresses that Scrum is essentially five things.
  • self-organization
  • collaboration
  • focus
  • alignment
  • rhythm
Each of these points is addressed by one or even a couple of those meetings. 


3)  The rhythm is to be discovered by the team. In my experience two weeks is a great fit for most environments but if the team cannot find it's own rhythm and cadence within a given Sprint length, then let the team decide. Often they adjust their defined working rules, and sometimes they decide a different Sprint length is what they need. If so, let them choose whether they want to go shorter or longer. The rhythm is a function of the domain, the planning horizon, team configuration, dependencies, other Scrum Teams, and more. It cannot be decided by an outsider.


4)  Finally, the underlying problem is, that people with that recommendation are usually bottlenecks themselves. It is a latency issue by those very individuals. When problems do pop up it takes too long for them to turn around. Since a loss of a couple of hours or even days is more visible or shall we say dramatic in a two weeks Sprint then a four weeks Sprint. Those 'well' intended recommendations try to mask the problem and thereby slowly turn the project into a ScrumBut.

Sunday, October 16, 2011

Agile Night no Grupo RBS

Na próxima segunda feira, 17 de Outubro eu terei o prazer de participar no RBS Agile Night. Este evento é uma parceria do GUMA-RS, do grupo RBS e da PUC-RS (através da AGT).

As empresas Grupo RBS, Oncast e Thoughtworks irão compartilhar fatores impulsionantes e restrições na migração para uma cultura ágil. O evento termina com um bate papo no fo0rmato fishbowl sobre Agilidade.

As inscrições ocorrem no site da SUCESU-RS - http://www.rs.sucesu.org.br/inscricao/guma_agile

Para mais informações: http://xp-rs.blogspot.com/2011/10/agile-night-nesta-segunda-feira-dia-17.html

Friday, October 14, 2011

Kanban and Beyond at Agiles 2011

This week I was at Agiles 2011, the 4th Latin American Conference on Agile Methodologies.

I had the pleasure to give a 2 hour version of the Kanban and beyond workshop. It was very well received by the participants. I did do some improvements since the last time I run the workshop at a conference (the Agile Brazil 2011 conference).

For the 2 hour workshop at the Agiles conference, I decided to shorten the activity time and give only a taste of the full workshop. The results were superb! The participants really enjoyed it. The fact is that the workshop is better suitable for a 4 hours or a full day activity.

I have improved the presentation and the workshop. Now I have different versions of the workshop for different event slots. I have also created site for the workshop. www.KanbanAndBeyond.com on it you will find the workshop material, feedback, photos and much more.

Sunday, October 9, 2011

Scrum is Open for Extension and Modification

Today, Scrum.org and Scrum Inc. are announcing a formal model for modifying and extending Scrum. Scrum's creators, Jeff Sutherland and Ken Schwaber, are inviting practitioners from around the world to contribute to Scrum's future.


Scrum was first developed 15+ years ago, and it has been evolving and adapting ever since. Informed by their experiences and those of the Scrum community, Jeff and Ken have carefully codified the framework in the Scrum Guide, which documents the basic rules, artifacts, and events of Scrum.

Today's announcement marks a new era in Scrum's evolution by making available a public mechanism for providing feedback on the Scrum Guide and a model for proposing extensions to the basic framework.

The formal process for proposing and integrating changes into Scrum is available online at Scrum.org. To learn more about Scrum, or proposing your own contribution to Scrum, you can use the following links:

Read It - http://www.scrum.org/scrumguides/
Change It - http://www.scrum.org/scrum-guide-proposal/
Extend It - http://www.scrum.org/scrum-extensions/

We look forward to hearing from you.




Friday, October 7, 2011

Facilitation exercise – Triangle forming for self-organizing team

This exercise is to be used for fostering the conversation about self-organization

Given a group of people multiple of 3 (12 for example), the facilitator will run a similar activity twice.

First run:

The facilitator asks the group to walk (individually) in a random direction

When the facilitator says the magic word “triangle”, each group member has to find other 2 people and from an equilateral triangle (each person is a triangle vertices, and should point each arm toward the other two people representing the other triangle vertices; each person is a triangle vertice on one triangle only).

The facilitator takes the time of how long it took the group to from the triangles.

Second run

The facilitator selects one person to be the group triangle organizer.

The facilitator asks the group to walk in a random direction

When the facilitator says the magic word “triangle”, the group triangle organizer has to form equilateral triangles with all group members (including himself in one of the triangles).

The facilitator takes the time of how long it took the group to form the triangles.

Conversation to follow

The first run shows a self organizing group; the second run show a group guided by one organizer (the group triangle organizer).

Typically, the self-organizing triangle formation runs faster than its counterpart, and the team feel more engaged on the activity.

I find this activity very useful for starting a conversation about self organizing teams.

I learned this activity from Heitor Roriz, a friend and Scrum coach and trainer from one of his trainings. Kudos to him for applying a fun activity for fostering the conversation about an essential concept of successful agile teams: self-organization.