Back to the basics: What made this Agile Inception especial?

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

Cross-Functionality in Scrum

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.

Google Drawing – another great tool for distributed retrospectives

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.