Monday, December 19, 2011

Agile Micromanagement, the good and the bad

Jim Highsmith wrote an interesting post about micromanagement. He mentioned Steve Jobs and Bill Gates are good examples of successful product manager micromanagement. I totally agree with that.

He also talks about the Agile process micromanagement. Experiencing both worlds, waterfall and agile as a developer and a manager. I have a strong opinion about it. Agile is all about micromanaging!

Consider these:

  • You are coding and someone is talking about your code as you type it (Pair programming).
  • Every day you stand up and tell the whole group what you did yesterday and what you will be doing today (Daily Scrum meeting).
  • You retrospect about what you did well and what you can improve on (Retrospective)
  • You show everybody exactly which task you are working on and how it is progressing (Visible card wall)
  • You respect work in progress limits (Kanban WIP limit)
  • You make a code commit and let everyone know about it. (Continuous Integration)

The more I think about it, the clear it is to me: Agile is all about micromanagement. The good or bad depend on how people adopt its principles and practices. I have experienced many benefits that come from such micromanagement. In fact, when I look back at all projects I participated on, the projects I consider more successful (people enjoying working, delivered great products and improving the work process) are the ones with lots of micromanagement.

The Weight of the Christmas Cake

At my daughters school they organize a charity event every year. There are all kinds of different foods, games and lotteries were you can spent money for the good cause. Since it is a british school the mandatory guessing of the Christmas cake weight must not be forgotten. 




In Agile and Scrum we praise ourselves about our estimation skills. It is not that we claim to be infallible. No, we also claim that laws in mathematics help us to be precise. One in particular is of interest: The law of large numbers.
The cake weighing proved to be change to put this practice under test.


This year we had 45 guesses and the weight from all the guesses is 3'742 kg. The real weight was 3'520 kg. The guessed weight is 94.1% accurate. Pretty impressive!



Friday, December 16, 2011

A good lightweight recognition exercise for your next Retrospective: tokens of appreciation

Today I read a blog entry which reminded me about a good lightweight exercise I have used in Agile retrospectives very for recognizing and fostering team collaboration.




It is called the token of appreciation. Here is how it works:

  1. Bring a chocolate box to the retrospective
  2. Ask people to form a circle.
  3. You can start as a facilitator by saying: “I would like to give a chocolate for NAME as a recognition on that time when he/she helped me with…
  4. Then you give the chocolate box to that person and ask him to repeat the gesture.

I found this exercise especially useful for end of projects or end of release exercise. The participants usually enjoy it and talk in a positive way about the good things their teammates did and how they appreciate it.

This blog entry about IGN describes another implementation of the same idea: token of appreciation for for recognition. A big difference is that the tokens are not eatable and translate to money. I am interested to hear the drawbacks of this as a bonus policy and alternatives to it.

Monday, November 28, 2011

Agile A3 Sprint Report

I really enjoy working with A3 Reports. They have the habit of making you to distill out the crucial information, to really drill down.
There are different kinds of A3 reports. The book 'Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System’ describes three different report types. Problem-, Proposal-, and Status Report. The Problem Solving is the one I use most often.

So what is an A3 report. A3 Reports are size limited and have to fit on an A3 size of paper (for US folks, it is 11.69 × 16.54 inches). The size limitation requires to only present important informations. Furthermore, the use of charts, graphics and other none textual descriptions is highly encouraged. The less words the better. Since the Problem A3 Report describes the current and the target situation they serve as excellent PDCA (plan do check act) tools.

In my profession as Scrum coach, I grew tired of all the different and bureaucratic status reports. Usually the decision makers require lots of text and a traffic light. The text does not get read and all decisions are based on a single color. So, my idea was to create an A3 Report which is hardly text and more differentiated then only one color. Providing a quick and easy way for more information width. 

This is how it looks like:


















Top Left - Sprint Burndown
Current Sprint burndown. Blue remaining work in hours, Green remaining Story Points

Top Right - Release Burndown (Burnup in this case)
Up to date, including last Sprint, release burnup

Bottom Left - Risk list 
Up to date, risk list a la Frederic Brooks. New risks are continuously discovered and either handled by outside help (i.e. by the Scrum Master) or they get put into the Product Backlog and mitigated when the Product Owner puts them into a Sprint. The risk list is dynamic and subject to change from Sprint to Sprint. (*) Mitigated risks are kept on the list.

Bottom Right - Open Bugs
Up to date number of open bugs. If I can have my way on a project, the 10-Finger-Rule applies. The moment you run out of fingers to count bugs, you need to fix bugs first. This guarantees clean, maintainable and sustainable code. If a bug is rather tricky to fix, it can be put into the Product Backlog analog to a risk. Again, the Product Owner then schedules the fix, if she sees it to be appropriate. Also, this avoids the growing number of bug triage meetings towards the end of an project (**). If you work on an legacy project with X bugs, the rule changes to X+10. Done right, X will decrease over time and product quality will go up.



(*) On many projects the institutionalized company process requires a risk list. So, at the early beginning of the project a risk list is compiled, checked off on the check list and then put into a drawer. No transparency and accountability.

(**) On many projects you you have severity levels from P1 to P4. With P1 being worst and P4 minor. Usually, you have a company mandate, that no software can be shipped with open P1 and P2 bugs. Guess what ... in the growing number of meetings after each bug fixing cycle, panic tends to creep up. The human reaction is to ‘mis’-label P2 as P3. Problem fixed, process followed.

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.