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.

A Stage Two team is typically focused on:

  • Learning the basics of a chosen agile framework, e.g. Scrum or Extreme Programming.
  • Working toward mastering the framework, not as a methodology to implement, but as a new way of thinking about work and using it to deliver high value outcomes.

Once a team has mastered the basics, the key to moving to Stage Three is to start to add additional agile and user-centred practices, such as:

  • Kanban, not just visualisation of work but limiting WIP.
  • Design Thinking.
  • Lean UX.
agile iq stage two-800x445

What do the basics look like?

Choosing a framework to start with, rather than picking and choosing the pieces of agile practice you like, is key. 80% of agile teams use Scrum, so that’s a great place to start.

Establish key agile roles

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

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.

Start Simple

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.

Leave project management behind

Evolve from team work as BAU and project management to product (and service) management.

Stage Two Learning Areas

Developer

Developers are the people in the Scrum Team...

Roles

Developer

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

Scrum Master

Scrum Masters are responsible for the effectiveness of agile.

Facilitation Guides

Sprint Review

Go beyond a demo and inspect the increment to get...

Daily Scrum

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

Artefacts

Sprint Review

Go beyond a demo and inspect the increment to get...

Daily Scrum

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

Behaviours to encourage

Encourage 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.”

Actions for leaders and scrum masters

Agile isn’t a pick’n’choose framework

 Choose an agile framework and learn its basics. Don’t modify or remote the bits you 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.

Establish key roles

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.

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.

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