Tuckman savings via feature teams

On the past 7 months I have been working with a SW delivery team on a way that is conceptually different than many of the teams I have worked before.

The main difference:

Instead of forming a team to deliver a feature, a performing team works on a feature after another.

Let’s take a look at options A and B below regarding team, project, and feature:

Option A: Shape a team according to the feature characteristics and the project time.

Option B: Shape the feature according to the (performing) team characteristics and the project time.

The team formation is the main difference between options A and B. A is the typical project team formation, where a team is selected for a target feature. B is the feature team, where the feature is selected for a target team.

Mind twisting, isn’t it?

A team selected for a target feature

versus

A feature selected for a target team

it seems similar, but it is drastically different.

Here is why:

The Tuckman model for group development (Forming – Storming – Norming – Performing) depicts stages for a team developing their work relationship.

My original hypothesis (from 7monhts ago) is my realization today:

I have been saving project time and money by keeping a fixed team and selecting features for the team.

Thanks Tuckman for helping me understand the savings! The forming and storming phases are not consuming much time (and money) anymore. In fact these savings goes towards delivering more features. The team is already on a performing stage, and our track record is showing reductions on features lead time and cycle time. 

A great Ice breaker for Energy Boost and memorizing names

Paulo: Zip Roger

Roger: Zip Marco

Marco: Zoom Mathias

...

Zip Zap Zoom is a great energy boost ice breaker. I made a small addition to it for helping the team memorizing each other names.

After the Z__ command (Zip, Zap, or Zoom), the person passing the imaginary relay has to say the target person name.

This keeps the energizer fun while helping the team memorize each other names.

Inception activity for discovering User Stories

On this blog post I share an activity I used on my last Inception.  I found this activity very useful to kick start the User Stories creation.

What are the goals of this project?

This question  triggered the conversation about the business goals for the project. 

Who will use this system? What are their roles?

These questions disclosed the personas (with their roles) for the project. Goals and personas were written on post-its. Large pink post-it was used for goals, and small colorful post-its were used for personas. This is shown on the photo below.

After having written a few goals and personas, the team started brainstorming for creating User Stories.

As a X, I want Y so that Z.

Note that X and Z were already known variables (personas and goals). We were now looking for the Ys.

So, what does X want from the system in order to achieve Z?

For example: What does an OPS dude want from the system in order to monitor the browser against system overflow?

User stories were being written...

Soon these stories were combined into features (blue post it). Usually a feature would have from two to eight stories.

This whole process was not linear and definitive. Index cards (for stories) and colorful post-it (goals, personas and features) were written and re-written a few times. Below are a few photos showing index cards and post-its.