Agile IQ®: Transformation Academy ™

Stage Two

Agile IQ® Score: 49-92

What is "Stage Two" ?

Stage Two companies are typically learning how to support self-managing, cross-functional, agile teams and make the shift from predictive waterfall-style planning to adaptive planning in Sprints.

These companies and their teams become “agile” when the basics are truly mastered.

Forecast cost savings

Low to none

Average time to release value

More than 1 month

Average time to pivot to change

Up to 30 days

Forecast psychological safety

Low

It typically takes a company 1 year to reach Stage Two. Cost savings will start to come when the company moves into Stage Three.

Stage Two organisations should strongly invested in learning and focussing on getting the basics of their agile operating models right.

Archetypal behaviours

Stage Two shows that you may have both project teams and agile teams. Focussing on developing one will help yield faster time to market and lower costs.

Customising practices	move to	Learning the fundamentals before your company starts customising it doesn't yet have any experience with.
Customising roles and titles	move to	Alignment to industry standards with new words that will help create change
Creating an overly complex company-wide "agile methodology"	move to	Keeping things simple

Key to growth

Your Agile IQ® score suggests that while there is some agile growth across your company, there may still be some competing priorities holding you back.

Ensure key agile roles are in place	actions for growth	Understand the role off managers versus Product Owners and Scrum Masters. Ensure minimal agile roles are supported.
Changing digital practices	actions for growth	Learning mindset. Focus team leads and capability managers on improving the company's capabilities over directing and task managing them.
Focus on teams	actions for growth	Self-organisation with guardrails established by management
Create consistency	actions for growth	Creating consistency of practice and terminology so that everyone has a shared understanding of how work is now delivered

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

Customisation	avoid	Tailoring practices you have yet to build experience with.
Agile values	avoid	People will claim they have an agile mindset but have no change to their work behaviours. An agile mindset requires demonstration through agile behaviours.
Cargo cult	avoid	Teams often missunderstand visual management for Kanban, and use it as an excuse not to change to using Sprints and increments of work.

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.

Reporting

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

Artefacts