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. 

Making Change a Habit

I adopted a new rule in 2000 that states, "If you think the problem can be solved by just trying a little harder, then you have the wrong solution". We spent decades of wasted time telling ourselves to just try harder to write tests, then TDD came along and it was obviously a better answer.

The try harder admonishment is an endless, repeated, diatribe about of our personal failures and how we should just buckle down and be better. Stop trying harder and start thinking.

I am not saying that, on an individual level, we don't have things we can do better at, and need to be pushed and cajoled into doing something about, but as an answer to an industry of professionals that work hard to build the best solutions they can, "try harder", is wasted breath.

Some things we here today are "Developers just have to try harder to make their code secure", this will never happen so just stop saying it. Instead, change the process to make security a primary focus on every team. Add a security engineer to every team who only, reviews, writes tests and verifies a product evolves appropriately. Enterprise level security initiatives are valuable but are not the full answer, as evidenced by the hacked reality we see every day.

Have you heard this one; "We have to try harder to share information from Scrum of Scrums with the rest of the team". I get that some of you probably do this well, but most do not, and the solution of trying hard doesn't work. Getting the right information into the right minds at the right time is an adventure in frustration. However, allowing for time-to-share and getting how-to-get-information concepts shared is much easier. The human brain works well in a limited number of prescribed scenarios and no-everything-all-the-time is not one of them. Optimize focus, intentionally limit sharing till required and allow time for understanding.

What about from your ops team; "If developers would only try harder they would understand the operations requirements and build the products we could use". Does your ops team hate you? If you are doing it right, a member of your ops team is sitting next to you for some hours of the day talking to you about what they will need to operate the feature you are adding. DevOps is a hard change, do it. Add operational intelligence as an aspect of every feature you implement with acceptance criteria and functional tests. Think of it as BI for the operations teams.

Has  your business every asked you to try harder to get BI reports out faster? "Why does it takes so long for the reporting about a feature to come out after the feature is in production? BI teams and dev teams are usually separated. This doesn't work. Every feature has a BI impact and needs consideration at the time the feature is implemented. Release your feature and the BI reporting as one package.

We have a support desk that answers the phone every day, and they hate us. "Oh please try harder to ensure we can answer customers questions. Just try harder to tell us what you are changing". How do we get support teams, with the hours they work, synchronized with feature development activity that we are working on. Send an email on release day? Sure that will work. "Oh, by the way, that button you used to use, just moved, good luck."  I don't know what the next change needs to be for this one, yet.

If you and your team want to be better, first change how you do things, then measure, and then change again. If you are not changing, you make it hard to change, and inevitably become a lagger in the ways of our ever improving approach to our profession.

If you believe that change damages teams because it introduced confusion, then you see change as an obstacle and will never master it. Don't use change as a tool, if you are not ready. With change comes chaos, and only teams experienced with change know how to own chaos. If your team members do not communicate, do not challenge each other and are not willing to be part of a solution, then change will destroy them. First empower the team, then master change.

On an experienced team, what happens is, a team member sees a change, and reacts by calling the team to order and facing it, they argue about how to address it, devise an approach to it and then reengage to the mission.

Change does disrupt, but since it offers the opportunity to grow, mastering it must be a primary goal.

Change is exciting.