The Separation of Power in Scrum

There is one element in Scrum which I really appreciate. It is the separation of power in Scrum. 

What exactly do I mean with this? Democracies are based on the separation of powers they require.

• Legislative
• Executive
• Judicative

Each one has their rights and responsibilities. The other two watch out and make sure, that third doesn’t abuse it’s power.

In totalitarian governments this is not given. One entity reigns over all three. The usual result is that a few benefit and many suffer - from individuals to whole economies.

What does this have to do with Scrum. Well, nothing - at least at a first glance. But if we apply this concept to classical management, the project manager has the possibility to act as a dictator. 

He or she can decide about all three elements: scope, schedule, people.

The image above is the incomplete ‘iron triangle of quality’. It tells us, you can choose two out of the three, the third has to give. For example, if we have a certain amount of scope to implement by a given date, we need to adjust the number of people working on it.

If all three are set then the quality of the product under development will be sacrified when things get tough. Quality is the forth hidden element. Often the manager tries to convince us about the attainability of the goal with sentences like ‘I know it is aggressive but …. ‘, ‘You are not a team player ….’ and more. 

Quality dies first on every software project. It is not transparent per se, it won’t show until very late in the project or even until the product has been released. This manifests in very high TCO (total cost ownership). Eventually the developers require to rewrite the piece of sh.. garbage software. (see my blog Resetting the Shitty Counter)

How is this handled with Scrum? In Scrum the Definition of Done (DoD) states certain attributes or activities which have to be present in order to guarantee a high quality, potentially releasable product. The compliance of the DoD is paramount to a high quality product with happy customers and low TOC. Now Scrum is not immune to crunch times, times when the Product Owner (PO) is tempted to push the Development Team a little further. In those situations it would be just to easy to abandon the DoD and reduce quality to keep the date and make the Product Owner happy.

This is when the Scrum Master comes in. She will make sure that the DoD stays enforced and keeps the PO at bay. Essentially she protects the people (Development Team) so that they can work in the agreed way and thereby create a high quality product. 

In Scrum the Product Owner has the right to decide which feature gets developed in which order. His tool for that is the Product Backlog.

and the Scrum Master ensures that the Delelopment Team has the right to estimate the work according to the Definition of Done and to implement it according to the Definition of Done.

The separation of power protects the Development Team and allows it to deliver high quality product increments throughout the project. This sustainable approach guarantees high quality software with high ROI, low TCO -- easy to maintain, easy to support, easy to enhance -- for a long time. Best, you should see happy, engaged developers.

In the end everybody wins!

Retrospective: understand perceived facts before reasoning

Reasoning is the core activity for a retrospective. But it is important for a group to have a common ground on what they are reasoning about. The group has to first look at facts and perceptions.

All argument and reasoning must be based upon certain perceptions. Without these, there cannot be any argument. Reasoning is the method of comparison between certain facts which the group has already perceived. If these perceived facts are not there already, there cannot be any reasoning.

When planning a retrospective, choose an activity to help the team uncover facts. Facts help the group understand perceptions, and upon that the group will be ready to engage into reasoning.

Timeline activity for retrospective

Below is a deck for a timeline activity I used on my last retrospective.

Timeline activity

View more presentations from paulocaroli.

Previously I have used this approach for a collocated retrospective. I would draw a timeline on a white board, create 4 areas on the board (people, process, tools/technology, and other), and use two colors of notes (well – green /not so well - gray) to start with, followed by a third color for action items (yellow).

Here is the snapshot of the retrospective activity (this picture was generated by Google Drawing):

TWBR colleagues delivering Tech Radar talks in Brazil

Back in 2008 I would dream about bringing Thoughtworks to Brazil. Dreams come true!

Today I am glad to watch 5 remarkable techie colleagues (all from Thoughtworks Brazil) shaping, spreading the word and fostering conversations about languages, technologies, tools and platforms.

The Thoughtworks Tech Radar road show (now in Brazil!) starring Ronaldo Ferraz, Rodrigo Kochenburger, Marco Valtas, Carlos Villela and Adriano Bonat.

Porto Alegre
Wednesday, March 28 2012

Rio de Janeiro
Thursday, March 29 2012

Sao Paulo
Thursday, April 12 2012

Belo Horizonte
Friday, April 20 2012

Register here.

The 1000 students challenge (2)

In May of last year I was able to run my first Pay It Forward Scrum Training at the University of Bern in Switzerland. I had blogged about this event there:  The 1000 Students Challenge

Last week-end I had the chance to do the second run at the University of Applied Sciences (FHNW) in Brugg Switzerland. 20 students volunteered their week-ends to learn about Scrum by attending the Scrum.org Professional Scrum Master Training or short PSM. It was great fun for them and myself and it is good to know that 20 future IT specialists will join the workforce pre-equipped with Agile and Scrum.

967 more to go ...

PS If you are interested in hosting such an event at your institution please contact me at www.effectiveagile.com

Scrum Bolivia Day 2012

This Monday I participated on the Scrum Bolivia Day 2012.

The event brought together many professionals from different companies interested in learning, and expanding Scrum in its various aspects.

Below are the Scrum Bolivia Day 2012 speakers with their respective presentations

• Emilio Gutter - Introducción a Test Driven Development
• Israel Antezana – Scrum no es suficiente...
• Luiz Parzianello – Agile & Business Analysis: A Successful Combination
  
• Heitor Roriz - Scrum Values
• Martin Alaimo – Adoptando Scrum y no morir en el intento
• Paulo Caroli & Johanns Arispe – Scrum with Kanban, Small Adjustments Big Improvements
• Samuel Crescencio – The Lean Pyramid

Congratulations for Juan Banda and his team for organizing such a great event!

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