Currently set to No Index
Currently set to No Follow

Agile IQ®

Stage Two

Agile IQ® Score: 49-92

What is a "Stage Two" team?

A team at this stage of its agile journey is establishing its agile behaviours in the Shu stage of Shu Ha Ri. A Stage Two team has an Agile IQ of 49-92.

Teams at this level of their learning journey are focused on mastering the basics. Combined with self-organisation, these two key areas are vital to seeing improved throughput, lower costs and reduced delivery risk.


Archetypal behaviours

The types of behaviours that are commonly seen in Stage Two include:

  • Industry standard agile roles & practices.
  • Working as a team with team goals over a group of individuals withindividually assigned tasks.
  • Just doing “the basics”.
  • Leaders are actively promoting and encouraging self-management.

What to expect in Stage Two

  • Cost Savings: None.
  • Improved Productivity: Low.
  • Improved Quality: Lower rework.
  • Improved Transparency: Medium.
  • Improved speed to market: Low.

Delivery outcomes of Stage Two teams should now be:

  • Repeatable – due to a standard level of documented and managed agile practices.
  • Consistent quality – using a standard baseline of quality across all teams.
  • Transparent – making the status of all work clear and visible in the Product Backlog, Sprint Backlog and producing an Increment every Sprint.
  • Retain their agile practices in times of stress without devolving to Stage 1 command-and-control behaviours.

As people work together as a single team, and just do the basics, the following should occur:

  • Use of agile artefacts such as Product Backlog, Sprint Backlog and an increment of work, improves transparency of the status of work and its alignment to the organisation’s goals.
  • Scrum Masters take up responsibility for agile operations without taking on responsibility for delivery. They help people work as a single cross-functional team, inspect delivery progress and adapt their plan to assure success and minimise delivery risk.
  • Product Owners prioritise work, creating transparency to teams regarding what they should work on versus what they shouldn’t work on. This “one front door” approach creates focus for the team.
  • Managers focus on the system of work that empowers teams to deliver and enact plans to grow, sustain, and improve it.

Within 3 months at Stage Two:

  • Transparency should have improved.
  • Some minor improvements in productivity and quality should have been achieved.
  • Rework should have reduced, allowing team members to redirect their efforts to delivering more.

The costs to deliver the same amount of work should decrease when teams hit an Agile IQ® of approximately 80. 


Diagnosing agile and delivery problems

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

  • Agile roles aren’t adequately understood or enacted. The team is typically slow to make decisions as a result or even insist on waiting until a manager decides before moving forward. People often mistake the Scrum Master as a delivery manager and the Product Owner as the business customer.
  • Team design isn’t optimal. Teams may be too big, causing delivery to slow and transparency of status to suffer. Teams may not have all the skills needed to deliver themselves. They may not be sufficiently cross-functional. Handovers between teams results in slower delivery. Team design based on an adequate skills matrix is critical.
  • Teams make assumptions about the amount of work they can deliver without basing it on objective metrics. This results in delivery plans and promises that simply can’t be kept.
  • A team’s work isn’t managed out of a single Product Backlog. Transparency and focus can only be created when there is “one door” for work to reach the team.
  • Work “rolls over” into subsequent Sprints without understanding why this occurs. This slows down work and results in poor forecasting of what can be delviered when.
  • Leaders move people around and putting people into multiple teams instead of creating a single team and then taking the work to that team. This is a symptom of poor team design and command-and-control leadership.

Where to focus

Ensure key agile roles are effective and team design is optimal

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

Master the basics

Don't over complicate things. Don't just tweak existing processes, leave behind old ad-hoc ways of working and master the essentials of your chosen agile framework.

Use simple metrics

Understand throughput of planned versus un-planned work to help diagnose problems in delivery.


Anti-Patterns to watch out for

Anti-patterns in Stage Two typically reflect reverting to old practices in times of stress and delivery urgency. 

Stage Two teams should be able to withstand a stress test to prove that even when things in the organisation aren’t running smoothly, the guardrails and agile practices should produce consistent and measurable results.

“Agile aside, what will it take to deliver?”

In times of stress, many agile teams revert back to their old, more comfortable behaviours – behaviours typical of Stage One, manager-led teams. These teams will stop doing agile events, such as Sprint Review and Retrospective, indicating that they need to be dropped given delivery timelines.

These teams conveniently forget that these events serve to diagnose the very problems they now find themselves in, in order to decrease the likelihood that they will happen again.

“But, I’ve run out of work to do”

When people continue to focus exclusively on their own tasks, they complete their work and hand it over to other team members. In the case of software developers, it can result in running out of “development” work before the Sprint ends. The tendency for managers is to optomise for efficiency and ensure they are “busy” by handing out more development work. The result is:

  • More work starting without being finished by the end of the Sprint.
  • The team working in solos.
  • Sprint goals being ignored and a focus on “business”.
  • No productivity gains – people aren’t actually working as a single team.

It’s the Scrum Master’s responsibility to promote and encourage the team to be cross-functional. It’s a manager’s job to make sure the Scrum Master is supported to do this.


“Rolling over into the next Sprint”

When teams don’t understand how to reduce the size of their work by creating smaller chunks, work tends to roll over into subsequent Sprints. “It can’t be broken down” is a common response.

There’s always a way to slice work, it is just that the team either has no experience in doing so, or no desire to do so.

Failing to understand how to slice work into smaller chunks will keep teams in low Stage Two and limit the organisation from receiving any benefits from agile.


Keys to improvement

Reinforcing the guardrails as a way to create repeatable, scalable outcomes is key to getting increased productivity and cost savings.

You may need to go through a few rounds of team design before you find the optimal cross-functional configuration.

