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!

What am I managing?

When I first started PMing I used to manage people working.

A few years went by. I changed.

I realized I should manage the work and enable people.

More years went by. I changed again.

Today I came to the realization I should manage people expectation and enable the work.

I wonder what will be my realization in another few years.

The 1000 students challenge (3)

In May of 2011 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 here:  The 1000 Students Challenge

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

A big thanks to the FHNW for being supportive and to Prof. Martin Kropp for organizing.

My mission is to train 1000 students in Scrum - 938 more to go ...

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

Toggle Driven Development

Similarly to Test Driven Development (TDD)--Writing tests before code--, my current team is following a Toggle Driven Development: Writing toggles before code.

The main point is: if you are using toggles, consider designing/creating/refactoring  the toggle strategy before writing code.

Before getting into TDD, I got into writing tests for the code. It took me a few years until I fully understood the value of writing the test first. It seems to me that toggles are following a similar pattern. I wonder if there will be such a thing as Toggle Driven Development.