How We Kick-Off New Squads

Let them be in control of the way they work ...

After having been though a day of letting people self-organise into squads David Mole, Trade Me's head of projects (and my Agile partner in crime) and I are often being asked how we kicked off the new squads and how we make sure they work in a disciplined but creative way.

This is a very topical question as not only did we have 22 brand new squads on our hands all at the same time, Trade Me are also rapidly growing and new squads are frequently being formed.

During total squadification we proved that people can be trusted to solve complex problems, know what’s best for them and the company and, in general, can be treated as the adults they are. In the spirit of letting people be in control of their way of working and finding a way that works for them we don't mandate whether teams run Scrum, Kanban or any magic mix of Agile ingredients. Secretly, if they really wanted to we’d even let them get away with waterfall (well maybe)!

When new squads start we guide them through a process of selecting Agile and Lean practices to help them come up with a process that works for them.

This is the facilitation guide that we provide for our Squad Masters:

Squad kick-off facilitation guide

Who should be there?

The entire squad, i.e. every team member. If someone can’t make it then find a different date - it is really important that everyone has a say in how the squad is going to work.

Also, make sure the facilitator has enough Agile experience to facilitate a discussion around when to use Scrum, when to use Kanban and about the purpose and meaning of each Agile practice.

How much time do we need?

Depending on team size and personalities reserve 2-3 hours.

What do we do?

We usually split the kick-off into three parts: Getting to know each other, choosing your Agile ingredients and agreeing on the practical stuff.

Part 1: Get to know each other (ca. 1 - 1.30 hours)

I like Lyssa Adkin’s journey line exercise as a starting point. Journey lines are one of the few non-wanky team building exercises that help people get to know each other and create a solid base from which a group of people can form a team.

In a nutshell people draw the journey lines of their careers and/or private lives and share as much as they want from their past. More detail and instructions for this exercise are here.

Part 2: Choose your Agile ingredients (ca 1 hour)

In this part we define the squad’s (Agile) processes. Here’s how we normally run this:

1) Generate a list of Agile ingredients from Scrum, Kanban and general Agile. Have people shout out the ingredients and write them on a whiteboard.

This is what people normally come up with (if they don’t then it’s a starter list for you to bring up yourself):

• Sprints (if so, how long)


• Kanban workflow


• Explicitly limit WIP


• Coordination: Daily standup


• Feedback process: Retrospectives?


• Visual workspace


• Measure/track velocity? cycle time? lead time?


• Planning: Sprint planning? On demand or on a regular basis?


• Backlog Refinement sessions


• Definition of Done


• Forecasting, product burnup charts, burndown charts


• Demos


• Product Owner collaboration: sit together? when? how?


• TDD, Specification by example


• Co-ordination with other squads: Scrum of Scrums?


• Have an Agile coach?

2) Discuss each practice/ingredient and decide to use/don’t use/introduce later. Make sure you discuss why you made this choice and have a conversation about the purpose of each Agile ingredient.

• For every ingredient discuss why/why not and the purpose of the practice


• For every practice the squad decide not to do, ask how else the purpose will be achieved. If a squad decides not to have standups for example - ask them what the purpose of standup is (co-ordination) and how and when they will co-ordinate their work. Also, ask them what they would gain and lose by not choosing to have standups.

There are usually two Agile practices that I try to convince people to use: Retrospectives and physical story walls.

Part 3: The practical stuff (20 - 30 mins)

Once you have decided which practices to follow, deal with the practical stuff such as:

• Definition of Done: Group discussion to come up with a checklist for what a story needs to fulfil to be potentially shippable, such as 0 known bugs, code reviewed etc (I usually push for 0 known bugs - more on the Definition of Done and some examples)


• Agree on what happens next:
  
  • If running sprints: sprint length
  
  
  • Meeting times
  
  
  • Tools to use (Trello, Fogbugz, wiki, whiteboard - except for a company agreement to use Fogbugz for releases squads are free to choose their own tools)
  
  

Also, make sure that everyone is aware that this is just the beginning and that everything can and will be revised at a later date. If the squad for example find out that they don’t want to do sprints at a later time, they can switch to a more flow based approach later if they want to.

Does it work?

This approach for kicking off new squads works really well for us. Sometimes we even use it to do a “team reset” when a squad realises they have lost their way or adds several new members and needs to revisit their working agreements.

Of course sometimes squads come up with a Frankenstein process that leaves them with the worst of all worlds but that’s where coaching and support come in and there’s always the opportunity to “re-kick-off” the squad.

Always evolving

As I said earlier, our squads are completely in control of how they work - including how they kick-off. Therefore we see this is a base template for how to kick-off a new squad and like all good templates this is just a suggested starting point which we expect people to adapt to what suits them and their squad.

P.S. No one has chosen waterfall

P.P.S If you’d like to know more about how we migrated to squads, chapters and guilds here’s an InfoQ interview with David and me.