Agile IQ®

Stage one

Agile IQ® Score: 0-48

What is a "stage one" team?

A team at this stage of its agile journey is in the Shu stage of Shu Ha Ri. A Stage One team has an Agile IQ of 0-48.

A Stage One team is typically either just learning how to be agile, or hasn’t firmly committed to changing the way that they work. Stage One teams deliver successfully because they rely on talented individuals. Undere the CMMI model, this is CMMI Maturity Level 1.

Delivery depends on talented people, but because skills are embedded in specific individuals, delivery isn’t scalable and success isn’t repeatable. A team at this stage of its agile journey is typically either just learning how to be agile, or hasn’t firmly committed to changing the way that they work.

Choosing an agile framework to serve as guardrails for teams, and just doing the basics in a consistent way, is key to evolving to the next level.

Archetypal behaviours

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

Ad-hoc task management. These teams deliver, but rely on the talents of specific people to get them over the line. Managers manage and direct the team through task delegation and reporting on task completion.
Waterfall linear approaches to work – attempting to handle complexity and changing environments by big, upfront planning.
Optimisation for utilisation by ensuring that each individual is “busy”.

Skilled individuals in the team help minimise delivery risk, but the capability isn’t scalable or repeatable.

What to expect in Stage One

Cost Savings: None.
Improved Productivity: None.
Improved Quality: None
Improved Transparency: Low
Improved delivery speed: None.

The organisation is unlikely to see any improvement in these areas until teams actually change the way they work. If teams only tweak their current work practices and use the “signs” of agile (e.g. visualisation and erroneously calling it Kanban), there will only be, at best, an improvement in transparency of the status of work.

Diagnosing agile and delivery problems

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

Business-as-usual, and urgent un-planned work distracts teams from delivering their planned work. These teams make delivery promises but then get distracted by other people’s priorities. The guardrails must establish one “front door” for the team and work prioritised by the team’s Product Owner.
Teams rush ahead with customising agile before understanding how to make best use of the basics. Choose a framework and embed it in the team’s operating model by establish guardrails.
Leaders don’t fully support self-management. If they continue to “task manage” people, and hand out and delegate tasks, and direct individual’s work, teams are unlikely to evolve beyond low Stage Two and therefore unlikely to get fastee to market or improve throughput.

Where to focus

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.

Promote self organisation

Start to move away from task delegation, and management of individuals, to using guardrails to set expectations about delivery.

Establish key agile roles and cross-functional teams

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

If these areas of focus are not attended to, the organisation is not likely to receive the benefits of agile.

Anti-Patterns to watch out for

Anti-patterns in Stage One all reflect resistance to teams changing the way they work.

Without changing the way they work, leadership will receive none of the benefits of agile.

“We take what works”

“We take what works” is short hand for “we haven’t changed the way we work”.

Many teams start out by selecting a few key agile practices they either like or they feel best suits their current way of working. Unfortunately, this results in the team not changing their current behaviours. If they don’t change the way they work they won’t get any of the benefits agile can bring.

Visual management for these teams may improve transparency of delivery, but it is unlikely to yield improved productivity or cost savings.

“Can’t we just do Kanban?”

Many feel that the basics of Scrum are too hard because it requires teams to change the way they work. Teams at Stage One are often tempted as a result to just “do Kanban”. These teams then implement the visual management aspect of Kanban, but none of its other practices, including optimising flow, minimising work in-progress, and defining explicit progression criteria. Just implementing these “symbols” of agile gives leadership the false impression that the team is agile.

This is called “Cargo Cult” agile.

“We’re just being pragmatic” / “You’re being a purist”

Using pragmatism is an excuse not to change. These teams feel that they are serving delivery by selecting the elements of agile that suit their current way of working. Any suggestion they should change is then labelled as being “purist”.

Teams with these behaviours will often relate that delivery will be at risk if they are required to change the way they work.

“But we’ll lose our capability if we form cross-fucntional teams”

Many organisations have functional teams. Teams that are based on a single function or capability that managers delegate to a number of projects. When faced with the change to form cross-funcitonal teams, many will claim:

Delivery will be at risk.
Quality will suffer.
Their specialised service/support will diminish.
It will limit their professional growth.

These claims are made as a form of change resistance.

Keys to improvement

Establishing guardrails for self-management is the key establishing the groundwork to getting higher productivity and reducing cost savings.

Self-management over traditional task management alone will increase productivity by approximately 10-15%.

Action #1: Establish guardrails

What are guardrails?

Guardrails are a leadership tool to ensure alignment with the organisation’s goals and objectives and to keep teams on the right path. In essence, they are the foundation of an organisation’s agile operating model.

