One Week Inception - presentation

Below is the one week inception presentation that Taina Caetano and I (Paulo Caroli) have delivering on a few events, including the AgileBrazil 2013.

The coolest thing about this presentation: it is a sequence of photos taken on real Inceptions.

Agile br one_week_inception from caetano_tc

User Stories and Business Hypothesis

As I find myself diving deeper into the Lean Start up and the Lean Analytics world, I start questioning some of the Agile practices that been  have followed me on every single Agile project I worked on. For instance: the User Story.

As a < type of user >,

I want < some goal >

so that < some reason >.

This User Story format was created by Mike Cohn years ago [Users Stories Applied], and ever since it has used by many Agile teams. Typically, a Product Backlog has a list of User Stories to be worked on.

Nevertheless there is another kind of work which Lean enthusiastic are bringing to everyone’s attention:  hypothesis.

Hypothesis is a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.

I have learned the following representation from Alison Vale and Rodrigode Toledo.

Basically I was seeking a better template for a hypothesis. The User Story format was not working for this one. I need a good format to describe the ?, the -> and the ! – my hypothesis, the work needed in order to get this hypothesis in play, and the way to validate the results.

So here is my recommendation for a simple and generic hypothesis format:

If < I do this > then < this will happen >

I am currently calling these Business Hypothesis (please share if you have a better name for it). It includes the ?, the -> and the !; being the ? and the ! explicitly on the text, and  the -> should be handled as details for that hypothesis. This is similarly to User Stories, where the implementation details are not contemplated on the format as a… I want to… so that…

This has been working well for the teams I worked with. Please share your experience with hypothesis. Has this or other formats worked well for you?

Esther Derby on self organizing teams

I was nodding my head and agreeing with so many points raised by EstherDerby on her Self Organizing Teams session on the 2012 NDCOslo conference.

 

Esther Derby - What Does Self-Organizing Team Really Mean? from NDCOslo on Vimeo.

Please find below a few notes from her great presentation. 

Team success:

60% - Design a team

30% - Launch a team

10% - Coach a team

Framing the goal is very important to the team success…

…The art of coming up with the minimum specification for the team goal. Leave some creativity to the team!

We should work against a common dynamic where the manager looks down at the team.

There is a balance when self organizing between management work and technical work… It is always a balance. We should be careful and clear on delegating decisions.

A few balance axis that always take place on teams:

1.                  Learning versus delivery… the ability to learn together is one of the core improvements for a team… Teams do learn to learn together over time.

2.                  My specialization versus our work… what is the shared definition of done? The answer to this question brings balance to the team… as a team you  are developing capability to speed up; you bring everybody up… overtime there is a diffusion of skills and having that redundancy creates flexibility in the team… flexibility leads to speed, to better decisions.

3.                  Autonomy versus responsibility… a few things that help balancing this: (1) being clear about the decision boundaries, (2) having a robust feedback loop… when should a manager step in? too soon or too late is not good… there is a balance act for managers to know when to step in.

Continuous Huddling

Continuous Huddling is a software delivery practice where the members of a team huddle frequently.  This practice encompasses analyzing, guiding the development, validating and communicating about the work requirements with the right people at the right time.  

Teams that are successfully applying ContinuousDelivery certainly have champions driving Continuous Huddling. The champions typically have great analytical, communication and organizational skills. One or more champion might entice it; nevertheless, the whole team adheres to it.

Leader, your team is not in the meeting room!

Leaders should stop wasting so much time on meetings. First, the meetings for planning how the team will work. Soon after, the meeting for following up on the previous meetings. Then, the combination of people and meetings just explodes. These innumerous s meetings are the biggest waste for leaders.

Instead, a leader should spend time on the ground with the team. Try to understand and improve processes and how people collaborate. Thus avoiding the distant management purely based on meetings.

Make the work and the workflow visible. This is a crucial activity for a leader. Say no to the meeting invites. Instead, spend your time working with the team members. Look for ways to make the process (and the team work) more visible. Make information more transparent. Encourage direct communication. These allows for greater collaboration.

Ask why! Seek to understand what is happening on each workflow step; ask why. Then ask again. Help the team members better understand their work and the reasons behind it. This, plus the visibility will enable them to understand each other, therefore better collaborating towards the common goal.

Time is limited. And you can have a great impact on your team’s work. Say no to ineffective meetings. Instead, spend your time on the ground working with the team.

fire prevention and firefighting

Moving around large Agile projects, I came across a common situation that hinders the team performance.  Individuals cannot allocate time for improving their work (and avoid future problems) because they are constantly firefighting current issues.

It typically happens like this: Someday on the past, the problem has started. Unfortunately, the issue (small at the time) was not clearly identified. It only got enough attention when it was on fire. Therefore the vicious cycle:

Everyone is busy putting out fires -> no time to improve (and avoid future fires) -> more fires

It takes discipline! Finding the balance between fire prevention and firefighting is not easy. You still need the fire sirens. But some experienced firefighters should be out of the fire department before the fire siren alert. Think preventive and proactively!