This ‘Problem Detection and Resolution: Fishbone Diagram’ tutorial is a part of the PMI-ACP certification course offered by Simplilearn. We will come across Fishbone Diagram, Work In Progress (WIP) and other problem-solving techniques in this tutorial.
After completing this tutorial, you will be able to:
The success of any project depends on how quickly and effectively the team resolves its problems. Often, a team with high operational focus fails to detect and address problems. If left unresolved, the problem debt continues to mount over time, leading to delays and rework, thus derailing the project schedule.
There are various ceremonies in Agile to identify and address problems, however, the following meetings focus specifically on problem detection:
Some of the techniques to identify problems and determine root cause are:
Let us understand in detail about Fishbone Diagram and its importance.
A fishbone diagram, also called Ishikawa diagram or cause-and-effect diagram, is an effective and quick way to identify the root cause of an issue or defect and decide on corrective actions. You can use the Fishbone diagram in conjunction with the 5 Whys tool to quickly pin down a problem.
Apply this technique to identify all possible causes of a problem, and use the outcome of process improvements. In this technique, the causes derive from the main categories, which in turn, branch out from the main problem or effect. The resultant diagram resembles a fishbone.
The steps in a fishbone diagram analysis are:
Eager to know about other problem-solving techniques? Click for course preview!
Let’s understand the usage and importance of the 5 Whys tool.
5 Whys is a technique of identifying the root cause of a problem by repeatedly using the question “Why.”
The answer for each “Why” drives the next “Why.” Suppose there is a delay in the delivery of a product.
The first “Why” question would be - “Why was the product not delivered on time?”
Let’s say the reason is that the requirements were not delivered on time.
The question and answers continue as follows - Why were the requirements not documented in time? If the answer was that the Product Owner was not available, then why was the Product Owner unavailable?
Let’s say the Product Owner was pulled into a parallel project. If that’s the case, why was there no substitute for the Product Owner?
If the answer to this was that this role was not defined, then why was the escalation channel not used to identify a workaround?
The answer to this - The team was not aware that an escalation channel exists for this problem.
As you can see, by repeatedly asking “Why”, it is possible to pin down the likely cause of the problem, which in this case was delayed product delivery. It is not mandatory to use exactly five “Whys” to drill down to the root cause, five being only an indicative number. This technique is used along with the fishbone diagram to provide a visual of the problem being analyzed and the categories into which the answers or causes fall.
Control Charts help establish controls on key parameters in the project. These charts are graphs with control limits, both upper and lower control limits, which are used to monitor the behavior of a process over time. Setting control limits helps detect whether signals lie within or outside the limits. Signals outside the limits indicate that the process is out of control and therefore unpredictable.
Hence, corrective measures have to be implemented to bring the project back under control. A process is also considered to be out of control if either of the “Rule of 7” conditions occurs: seven consecutive points on one side of the mean or seven consecutive points in ascending or descending order. In the chart, the upper and lower limits show the ranges where a data point will fall within six sigma or 99.9997% of the time.
Note that Agile projects experience different velocities and varying amounts of defects between iterations. By capturing such metrics on a Control Chart and setting up the mean, upper and lower control limits help understand if the development process is in control or out of control.
In software development, Lead Time or LT, also known as Software in Process or SIP, is the number of days between feature specification and delivery to production. In other words, it is the time business stakeholders have to wait for their requirement to be captured, designed, developed, and made available for production. Lead Time equals Cycle Time or CT multiplied by WIP or, LT equals WIP divided by T.
Where, WIP is Work in Progress;
T is Throughput or the rate of output;
Cycle Time is the time the team requires to convert a requirement into a working solution.
It starts when the team picks up a requirement for development and stops when the software is ready and bug-free.
Remember that, a long Cycle Time or Lead Time implies there are difficulties in addressing requirements; the overall Lead Time can be reduced by keeping the CT at a minimum, and doing so demonstrates how agile and responsive the organization is to the needs of the end customer.
Let’s understand the technique of Work In Progress (WIP) and its working below.
Work in Progress or Work in Process, WIP, refers to those requirements the team has started working on, but are not yet complete. Like, the amount of work the team is currently engaged in. Lean principles recommend limited requirements to be WIP, as having a long list of WIP results in:
Kanban boards are used to visualize and limit the amount of WIP, without which efficiency issues can result from teams being tempted to pick up more requirements that can be handled, and difficulty in identifying persisting blockers.
The image depicts a Kanban board with the WIP limits set. In it, the workflow is broken down into granules called Backlog, Selected, Review or Fix, Validate, Merge, Update Docs, and Done.
Anything between Backlog and Done can be termed WIP. The philosophy of Kanban is to minimize WIP by setting explicit limits, which allows downstream processes to determine when they can consume more work.
You can see the Selected granule has a WIP limit set to three and therefore, there are only three cards being worked on by the team at any point in time. If WIP exceeds the threshold, then the assembly line stops until the bottlenecks are removed.
WIP limits help focus on bottlenecks in the system and trigger appropriate corrective action. Work in upstream processes stops if a WIP limit is reached.
WIP limits ensure an emphasis on the team’s throughput, that is, how fast products are developed by the team, rather than on individual productivity, that is, how efficient each individual is performing.
This subtle shift in focus creates a positive synergy within the team, enables them to spend time on innovations, and helps them transform into a High-Performance Team.
Cumulative Flow Diagrams, or CFDs, were introduced by Lean thought leaders Don Reinertsen and David Anderson. It is an important tool for tracking and forecasting Agile projects. It tracks work at different stages, such as “Total Scope”, “Completed” and “In progress”.
The same report can provide insight into the Burn-up chart, Cycle Time, Work In Progress, and Bottlenecks in one place. This information helps the ScrumMaster to focus on the areas requiring attention, improving the throughput of the team.
Here, you can see an example of a CFD. The red area shows the total planned work for the release. It starts at 400 points, goes up to 450 and then to 500 as the release progresses. The green portion indicates the amount of work that has been completed. It starts at zero and continues to increase as the team continues to deliver the work. The yellow area shows work that is started but not yet complete, that is, the WIP. This helps to understand how fast the team is able to turn the work over.
One of the focus areas of Lean is to minimize inventory. A CFD helps in determining the amount of inventory in the system. Little’s law states that the amount of inventory can be calculated by multiplying the throughput and the flow time or Cycle Time.
Throughput is calculated by dividing the WIP by the Cycle Time. In the CFD shown here, the vertical distance, or Y, covered by the “In Progress” area represents the WIP, while the horizontal distance, or X, represents the Cycle Time.
Let’s look at an example for Little’s Law. If there are ten user stories in progress, and it takes six hours to complete one user story, then the throughput, T, is equal to Work In Progress, that is, 10, divided by the Cycle Time, six hours.
Therefore T equals 1.6 stories per hour. Conversely, if it takes 1.6 hours to complete a story, and the story enters the In-Progress queue and is in the tenth place, then it will take 10 multiplied by 1.6, or 16 hours to address the story.
CFDs can also be modified to show more detail for activities within the WIP area. This is particularly useful to get a sense of how activities are progressing, as it reflects what the team is directly working on and what can be controlled.
In this graph, the WIP area has been broken into three activities: Started, Designed, and Coded. Other categories can be easily added depending on the project structure and needs. You can also use this approach to identify if there are any bottlenecks affecting the delivery team’s throughput.
The bottleneck is indicated by a widening area at the top of an activity. In the example chart, the green area, ‘Analysis’, appears to be widening. Although ‘Analysis’ is progressing well, the ‘DB Process’ is below the widening band, indicating a slower rate of progress and a warning that it is a bottleneck in the system. The likely cause of this is that the ‘DB Process’, is not consuming the output of the previous step, ‘Analysis’, at the expected rate, therefore creating an inventory. In the context of user stories, this could mean user stories are being created but not being worked on.
There is a risk of a growing time lag between story creation and the demonstration of a completed story. This delays feedback and presents opportunities for more changes, possibly leading to a waste of time and effort. A well-defined process minimizes or eliminates inventory.
Interested to know more about PMI ACP? Click here!
Pausing to solve problems as soon as they appear is important to the success of any team. In Agile, problems can occur at the following levels:
Here are some problem-solving techniques used in Agile projects. As an Agile project manager:
Let us summarize the topics covered in this lesson:
This concludes ‘Problem Detection and Resolution: Fishbone Diagram’ tutorial. The next part of the domain is ‘Problem Detection and Resolution - Agile Risk Management.’
Name | Date | Place | |
---|---|---|---|
PMI-ACP® Certification | 6 Feb -27 Feb 2021, Weekend batch | Your City | View Details |
A Simplilearn representative will get back to you in one business day.