1/10/2015

Tribe Level Ceremonies

We take new words from Spotify to describe a scaled agile organization. Tribes contain squads which deliver features. Guilds share subjects and Chapters share skills.

This is about extending traditional Agile to optimize for larger teams. Scrum talks of teams with daily Stand Ups and a Scrum of Scums to share between teams. It assumes that information is shared between teams via a Scrum of Scrums representative but this doesn't really work.

We don't do team Stand Ups anymore. We don't do Scrum of Scrums anymore. Instead, all Squads in a Tribe attend a daily Stand Up and share red, yellow, green status of the Squad. Thirty people in one room for 10 minutes. Thats four Squads in one room for 10 minutes. Thats four announcements of green most days, occasional yellows with some details and followup actions assigned and a rare red where everyone takes note and assesses how to change resource, blockers or what ever it takes.

This benefits us in a few ways. We decided a long time ago that a Squad Stand Up with a single developer reporting "Finished X, moving on to Y today, no blockers" was not effective. Its not effective because the information is too detailed for most listeners, and redundant for everyone on the Squad because they are all working and communicating everyday. The goal of Stand Ups is to decide if the current plan needs changing and how to change it. Everyone knows the current plan so no point reiterating it but risks and blockers potentially drive change and that is the key that these discussions should focus on.

So, from the old Stand Up definition.

- Please tell everyone what you did yesterday, what you are going to do today and any blockers you have.

We now have a definition:

- Your Squad must indicate the red, yellow, green status of your Sprint commitments and, if not green, what the projected problems are.

This change is made possible because these people have been doing Agile for years and so the need for a single team to "share status" every day is irrelevant now, they do that all day. They all sit within 10' of each other and openly announce issues as they occur. They commit and push code all the time and they ensure the build is always watching them.

If you have developers sitting in cubes, don't do this. If you are new to Agile, don't do this. The habits of the people on your team can not sustain this kind of automatic behavior.

How do you know if you can do this? Do you feel an uneasy fear if you have't pushed for more than 15 minutes? When you pull do you look at the code changes and immediately give feedback? Do you feel strange not having someone sitting next to you arguing with your approach to a problem? Would you feel comfortable if the code you just pushed was to be release to production now.

People go through changes when they practice Agile. Its more than a process, its a re-programming of a developers instincts. 








No comments: