The following two pictures depict the latest Inception I participated at.

A little bit of history: For the past two years I have participated directly in 3 Inceptions, and indirectly in 5 inceptions. By directly, I mean, I was sitting in the war room for most of the Inception sessions. And by indirectly, I mean, I was participating on the Inception sessions over video from a Nearshore location (onshore is San Francisoc, USA, nearshore is Porto Alegre, Brazil).

I attribute the success of the last Agile Inception to 3 things: collocation, war room, and colorful post-it.

Collocation

Don’t under estimate the value of a face to face interaction. I am currently in Brazil and I am used to having effective meetings over video and phone with USA. I know that technology can bring people closer together, and, perhaps, we can work together without sitting next to each other. However, the face to face during Inception will bring the team together in a way that it will be worth each penny spend for making the collocated Inception a reality.

I compare it to dating and internet dating. Relationship development goes to another level when the whole team is at the same room. Think creatively on how to save on costs. In our case we were able to reduce the collocated period by having a pre-Inception period before the collocate Inception. Spikes, research, data gathering, codebase analysis were the sort of activities we did in the pre-Inception week.

War room

Keep a single room for the team during the intense Inception period: the war room! The room should fit all team comfortably. It must have a clean table and wall space. The room should also have a cabinet or a box with index cards, colorful post-its and pen.

The war room makes the environment for collaborative sessions. It also avoids the waste of time of people moving from one room to another. Another important point is about carrying the information between rooms. You can either carry all hand-written notes (index cards, post-its, flip-charts, etc) and put them back in the wall and tables, or upload them on a digital format and carry it on your laptop. The former option is a waste of time. The later lessens people interaction. There is no replacement for writing on and tearing apart colorful post-it or index cards. Once the information goes to the computer, it will not get back to paper. People interaction reduces as there is nothing on the table to gather around.

colorful post-its

Do not bring a list of existing user stories to the Inception. I am sure there is a list somewhere (excel, Jira, or alike). Use it for reference, but don’t use it for driving the Inception sessions. Print a few copies and bring them to the war room. Let people consume it if required. Try not to read items from a list during a collaborative session. In fact, do not build a list while in a collaborative session.

Group people around colorful post-its. Write and place post-its either on the table or at the wall.. Talk about them. Write a few more. Tear them apart. Make use of colors. Reorganize it. The collaboration from using such basic, low-fi technology— colorful post-its and pen—cannot be matched by any digital alternative (file sharing, projector, spreadsheets, etc).

The picture below depicts a great example from my last Inception. Without a previous encoding, the team decided to use the colored small post-its for personas. User Stories (in green post-its) were placed on white index cards containing numbers and estimated (with notes on the back).

On future posts: user story mapping for driving Inception, and a few notes on Inception facilitation

Scrum recommends that a team should feature all the skills required in order to deliver the releasable product increment by the end of the Sprint. 
Why is it a good thing to have all the skills needed? It is all about dependencies. We try to design our software systems to be loosely coupled and highly cohesive. The same principles apply to team composition. We want our team to be like a special unit, self sufficient and able to deliver on the chosen assignment.So, what would happen if one significant skill is missing from the team? The team will have a strong external dependency and will need to ask for support from external sources. This is a huge risk. Will the team get access to the person at the right time for the right duration? This creates an additional drag factor and affects the delivery date or reduces the scope of the product to be delivered.
Scrum does not require cross-functional teams, it only recommends them. In practice they have shown to be a significant boost for productivity. Especially in combination with self-organization.
Often it is misunderstood that cross-functional means that any person in the team needs to be able to do all the upcoming work. This is wrong. The unit that needs to be cross-functional is the development team. The dev team has the responsibility to self-organize in order to maximize the usage of its skills.  Hence, the team might be composed of specialists only, however the sum of the individuals needs to possess all required skills.
Nevertheless, as described above, if you only have specialists then you will have rather large teams, as for every skill you will need at least one developer. This will cause larger than needed teams and probably all other kinds of problems: part time team members based on FTE mathematics, work organized by activity not by feature, bad ‘unskilled' estimates, ...
Therefore agile teams favor generalists, developers with a rounded and versatile skill set. I like to use the term specialized generalists, strong all-rounders with one top notch special area.

Yesterday I used Google Drawing for a distributed retrospective. I was very pleased with the tool.

The team members talked over a phone bridge (skype or similar would work as well).

Google Drawing was used to collect data on the main data gathering exercise for the retrospective.

Here is the picture generated at the end of the retrospective.

How did I use Google Drawing?

1. I created a new document (empty canvas)
2. I prepared the canvas; in this case I placed a picture representing the speed car – abyss retrospective exercise in the middle of the canvas with 4 text boxes identifying the 4 exercise quadrants.
3. I shared it as a public document and emailed the link to the whole team
4. I gave the instruction verbally and asked people to use Text Boxes for their notes
5. I changed the text box color to blue for the notes which became action items
6. I exported the drawing as a .png and emailed it to the whole group

Simple is good!

The only problem we faced: a few of us got an error message when creating a text box (I believe this was due to all 10 team members creating text boxes at the same time). But this only happened a few times. A simple refresh took the problem away.

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.

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!

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.

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 BurndownCurrent 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 BugsUp 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.

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.

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.

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