BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Agile Fluency Workshop at Agile Australia

Agile Fluency Workshop at Agile Australia

This item in japanese

Bookmarks

James Shore presented a day long workshop at Agile Australia titled “Bringing Fluency to your Agile teams: Coaching for Best-Fit Agile”.  The focus of the workshop was the use of the Agile Fluency model, which he and Diana Larsen have developed, as a tool for coaches to use when choosing the approach to working with different teams based on their level of fluency with the agile values, principles and practices.

The description for the workshop states

Learn how to tailor your Agile coaching efforts to best fit the needs of your teams and organisation. As teams grow in their understanding of Agile, their perspective of Agile shifts and changes, and so do the challenges they must overcome. Whether it’s team cohesion, technical skills, or organisational politics, the right investment to make in your teams depends on where they’re at, what they need, and what your organisation is willing to provide.

He started the workshop by explaining the importance of fluency vs proficiency.  He and Diana were influenced by the work of Language Hunters which has techniques for rapidly learning a language.  There are four levels of proficiency in speaking a language ranging from being able to understand single words and very simple sentences to being completely bilingual where the speaker is unable to be distinguished from a native speaker of the language. 

In the context of the agile practices James defines a team’s level of proficiency as the way they behave when under pressure.  Do they maintain a disciplined TDD approach or revert to “code & hack” when the deadline looms.  Are the self-organising all the time or is their ability to set goals restricted by management practices.

He presented the four step model shown here, and described the behaviours, benefits and challenges which emerge at each of the stops on the pathway.  He was at pains to point out that where a team should chose to stop is where it makes the most sense in their context and environment.

Each star represents a level of practice and team characteristics that need to be in place:

One Star

At this level teams are proficient in the agile ceremonies and processes, they work together as a real team, use retrospectives to actively learn and adapt their practices, have an empowered product owner/business representative who provides the team with clarity of understanding about business value.  Team work at a regular cadence (with or without formal iterations) and are able to show how the work they are doing aligns with the business goals.  

At this level organisations can expect to see increased productivity, reduced risk through transparency and reduced hand-off delays.

Getting to one star requires that teams are able to be focused on one thing at a time and have a clear view of value in their product backlog.  Typically teams can reach one star fluency within 2-6 months of adopting agile practices. 

In unscientific polls approximately 45% of teams self-identify as being one star teams.

Two Star

Two star teams build on the social and process capabilities of one star teams and add technical proficiency.  This is where the strong technical practices become necessary and teams need absolute line of sight from their product to the marketplace.

Benefits from two star teams are reduced technical debt, building quality in rather than retrofitting technical aspects, predictability in terms of velocity and cadence of delivery, high morale and the ability to ship working product on demand.  The key differentiator of two star teams is their ability to ship working product on a cadence that suits the market, and always being ready to ship.

Getting from one to two star proficiency requires technical mentoring and discipline and organisational permission.  It is a hard shift which is mainly to do with bringing in technical practices such as test driven development, ruthless refactoring, continuous integration, pair programming.

In the same polls mentioned above approximately 30% of teams self-identify as being at the two star level.  James estimates it takes from 3 to 24 months for a team to become fluent at the two star level.

Three Star

Three star teams are where the promises of agile are able to be realised.  Getting to this level requires not just permission but organisational structure changes.  At this level the team owns their marketplace – there is no differentiation between “the business” and “the team”.  Product management is imbedded in the team and all team members have direct line of sight to customer value.  The team owns the product vision, is empowered to act on that vision and can adapt the product based on the feedback they receive.  Teams are stable and team members have a broad range of skills, able and willing to support each other in whatever role is needed at the time.

Reporting is based on concrete business metrics such as ROI, customer satisfaction and net profit per employee.  Risk is reduced because low value initiatives are cancelled quickly, products are released based on customer needs and rapidly adapted in response to those needs.

To achieve this level of fluency organisations need to form stable teams and break down silos, removing barriers between the builders and consumers of products and empowering the teams to deliver the right results.

Approximately 5% of teams self-identify as three star fluency and James estimates it takes between one and five years to achieve this level.

Four Star

Four star organisations are agile’s future.  There are very few organisations around today who have made the substantive culture shift which will be needed to create truly responsive organisations.  What they will look like is yet to be seen, but there is some indication in companies such as Zappos and Semco

Having identified what the four levels are and the changes needed to get to each level, James went on to provide the workshop participants with guidelines on what types of investment are needed to bring teams to each level and what skills and other changes will be needed.  For example, to help teams get to two star fluency it will most often be necessary to bring in a technical coach or mentor, someone who has used the technical practices in a similar tech stack and platform structure to which the team is working in. 

As a coach working with a team it is important to understand where they are proficient and fluent, and where realistically they could target getting to.  He feels that most teams should aim for two star fluency, but going beyond that level may not be feasible nor desirable in some organisations.  The change required may be too extreme for the organisation to permit it.

He and Diana are working on a diagnostic tool which can be used to help teams self-asses their level of proficiency and fluency and where they could realistically target getting to.


Full disclosure: This reporter was invited to attend the workshop by the Agile Australia organisers and James. 

Rate this Article

Adoption
Style

BT