Agile IQ® Score: 49-92
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.
The types of behaviours that are commonly seen in Stage Two include:
Delivery outcomes of Stage Two teams should now be:
As people work together as a single team, and just do the basics, the following should occur:
Within 3 months at Stage Two:
The costs to deliver the same amount of work should decrease when teams hit an Agile IQ® of approximately 80.
Issues with agile most often occur in Stage One and Stage Two teams when:
Ensure that someone is accountable for the effectiveness of agile practice.
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.
Understand throughput of planned versus un-planned work to help diagnose problems in delivery.
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.
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.
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:
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.
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.
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.
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:
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:
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:
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.
An executive backlog and an ‘Executive Scrum’ is an effective pattern for addressing impediments the team can’t address themselves.
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.
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:
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.
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.
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.
“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.”
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.
Move from reporting of tasks and activities to:
When a Story doesn't get finished by the...
Inspecting progress toward the Sprint Goal empowers a...
How do you slice Product Backlog items so...
The Sprint Backlog is a plan by and...
When quality slips, defects and rework increases, it's...
Developers are the people in the Scrum Team...
How do you create an Increment of work...
Who has the capability to grow into an agile role?
Developers are the people in the Scrum Team that are...
What does it take to lead an Agile Release Train...
What is a manager's role in an agile team?
What does it take to be a great Product Owner?
What is a Release Train Engineer (RTE) and what does...
Scrum Masters are responsible for the effectiveness of agile.
An activity is designed to help improve awareness of agile...
Who will make a good fit for new agile roles?
How does a Product Owner facilitate discussion on the value...
Teams' agility improves when the Scrum Master supports self-organisation with...
Inspecting progress toward the Sprint Goal empowers a team to...
Getting on top of your Product Backlog is a key...
How does a team decide on what items will become...