At the combined Agile Alliance and Agile Open Northwest Open Space event in Portland, OR on 24 September, Declan Whelan and Diana Larsen led two sessions in which they explored the application of the Agile Fluency model for understanding and addressing technical debt and showed a game based on the model which teams can use to help them identify practices and principles they want to adopt based on their fluency goals.
The first session was led by Declan and was titled “Solving the World’s Technical Debt Problems via Agile Fluency”. His initial premise was that the proliferation of Scrum without strong technical practices has resulted in teams that are more proficient at producing technical debt.
He started by having the group come up with an agreed definition of technical debt for the purposes of the discussion. He is part of the Agile Alliance Managing Technical Debt (at Project and Portfolio level) program and presented the definition that program uses for technical debt:
“Anything in the code that slows down the delivery of value, across the whole life of the product”
An additional aspects to the definition was added through discussion – “technical debt is something that you can see by looking at the artefacts of the code” and “things in technology that slow us down”.
He referenced Martin Fowler’s quadrants of technical debt and the fact that technical debt does have a compounding interest aspect – the longer it is left unaddressed the more expensive it becomes to resolve it.
He then summarised the Agile Fluency model and presented the premise that there will be practices which need to be applied at each “bus stop” on the fluency path and that there is a correlation between the stop an organisation choses to stop at and the level of technical debt in their products.
He asked the participants to identify the practices they felt applied at each fluency level and put them onto a wall chart:
Diana Larsen and James Shore, the originators of the model, were in the group and they presented some of their more recent ideas about the model. Firstly they emphasised the fact that the “bus stop” is chosen by the organisation, not by the independent teams. The organisation “buys the ticket”, the teams then have to “get on the bus”. If no one buys the ticket the teams won’t even be able to achieve one-star proficiency.
They also emphasised that this model is about achieving fluent proficiency in a combination of skills and competencies at each level – being fluent means doing the practice even when under pressure. For any given proficiency on the journey teams and individuals will be going through a learning pathway (Alistair Cockburn talks about Shu-Ha-Ri as an example of a learning pathway) and the organisation needs to support them in their journey.
They spoke about the adoption of the model by the wider community and the formation of a Google group as a place for sharing ideas and experience using the model. They are also building a team diagnostic model which will allow teams to self-assess where they are on the pathway and can be used as the basis for conversations about how far they would want to go.
The second session was led by Diana and she presented the “Fluent@agile” game which Christian Vikstrom and Peter Antman at Spotify have produced as part of their Squad Health Check model. The game is described in the video, which unfortunately for the audience in Portland, is in Swedish. Diana asked for the participants' help in identifying how the game should be set up and could be used. This resulted in much exploration and experementation, after which the following description was agreed on.
The game consists of a roadway which is drawn on flipcharts with five stops on the journey which relate to the bus stops in the model. The Spotify interpretation uses a musician metaphor which has the levels as
- Hobby musician / Studio artist / Solo artist
- Cover Band
- Symphony orchestra
- Successful band in control of own music
- Improvising (symphony) orchestra creating beautiful music in the moment
The game has cards which list a wide range of technical practices and competencies which the team playing it put either onto the road or outside the road. If a card is on the road then the team feels they are proficient at that competency, if it is outside the roadway then it is something they feel will be necessary but they are not yet proficient. They can then pick a number of competencies to put under a “driving license” which indicates a commitment to learn and become proficient at the practice.
A tool such as this game can help teams identify where they are in the fluency model and help management understand the investments which will be needed to support teams to get to the desired level of fluency.