Action #1: Getting agile roles and the team design right

Team design

Team members should have created a Team Charter and skills matrix in Stage One. Reflect on this to ensure that the team has all the skills it needs to deliver its outcomes successfully without needing to rely on other teams.

Managers may seek to hold on to specific people and prefer to manage their group as a single team, even if the team becomes very large. Agile teams should be no more than 10 people, including the Product Owner and Scrum Master.

Transparency of team delivery problems will improve when:

  • There are no more than 10 people in an agile team.
  • Their skills and delivery capability are made transparent.
  • The state of their agile artefacts – Sprint Backlog and Product Backlog – are current and continuously updated by the team members themselves.

Team roles, especially the Product Owner

Managers should ensure key agile roles are in place, especially the Product Owner. Don’t confuse the Product Owner with the team’s (often many) customers or stakeholders. When the Product Owner provides clear priorities to the team throughput is likely to increase. Only the Product Owner prioritises the work, regardless of what it is: it’s one person not a committee.

Quality will improve:

  • As the team and its Product Owner review delivery with stakeholders and customers on a regular basis.
  • When teams have a consistent Definition of Done and use it to build-in quality each and every Sprint.

Scrum refers to this as the “Sprint Review”. Where quality and un-planned rework needs to be addressed, consider what needs improving in a Retrospective and ensure that this now becomes the standard by which the team delivers future work.

Productivity will improve when:

  • Focus is created by only allowing work to come to the team through one front door – the Product Backlog.
  • The Product Owner works as a team member, not the customer or business subject matter expert.

The manager’s role

As teams learn how to self-organise within their guardrails, a manager’s focus should turn toward understanding their new operating model and working to optimise it.

Productivity will improve when:

  • Delivery impediments teams don’t have the power to resolve themselves are escalated to management to solve by the Scrum Master.
  • Managers have a structured, repeatable and scalable way of addressing impediments with systematic prioritisation.

An executive backlog and an ‘Executive Scrum’ is an effective pattern for addressing impediments the team can’t address themselves.

Action #2: Master the basics

Agile isn’t a pick’n’choose framework

Choose an agile framework and encourage teams to work with their Scrum Masters do do its basics. Don’t modify or remote the bits they don’t like. Scrum is typically the framework people choose.

Learn the basics

Focus solely on learning the basics. Don’t overcomplicate things. Don’t pick the parts you like or you feel “work for you”. If you don’t change the way you work you won’t get any new benefits or improvements from agile.

The basics should include:

  • “One door” for work to reach the team. This can include “business as usual” work as well as any projects the team is required to deliver.
  • Set up the team and take work to the team. Don’t move people around to different “project” teams. 
  • A Definition of Done that states what the team will do to ensure it can build-in quality. The Definition of Done should only contain items that the team themselves can do. “Customer sign-off” isn’t something in the teams control and so shouldn’t appear in the Definition of Done.

Don’t customise things before you’ve learned why and how they work

Formalise the use of agile language with the team. Changing your language helps change mindsets and establish new behaviours. If you just use existing terms that people are familiar with they won’t necessarily change their behaviour. Stick to the industry terms and don’t be tempted to make up your own.

Encouraging cross-functional work

Most teams start out with functional silos in their team. A collection of designers and analysts, software developers, and a separate set of testers. When it comes to delivering work, each silo does its own work and then hands it over to the next person when it’s done.

A cross-functional team focuses on working as a single team, without silos. It takes on work and examines what’s needed from design, development and testing, and creates a plan on how these three separate functions will collaborate to get the work done. Only when the work is done, do they then take on the next piece of work.

In Stage Two, the team will need support to learn how to focus on collaboration of work over coordination of separate tasks defined by their functional roles.

Reducing the batch size of work

Encourage the team to deliver outcomes frequently by reducing the size of the work they do. Help them to define work in smaller chunks over open-ended tasks. Help the team to deliver to a shorter timescale of days or weeks over months. Smaller batches of work have less variability and therefore less risk.

Cross-collaboration with stakeholders and customers

“Encourage people – customers, end-users, business people, and the team – to work together daily to deliver their outcomes.”,
“Encourage the team to work in short work cycles (Sprints) of a fixed length of no more than 30 days. With a fixed team size and a fixed Sprint length, this reduces the variability of work and increases their ability to forecast how much work can be done each Sprint.”

Action #3: Simple Metrics

Planned versus un-planned work

Counting items as they are delivered helps to create transparency about the amount of work and the type of work the team does. Operational teams in particular get overwhelmed by urgent un-planned work.

  • Count the numer of planned items that go into a Sprint.
  • Count the number of planned items that get to Done within the Sprint.
  • Count the number of urgent unplanned items that are forced into the Sprint.

At Retrospective:

  • Compare planned versus un-planned work.
  • Improve understanding about why un-planned work enters the team.
  • Work with stakeholders to “book” unplanned work into future Sprints.


Move from reporting of tasks and activities to:

  • What was the goal for last Sprint and was it achieved?
  • What is the goal for this Sprint?
  • What will the team likely focus on for the following Sprints?

Stage Two Learning Areas

Gettingn the most out of agile roles


Developers are the people in the Scrum Team that are...

Scrum Master

Scrum Masters are responsible for the effectiveness of agile.

Facilitation Guides

Daily Scrum

Inspecting progress toward the Sprint Goal empowers a team to...

Enhancing transparency thru agile artefacts

Daily Scrum

Inspecting progress toward the Sprint Goal empowers a team to...

agile iq academy logo 2022-05-05 sm

Enter your details

search previous next tag category expand menu location phone mail time cart zoom edit close