I'm busy working on my blog posts. Watch this space!
Featureban at Scale (Scaled Featureban) - a scaled agile game
October 11, 2016
I'm an agile coach working for a multinational consultancy at client side - one of the leading universities in the world.
I was recently asked to conduct an agile game for a group of 7 to teach them agile skills. I chose Featureban (https://www.agendashift.com/featureban) which I believe to be one of the better games to:
1) teach teams the basic flow of the Kanban Agile methodology,
2) teach teams that kanban is more than just a visual board,
3) teach teams the differences between Kanban and Scrum,
4) teach agile!
Featureban teaches you the core of Kanban i.e.
1) visualize work flow,
2) use explicit policies / rules,
3) implement feedback loops such as daily stand ups,
4) limit work in progress,
5) manage flow,
6) improve collaboration and communication.
Featureban is an agile simulation game for a team. Agile teams typically comprise of under 10 team members. On successful completion of my Featureban game I was asked to deliver the same course to a group of 40 people. How would one scale Featureban?
Having given thought to this, succeeding in this challenge would rest upon 3 factors:
1) facilitating the group and bringing them together for instructions and de-briefs,
2) splitting the group of 40 up into teams and assigning a team coach for each team,
3) training team coaches in facilitating Featureban.
Given below are the steps I followed to ensure the Featureban at Scale event was a success:
1) Train the team coaches (I setup a couple of hours with the team coaches, who had themselves participated in Featureban before, and taught them the core requirements i.e.
a) ensure the team follow the rules explicitly,
b) don't get caught up in the subject matter,
c) don't advise the team on how to progress work, they are there primarily to ensure the rules are
followed. A 'good' sign in iteration 1 is chaos and a build up of work backlog items.
d) don't reset the board after Iteration 1
e) set the WIP limit when instructed to in Iteration 2. A 'good' sign in iteration 2 is when the team begin to discuss each move with one another and communicate.
2) Setup Kanban boards with enough space for teams in advance. Ensure sharpies, post-its and coins are made available. Fill out the 'in-progress' columns with meaningful stage names before hand e.g. design, build. Ensure the rules are printed out in large e.g. A3
3) Provide the team with a 'project subject' to deliver before the event. Ask each participant to come prepared with 5-6 tasks written on post-its before the event.
4) During the event present the group with the purpose for the game and go through the rules explicitly. Run a mock / trial session of the game with the team coaches to demonstrate the game at play. Assign a team coach to each team and start playing.
5) Make sure to walk around each team and comment on progress e.g. comment on the backlog of work building up. Answer any questions or concerns. Re-iterate in Iteration 2 the goal is to limit work in progress.
6) At the end of each game play call the group back and discuss their observations. Make the de-brief engaging and discussion based.
7) Present the key learning at the end of the session.