Fluent@agile – visualizing your way of working

Facebook

Google

Twitter

Linkedin

Help your team improve by visualizing their way working with the fluent@agile game. With the game you can help a team find out where it is on its agile journey and help it find new ways of both fine tuning and make leaps in their daily agile practices.

Me and Christian Vikström made the game together at Spotify during the spring 2014 when we were coaching and helping team to improve their agile skill sets and processes.

At Spotify the teams owns their own way of working. A team is basically only accountable to itself. We therefore needed an coaching tool that could help team take ownership of their self image and improvement strategy.

We also wanted the tool to be opinionated. It should be normative, tell what’s good and not, what kind of practices and behaviour that’s expected and not. But at the same time it should be open to new ideas, new practices and the teams local conditions.

Fluent@agile

We found the model “Agile Fluency™” developed and described by Diana Larsen and James Shore very useful. It’s based on their long experience of helping team grow agile and the different stages both teams and organizations (most) often will go through.  

According to them team goes through the following stages or phases:

1. Team starts focusing on value. This often means a cultural shift. What you normally see is some kind of vanilla Scrum.
2. Team now actually delivers value regularly. We now focus on our skills. Typical practises are inspired from eXtreme Programming
3. The team takes on new responsibilities by optimizing value. Here you find high impact teams inspired by Lean Startup. This almost always requires an organizational structural shift.
4. A few teams and companies reach a level where they optimize the system and see the whole. It requires a cultural organizational change. Few companies have reached and will ever reach this level.

Do you always have to go through all stages? Theoretically no. You could try to jump directly into the kind of setting you prefer. Our experience it however that is seldom work. There is a more or less implicit maturity model at work here. If you have never experiences how it feels when you are delivering well sliced stories to a Product Owner, you will most probably have a very hard time defining your minimal amount of work, on whatever level you are. It’ great, however, to set an ambition: what level do we want to strive for.

The game we built from this is based on three pillars:

• A model: It’s based on a model for how teams usually moves on their journey from “pre-agile” to high impact teams.
• Visualization: We believe that visualization is a super strong way to build shared understanding, engagement and collaboration.
• Ownership: The game is built so that teams can take a strong ownership over their journey towards becoming a high impact agile team.

By gamifying the model and adding concrete practises to it we think we achieved our goals: a team can use the game and “configure” its own image of agile and where it is and want to be. Since “Agile Fluency™” is trade marked, we named it fluent@agile, free to use by any- and everyone.

Apart from adding a set of concrete practices Christian and I also added the metaphor of playing in a band (working on Spotify, the world’s leading provider of streamed music, you know). We have thus actually defined five stages:

1. The solo artist. You play for yourself. It could be a hobby, or you could be world class. But you do not deliver together with others.
2. The cover band. You play together and perform. But you play other people’s music. Again, you might be an amateaur band playing at friends weddings or the best after-ski band in the world.
3. Symphony orchestra. You are super skilled musicians that really can play together, but you play by notes and you are directed by a conductor.
4. Successful band in control of their music. You write, produce and record your own music. You know what your audience want, or you are experimenting to learn.
5. An improvising (symphony) orchestra that improvise and create fantastic music in the moment. Every moment is unique.

It’s very fun to get discussions started by introducing these metaphors. Are they right on spot? Try them.

The game

We used fluent@agile on several teams on Spotify. I have also used it to start organizational discussions without actually doing a complete team visualization. Several coaches at Crisp have also used it. One of the most powerful aspect of it are the discussions that emanate out of the play. What practices is this? What does it mean? Do we believe it would be good for us? Why would we want to be at that level? Are we really at the level we think we are?

Christian and I presented fluent@agile at Agile Sverige 2014, but we did not make the material public. So, here it is.

You can find a video from the presentation here. Unfortunately it’s in Swedish.

Here’s the original presentation where you can get a feeling of we normally do the visualization.

The game is delivered as a PDF. It should be easy to follow the instructions. You print out the part of the presentation that represents the game,  laminate it and cut it. Download it here: The game fluent@agile.

Here’s also a first cut at extending the practices by building a practices matrix.

So how do you get started?

We believe that one of the pillars for the game to be successful is that the team feels a strong ownership over the game and their improvement work. Our experience is that when we facilitate in a way where we listen to the team and try to adapt our facilitation along the way makes it easier for the team to take that ownership.

Possible ways to facilitate:

• Present the model approach: Present the model/game and let the team build the game and then decide on what practices they want to work on getting fluent on next. Establish the value/goals of implementing the practices. Write one or several improvement stories as first steps towards getting fluent at the practices.
• Music metaphor approach: Present the music metaphor. Either by presenting it yourself or by facilitating a discussion that builds the metaphor. Let the team(s) build their models using a training from the back of the room approach.
• Training from the back of the room approach: Give the team minimal instructions to get started with the game, stay available for the team to pull information or give direction if the team gets stuck or misunderstand how to play the game.

Here’s the way we normally do the model approach:

• Introduction to the model/game.
  • Put the different levels up on the wall. Describe shortly what each level means, stay open to answer questions or have short discussions with the team on each level.
  • Team discussion: “At what level in the model do you as a team want to get fluent?”
    • “Are you fluent on any of the levels already?”
    • “Where would you like to be as a squad?”
    • “On a personal level, where do you think you would be most satisfied?”
    • If the team seems open to it you might even go for a consensus decision on this.
• “What practices do you believe you need to be fluent at to be able to be fluent at all the levels up to the level you are aiming at?”
  • Let the team go through all the practices notes and discuss which ones they are: (“teaching moments” often arise here when team members ask what specific practices are, and what they are good for 🙂
    • Fluent at (put them on the road)
    • Practicing (put them besides the road)
    • Need to do (put them under the “drivers license”)
    • Don’t need (put them under “Park”)
  • “Are there any practices missing in the game that you are already doing or that you think you need to be doing?”
  • “Is there any practices that we can remove and still get fluent?”
• Next practice(s) to get fluent at:
  • Create a target condition:
    • Let the team pick something they want to start working on to get fluent at, e.g. by dot-voting.
    • Discuss and define what it would mean for the team if they got fluent at the practice(s). E.g. by brainstorming post-its on the possible benefits, then discuss and group them; now you have a goal/target condition.
    • Write improvement stories that describes the first steps to take to move towards fluency.
• How to integrate this improvement work to your daily work:
  • Discuss how the team will make this happen as part of their daily work. E.g.:
    • The improvements stories are prioritized together with the rest of their work in the backlog.
    • Having weekly meetings to plan/groom their improvement work.
• Optional perspectives:
  • “Given the pace of improvement work we are currently having in the team – how long do you think that it would take for your team to get fluent at all the practices that you have listed?””
  • “Do you believe that it would be valuable for your team and for the organization to increase the pace of improvement work?”

Happy gaming.