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.
A Stage Two team is typically focused on learning how to get the basics of agile right and mastering them. Focussing, for example, on doing the basics of Scrum.
Once a team has established the basics of its agile practices in Stage Two, the key to moving to Stage Three is to start to add additional agile and user-centred patterns, such as Kanban and Design Thinking.
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.
A Scrum Team has the following essential components.
Scrum Teams have three roles or areas of accountability:
Accountable for optimising the value the Scrum Team delivers, establishing the product's goals, the budget, and making the work to deliver the product's outcomes transparent in the the Product Backlog.
Accountable for delivering an Increment of work every Sprint and delivering that work to a set level of quality, known as the Definition of Done.
Accountable for the effectiveness of Scrum used by the whole Scrum Team. The Scrum Master isn't an 'agile project manager'. Their responsibilities encompass coaching the Product Owner, Developers and Stakeholders how to be more agile.
Scrum Teams use three artefacts. Making artefacts transparent supports the team to inspect the state of work and then more easily adapt to change.
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). It's a real-time picture of the work that's needed to achieve the Sprint Goal.
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
Scrum Teams use five events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt.
Events are used in Scrum to create regularity and to minimise the need for meetings not defined in Scrum. Optimally, all events are held at the same time and place to reduce complexity.
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.”
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.
Focus solely on learning the basics. Don’t overcomplicate things.
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.
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.