A team needs fuel.

Fuel

The ability to produce valuable work is the sole focus of any performing team. Much like an engine, a team will need fuel (tasks) to burn though to create a potentially shippable product. However, just providing high-quality tasks will not be enough. Each team is different, and the right mix of tasks and air (breathing room) need to be adjusted in order to allow the team to succeed.

An engine can run on anything, it may not be efficient and produce a lot of waste, but it will still run (until it kicks out). For example, you can run an engine on Crude oil but expect the engine to struggle and need to work harder for the same results as normal petrol. In addition, it can cause damage to the system and produces a lot of waste.

Teams need fuel in order to operate. How these tasks are presented and the quality of them matter. By providing a team with vague requirements, unfocused tasks with large amounts of scope and unclear outcomes, in effect the team has been provided an unrefined fuel. These unrefined tasks cause inefficiency within the team, leading to more strain and a need to work harder in order to produce output.

Think of this when providing unclear, crude tasks to a team to plan and implement. Although they will output, it will also create a lot of waste such as technical debt and a lot of coughing and spluttering until they break down. Expect a lot of rework in order to produce the same task if it had only been refined

Improving to premium quality

Improving the standard of tasks that will be provided to a team undoubtedly will increase the output. Not only will it reduce the strain on the team, but it will also clarify requirements and answer questions upfront, saving countless hours of adapting the product to suit the user’s original needs. By spending minutes in upfront clarification, hours can be saved from un-needed changes in scope and unknown requirements.

User Stories

One powerful way of providing clear requirements is the User Story format “As a… I need…. So that”.

As an Engine, I need higher quality fuel, So that I can function more efficiently.

This format focuses on the end-user or customer of the request, be it a Marketing Executive, Product Owner, Customer or Developer, meaning that the request has been brought back to the needs of the user. This focuses the team to solve business-level problems as opposed to just thinking from a technical perspective.

In addition, adding Acceptance Criteria to each story provides the team with a clear set of guidelines on what they need to achieve and test against.

The type of fuel will need to be petrol

The type of petrol needs to be Premium 95 as a minimum

From this, a team knows that it must use premium 95 petrol in their car, however, they know that they can choose from any supplier and any garage so long as it meets these requirements.

Providing clear requirements and focusing on the end-user will improve the quality of tasks into the system, generate better responses and quality of work, and reduce time scales. This, however, does not reduce the need to communicate, even when working from a description like this, involve the Product Owner to clarify and involve the end-user to make sure their needs are being met.

These work especially well in a Scrum Sprint in which the team can be a part of planning these before committing to them, increasing the quality of what goes into a Sprint and enabling team Definitions of Ready.

A3 management

Notably used in Toyota, A3 management requires project and tasks to be planned on a single page of A3 paper. No heavily documents risk reports or benefits causes that span hundreds of pages, just a single page.

Starting with the current situation, describing what is happening now, the Product Owner will describe their intended goal/ target clearly countermeasures, acceptance criteria, root cause analysis, and expected results.

Title – Name the problem, issue, or topic

Owner/Date –

Current Situation - Analysis of need and contributing conditions – Show the current state using pictures, graphs, etc. What is the problem?

Goals/ Target Existing value, expectation, Policy, Goal or Plan – why Is this important? What background info do you have?

Countermeasures: what proposed actions do you intend to take to reach the target condition? How will you show how your countermeasure will address the root cause of the problem? What is the new standard process?

Acceptance Criteria - What needs to happen for this to be accepted? How will you test against this?

Root Cause Analysis - What is the root cause(s) of the issue?

Expected Results - When/ how will they be checked? How will you capture and share learning?

A very useful way of radiating this information is to position it on a wall in the team area, where it can be view daily as a reminder of a high-level task, epic or project. This will always keep the context clear, keep the focus on the desired outcomes, resolve any discrepancy or need to pivot based on new information.

5 Whys

The 5 Whys is a fantastic example of root cause analysis. Instead of seeing the first issue and deeming that to be the problem, you may find that it is simply a symptom of a larger or unknown fault deep within the system itself.

The vehicle will not start. (the problem)

#1 Why? – The battery is dead.

#2 Why? – The alternator is not functioning.

#3 Why? – The alternator belt has broken.

#4 Why? – The alternator belt was well beyond its useful service life and not replaced.

#5 Why? – The vehicle was not maintained according to the recommended service schedule. (root cause)

By using this format when facing an issue within the software or the team, you will be able to understand the reason for such behaviors and tackle the right problem. Who knows, you may find out that by fixing this root cause solves a number of issues that already populate your Backlog!

Air

For an engine to turn petrol into power, it needs not just fuel but air. The right mix of air and fuel is needed to achieve the right environment to create power, too much or too little of either will leave the engine either suffocated or swamped and little will be achieved.

Teams also need air, in the form of time to take a breather. Teams need slack time, not just to ease the pressure but to also inspect and adapt their ways of working. Without this, a team will continue to use bad practices, become overburdened and produce limited results. Too much air will lead to a directionless team, and value-adding work will take longer. (This last statement depends on the team, a self-organizing team capable of preparing value-adding work may use the slack time effectively. It simply depends on the engine the team has depends on how much more air can be added).

Air can take the form of team lunches to hackathons, process improvements to technical debt repayment. These are vital to any functioning team to be able to achieve not only internal team objectives such as meeting the Sprint Goal but also Company-wide goals such as value-adding functions and products that make the business more competitive and profitable.