Guardrails for agile teams form the minimum set of rules established, communicated, and reinforced by leaders regarding:

Team composition – cross-functional teams over functional or single capability teams
Team decision-making – what’s in their power to made decisions on and change and what isn’t.
Planning cycles – every Sprint, every week, month?
Delivery quality and frequency – what is required to build-in quality (“Definition of Done”), are teams expected to do continuous delivery and release on demand?
Minimal set of roles, events and artefacts – Product Owners, Scrum Masters and backlogs.

According to the State of Agile Survey, approximately 80% of leaders use Scrum as their minimal set of guardrails for their teams. Deliberately incomplete, its 3 roles, 3 artefacts, 5 events and 3 areas of comitment provide a framework that can be added to based on the context.

Many teams will later add (typically in Stage Three) additional practices to Scrum, such as:

Kanban.
Extreme Programming.
Lean UX.

Within these guardrails, teams are expected to self-organise.

Communicating guardrails

While teams are in Stage One, the role of leadership is to communicate the change required by teams to align to the new operating model and to encourage, promote and support teams to change.

If given the choice not to change, teams and their managers are likely to simply continue the way they currently work.

Focus on Agile IQ® improvement actions that impact:

Self-organisation – Creating a Team Charter to create a social contract that adheres to management’s guardrails.

Action #2: Promote self-organisation

What is self-organisation?

Self-organisation isn’t chaos. It requires management to set guardrails that define the boundaries for team-level actions, behaviours, and expected outputs.

The stronger a team’s self-organisation behaviours, and the more managers support and encourage self-management, the stronger the outcomes agile brings: faster to market, higher quality, improved predictability, lower delivery risk and and transparency.

Self-organising teams are more productive and achieve their goals more often than traditionally managed teams.

Action #3: Establishing key agile roles and cross-functional teams

What key roles?

Scrum is used by 80% of organisations to establish guardrails for teams. With this agile framework comes three essential roles:

Product Owner: Responsible for delivery of value aligned to organisational goals.
Scrum Master: Accountable for ensuring that team operate within the guardrails and that agile is effective in delivering enterprise outcomes – lower costs, higher quality, higher productivity. The Scrum Master isn’t an agile project manager or a delivery manager. They help the team be effective through promoting self-organisation and cross-functionality.
Team members: Scrum refers to the people developing solutions and delivering the work, regardless of what it is, as “developers”.

What Is a Cross-Functional Team?

While most departments are organised by expertise and purpose, cross functional teams are groups of people with different viewpoints and expertise who collaborate to achieve a common objective.

Cross functional teams are groups of people from various departments in an organisation—such as marketing, product development, quality assurance, sales and finance—who work together to achieve a common goal. Oftentimes, cross functional teams are organised to complete a specific project, but they can also be created with a more ongoing purpose.

Benefits of a Cross-Functional Team

Cross functional teams break through the “silos” of a traditional organisational structure so that the team can see the big picture. By working with members who have varying viewpoints, expertise and backgrounds, the collective team can more efficiently tackle problems and achieve the goals of a project. They can also anticipate hurdles earlier in the process because each department has input throughout the process, rather than a project moving from department to department.

Cross-Functional Teams Promote the Goals of the Organisation

When departments operate primarily within their specific vertical, they often focus on their own goals without seeing the big picture. For instance, the sales team may be concerned about securing new customers but they lose sight of the personnel issues involved with an overwhelmed crew. The finance team might be so focused on the bottom line that they are hesitant to take on the risks of launching a new product line. And the marketing team might be so eager to launch a new brand or product that they aren’t focused on product development challenges.

By putting together people with seemingly competing day-to-day goals, you can ensure that the goals of the organisation are advanced throughout the entire project.

Cross-Functional Teams Increase Efficiency

Instead of a project moving through one department before being passed off to the next, cross functional teams increase the efficiency of project completion. Because you are working with personnel from other departments, the team can address potential challenges before moving too far along in the process.

For instance, if the product development department creates an innovative new product, only to find out that the sales department has concerns about actually selling the product, there will be wasted time in the project. On the other hand, if the sales department works alongside product development in a cross functional team, the potential challenges can be addressed earlier on to minimise lost time and sunk costs.

Cross-Functional Teams Can Increase Innovation

Departments often become so focused on sharpening their own skills and achieving their specific goals that they lose sight of the big picture. Siloed departments can get stuck in a rut. But by combining different viewpoints and knowledge, cross functional teams can increase innovation of both processes and products. They can find holistic solutions to meet the needs of the organisation because they can see the perspectives of other functionalities.