Agile IQ®: Transformation Academy ™

Stage One

Agile IQ® Score: 0-48

What is "stage one"?

Stage One suggests that you have a number of people focussed on digital transformation, but relative to other organisations, your overall agile capability maturity is likely still fairly low.

A team at this stage of its agile journey is in the Shu stage of Shu Ha Ri.

Forecast cost savings

None

Average time to release value

Once a year

Average time to pivot to change

Up to 6 months or more

Forecast psychological safety

Very low

Delivery in Stage One organisations depends on talented people, but because skills are embedded in specific individuals, a company’s agility isn’t yet scalable and success isn’t repeatable.

Archetypal behaviours

Your Agile IQ® score shows that you may have traditional management behaviours in place over guardrails for self-management.

Management by task delegation	move to	Self-management with set timeboxes, minimum agile roles, potentially releasable increment every Sprint.
Ad-hoc or waterfall practices	move to	Cross-functional teams that can deliver outcomes without needing to rely on upstream or downstream teams to provide an increment of value.
Optimising for utilisation	move to	100% utilisation doesn't mean people are working on the most valuable thing. Ensure teams are effective at delivering work to a standard level of quality that is "potentially" releasable to userrs and/or stakeholders, not just being 100% utilised.

Key to growth

Stage One suggests that while there is some agile growth across your company, there may still be some competing priorities holding you back.

Self-organising teams	actions for growth	Executives and managers must establish and promote guardrails for self-organisation. Agile needs to become the company's operating model.
Agile IQ® ROI metrics	actions for growth	Use data, not gut instinct, to make informed decisions on where to focus capability development.
Improve the transparency of work	actions for growth	Employ team backlogs over project gantt charts are a good place to start.

What to avoid

Data on the fastest path to growth, based on other companies' successes and lessons learned, is key to avoid the traps of transformation

Team design	avoid	Functional, single capability or component teams.
Self-organisation	avoid	Autonomous teams. All teams should still have alignment of purpose, function, quality, standards and backlogs.
Cargo cult	avoid	Assuming the symbols of agile make teams agile. Only a change in the way teams work will give the company the benefits of agile.

Diagnosing agile and delivery problems

Issues with agile most often occur in Stage One teams when:

Business-as-usual, and urgent un-planned work distracts teams from delivering their planned work. These teams make delivery promises but then get distracted by other people’s priorities. The guardrails must establish one “front door” for the team and work prioritised by the team’s Product Owner.
Teams rush ahead with customising agile before understanding how to make best use of the basics. Choose a framework and embed it in the team’s operating model by establish guardrails.
Leaders don’t fully support self-management. If they continue to “task manage” people, and hand out and delegate tasks, and direct individual’s work, teams are unlikely to evolve beyond low Stage Two and therefore unlikely to get fastee to market or improve throughput.

Where to focus

Establish the guardrails for self-management

Implement key events and artefacts like the Sprint Backlog, Product Backlog and the Increment of Done by the end of the Sprint.

Promote self-organisation

Start to move away from task delegation, and management of individuals, to using guardrails to set expectations about delivery.

Establish key agile roles and cross-functional teams

Ensure that someone is accountable for the effectiveness of agile practice and someone is accountable for delivery of value.

If these areas of focus are not attended to, the organisation is not likely to receive the benefits of agile.

Anti-Patterns to watch out for

Anti-patterns in Stage One all reflect resistance to people changing the way they work, from managers to their teams.

Without changing the way they work, the company will receive none of the benefits of their transformation.

Antipattern #1: “We take what works”

“We take what works” is short hand for “we haven’t changed the way we work”.

Many teams start out by selecting a few key agile practices they either like or they feel best suits their current way of working. Unfortunately, this results in the team not changing their current behaviours. If they don’t change the way they work they won’t get any of the benefits agile can bring.

Visual management for these teams may improve transparency of delivery, but it is unlikely to yield improved productivity or cost savings.

Antipattern #2: “Can’t we just do Kanban?”

Many feel that the basics of Scrum are too hard because it requires teams to change the way they work. Teams at Stage One are often tempted as a result to just “do Kanban”. These teams then implement the visual management aspect of Kanban, but none of its other practices, including optimising flow, minimising work in-progress, and defining explicit progression criteria. Just implementing these “symbols” of agile gives leadership the false impression that the team is agile.

This is called “Cargo Cult” agile.

Antipattern #3: “We’re just being pragmatic” / “You’re being a purist”

Using pragmatism is an excuse not to change. These teams feel that they are serving delivery by selecting the elements of agile that suit their current way of working. Any suggestion they should change is then labelled as being “purist”.

Teams with these behaviours will often relate that delivery will be at risk if they are required to change the way they work.

Antipattern #4: “But we’ll lose our capability if we form cross-functional teams!”

Many organisations have functional teams. These teams have faster time to delivery as there are no hand-overs to other teams to complete an increment of value and they typically have fewer to no team-to-team dependencies.

Often when single function teams, or capability-based teams, are faced with the change to form cross-funcitonal teams, many will claim: