Workshop on Flow at the Agile Game night

Last week I participated on the Agile Games Night at Porto alegre, Brazil.

The event took place at the UniRitter university.

Congratulations to GUMA-RS and the amazing people running the Agile show in this region!

To name a few: @dwildt @lcparzianello @paulocaroli @jorgee_audy @flaviosteffens @rafaelpri

On this event, I run the Kanban And Beyond workshop as a 1 and ½ hour game.

The audience had a great time! (check out the results of the Return of Investment activity)

Below are some photos from this workshop instance.

Looking forward to the next workshop.

Creating an ATDD Ready Sprint Backlog

The arcticle about 'Creating an ATDD Ready Sprint Backlog' can be found here 
Enjoy,
Ralph

Ralph Jocham is the founder of effective agile. GmbH 

effective agile. believes that agile is more than just working in iterations, doing a daily standup or writing a unit test after the fact.

effective agile. believes that people are the most important part of a successful project and that we should focus on ways to enable them.

effective agile. believes that the world for knowledge workers is changing faster than ever. Only by harnessing the skills of each individual and putting trust into them, technology companies are able to survive.

effective agile. believes that we have to address our current believe system and that we need to challenge everything.

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.

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.