1. Home
  2. Training Library
  3. Module 3 - Managing Conflict

The 5 Whys

Developed with
QA

Contents

keyboard_tab
Managing Conflict in Agile Teams
2
The 5 Whys
PREVIEW5m 9s

The course is part of this learning path

Managing Conflict in Agile Teams
course-steps
4
description
1
play-arrow
The 5 Whys
Overview
DifficultyBeginner
Duration22m
Students166
Ratings
4.8/5
starstarstarstarstar-half

Description

Course Description 

This module is about managing conflict. It outlines a management strategy for dealing with constructive and destructive conflict and introduces a range of troubleshooting methods to identify the cause of conflict, including the ‘5 Whys’ technique. After that, it provides guidance on the techniques that you can use to resolve conflict situations.   

Learning Objectives 

The objectives of this course are to provide you with and understanding of: 

  • The different strategies for managing conflict. 
  • The management behaviors which support effect conflict resolution. 
  • The different methods which can be used to deal with conflict. 
  • The analysis techniques which can be used to troubleshoot and solve non-complex problems.  
  • The Scrum Master’s role in managing conflict. 
  • The techniques a Scrum Master can use to manage conflict within Agile teams. 
  • The importance of emotional intelligence in effectively addressing conflict situations. 

Intended Audience 

The course is aimed at the Agile Scrum Master. However, it’s equally relevant to the Product Owner’s role in the team. 

Prerequisites of the Certifications 

There are no specific pre-requisites to study this course 

Feedback 

We welcome all feedback and suggestions - please contact us at qa.elearningadmin@qa.com to let us know what you think. 

Transcript

Keep asking ‘why?’ 

The 5 Whys is a technique you can use for troubleshooting and solving simple or moderately difficult problems – or conflict situations. 

 

Many problems at work are just symptoms of deeper issues. So, to solve a problem effectively and stop it coming back, you need to drill down to identify the underlying cause. The 5 Whys is an approach to finding a resolution to a problem with a single cause – you start with the problem you’re facing and ask ‘why?’ until you’ve got to the root cause. 

 

Here’s an example of how this technique might work. 

 

Imagine the IT team in your organization has just rolled out new software to track expenses. But no one on your team is using it, even though they’ve all been trained.  

  • You start by asking why people aren’t using the new software. They say they don’t like it and that it’s a pain to use; 

  • Then you ask ‘why’ they don’t like it. They tell you that the system asks them for information they don’t have; 

  • Then you ask them ‘why’ they don’t have the necessary information. They say that the system wants their scanned receipts, which is fine, but it also wants them to list what they bought. Sometimes the receipts don’t list individual items. When this happens, they can’t use the software.  

 

In this case, it took just three ‘why’ questions to get to the root of the problem. The system is asking for information that your people often don’t have. So, they’re avoiding it because it’s not useful.  

 

If you hadn’t used the 5 Whys technique you might have just got angry with your team again for not using the software. But now you know what you need to do to resolve the situation.  

 

So, in summary… 

  • State the problem to help visualize it and gain everybody’s agreement; 

  • Ask ‘why is it happening’? 

  • Drill down by asking more ‘why’ questions; 

  • Stop when you think you’ve found the root cause; 

  • Agree a countermeasure to resolve the issue and follow it through so the problem doesn’t happen again. 

 

5 Whys isn’t going to work for complex or critical problems where there might be multiple issues causing conflict. For these, more in-depth methods are needed. 

 

Cause and effect analysis 

(AKA fishbone diagrams, herringbone diagrams and Fishikara diagrams) 

This is a 5-step process introduced by Professor Ishikawa in the 1960s and it ends up looking like the bones of a fish – hence the different names. It combines brainstorming and mind-mapping. 

 

  • First you identify the problem and write it down. Then you draw the spine of the fish from the definition; 

  • Then identify the factors that are part of the problem and draw these off the spine; 

  • For each of the problem stems, brainstorm possible causes – these can be broken down as much as you need to; and 

  • Finally, analyze all the possible causes noted on the diagram to narrow down which ones are contributing to the problem, and work out whether further investigation or resolution actions are required.  

 

FMEA – Failure Mode and Effects Analysis 

Failure Mode and Effects Analysis – or FMEA – is a process analysis tool which looks at issues with the design, process, product or service. 

 

 

In very general terms, it starts by assembling a cross-functional team of people with diverse knowledge of the process, product or service – including a wide range of different stakeholders. Flowcharts are used to define the scope of the process or service so everybody’s clear. 

 

The initial information is completed in the FMEA form to breakdown the steps of the process, and look at the potential failure effects and consequences. Each effect is then given a severity rating of 1-10 and a detection rating based on the effectiveness of the existing controls. These are combined to give a risk priority number – or RPN. 

 

Then recommended actions are identified, starting with the issues rated with the highest RPN, and, as actions are completed the severity, detection and RPN ratings are updated.  

 

The cause and effect and FMEA analysis approaches do take a fair amount of time to go through. A simple approach, like the 5 Whys can often quickly direct you to the root cause of a problem. So, whenever a system or process is causing conflict, do the simple things first and introduce additional techniques where you think you need to. 

 

There’s more information about problem solving techniques in the ‘Cause and Analysis’ video and ‘Failure Mode Effects Analysis’ guide. You’ll find links in the Managing Conflict Resources. 

About the Author
Students2957
Courses36
Learning paths9

Tony has over 20 years’ experience in Business Development, Business Change, Consulting and Project/Programme Management working with public, private and third sector organisations.

He has helped organisations to design and create process and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider utilising a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.

As a confident and self-motivated professional with excellent communication skills Tony is able to bring people together and get them working as a team quickly.

Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Programme and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers and worked at Director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.