Problem Detection and Resolution - Part 1 Tutorial

Hello and welcome to Domain VI—‘Problem Detection and Resolution’ of the PMI-ACP Certification course offered by Simplilearn. This is the first part of this domain.

After completing this lesson, you will be able to: • Explain the importance of problem detection in Agile projects • Discuss the techniques of problem detection: Fishbone Diagram; 5 Whys; Control Limits; Lead Time and Cycle Time; Escaped Defects; and Work In Progress • Explain the Cumulative Flow Diagram and its use in identifying bottlenecks • Explain problem-solving and related techniques

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: • Daily Standup: the third question in Daily Standups–"Are there any blockers or impediments to completing a task?” • Sprint Retrospection meetings Agile helps address problems proactively, ensures timely resolution, and enables the team to deliver results.

Some of the techniques to identify problems and determine root cause are: • Fishbone Diagram • 5 Whys • Control Charts • Lead Time and Cycle Time • Escaped Defects • Work In Progress or WIP

A fishbone diagram, also called Ishikawa 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 this 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 for 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 analysis are: First, identify the problem to be solved and enclose it in a box on the right. Next, determine the major categories of causes. You can use the McKinsey 7S Framework —that is, Strategy, Structure, Systems, Shared Values, Skill, Style, and Staff—or, the 4Ps of Marketing—Product, Place, Price, and Promotion—as a starting point. Place the major categories as branches from the problem box. Last, allow the team to brainstorm and identify possible causes under each category. Insert these causes so that they branch off from the major categories. Prioritize the major causes contributing to the problem, and take necessary actions to resolve them.

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.” Let’s understand this with the help of an example. 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 the requirements were not delivered on time. The question and answers continues as follows: Why were the requirements not documented in time? The Product Owner was not available. Why was the Product Owner unavailable? The Product Owner was pulled into a parallel project. Why was there no substitute for the Product Owner? This role was not defined. Why was the escalation channel not used to identify a workaround? 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 occur: 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 helps 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.

Escaped defects are those which are not captured by the Quality Assurance team during testing, and are identified by the end user or business during live operations of the developed software. Capturing this metric over every release for multiple releases helps you understand if the Quality Assurance and Quality Control measures are robust or have to be revisited. Escaped defects are the most costly to fix, as they occupy the top of the ‘Cost of Change’ curve. The impact of escaped defects is more than just the work required to fix them. It affects the product’s brand value and the organization’s reputation, and gives rise to litigation costs. Product defects can also adversely impact customer property or even people’s lives. Escaped defects are captured and tracked over a period of time–a day, week, or month. Trend analyses help identify if the number of escaped defects increase or decrease over a time period. The illustration shows the number of escaped defects tracked on a weekly basis, represented as a bar chart.

Work in Progress or Work in Process, WIP, refers to those requirements the team has started working on, but are not yet complete; that is, 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: - Sunk cost, or the money that is invested but is not producing any returns - Hidden problem areas, making it difficult to diagnose the issue - More rework, if business expectation change suddenly 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 than can be handled, and difficulty in identifying persisting blockers.

The image depicts a Kanban board with the WIP limits set. In it, the work flow 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 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 emphasis on the team’s throughput, that is, how fast products are developed by 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 from 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 from 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 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.

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 approach to identify if there are any bottlenecks affecting the delivery team’s throughput. Let’s see how in the next screen.

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.

Pausing to solve problems as soon as they appear is important for the success of any team. In Agile, problems can occur at the following levels: Process level: How well is the team adopting Agile? Quality and performance level: How can the team perform better? Team dynamics level: How can the team work better together?

Here are some problem-solving techniques useful in Agile projects. As an Agile project manager: Establish yourself as a devil’s advocate: The goal is to help the team re-verify their assumptions. Make it clear that you will ask a lot of questions. The questions should not be framed in a manner challenging the team, rather, they must help the team think differently and be open to alternatives. Don’t let the team linger on meta-problems: They are distractions from the real issue. Relentlessly focus on the big problem, as smaller or meta-problems only represent symptoms or side issues. It is tempting to stay on the meta-problems because they are smaller and easier. Be kind, rewind: Ask a lot of questions, forcing the team to step back and push towards the root cause. Ask probing questions: Make the team talk through each decision and ask questions. Scrutinize the team members, understand what they are thinking by asking a lot of probing questions. Use reflective listening: Reflective listening is a technique in which the listener repeats or paraphrases what is just heard. The purpose of this technique is to confirm understanding and reassure the speaker that the communication was heard. Avoid injecting your ideas: Do not prompt the team to select a new idea, even if it could be a better approach. This is to avoid the team stopping their analysis and looking to you to solve the problem for them. Lead them to the answer: If the team is not making progress, lead them to the solution by providing small cues, asking questions, and giving hints, and not the answer directly.

Following is the quiz section to check your understanding of the lesson. Select the correct answer and click Submit to see the feedback.

Let us summarize the topics covered in this lesson: • Agile projects have a strict and short delivery schedule. To ensure consistent delivery, problems impacting project’s progress must be progressively identified and resolved in a timely manner. • The Ishikawa or Fishbone diagram is one of the commonly used techniques to identify the root cause of a problem, and is mostly used in conjunction with the 5 Whys Technique. • Control limits are used to detect signals that indicate when a process is not in control, and therefore not operating predictably. • Escaped defects are the ones not found by the QA team, but by the end users post-release. • WIP refers to those requirements the team has started working on, but are not yet complete. WIP limits are set to minimize sunk cost and waste. • A CFD helps track work at different stages, the total scope, amount of work that is completed, and the amount of work in the “In-Progress” state.

This concludes ‘Problem Detection and Resolution, part 1.’ The next part of the domain is ‘Problem Detection and Resolution, part 2.’

Hello and welcome to Domain VI—‘Problem Detection and Resolution’ of the PMI-ACP Certification course offered by Simplilearn. This is the first part of this domain.

After completing this lesson, you will be able to: • Explain the importance of problem detection in Agile projects • Discuss the techniques of problem detection: Fishbone Diagram; 5 Whys; Control Limits; Lead Time and Cycle Time; Escaped Defects; and Work In Progress • Explain the Cumulative Flow Diagram and its use in identifying bottlenecks • Explain problem-solving and related techniques

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: • Daily Standup: the third question in Daily Standups–"Are there any blockers or impediments to completing a task?” • Sprint Retrospection meetings Agile helps address problems proactively, ensures timely resolution, and enables the team to deliver results.

Some of the techniques to identify problems and determine root cause are: • Fishbone Diagram • 5 Whys • Control Charts • Lead Time and Cycle Time • Escaped Defects • Work In Progress or WIP

A fishbone diagram, also called Ishikawa 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 this 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 for 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 analysis are: First, identify the problem to be solved and enclose it in a box on the right. Next, determine the major categories of causes. You can use the McKinsey 7S Framework —that is, Strategy, Structure, Systems, Shared Values, Skill, Style, and Staff—or, the 4Ps of Marketing—Product, Place, Price, and Promotion—as a starting point. Place the major categories as branches from the problem box. Last, allow the team to brainstorm and identify possible causes under each category. Insert these causes so that they branch off from the major categories. Prioritize the major causes contributing to the problem, and take necessary actions to resolve them.

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.” Let’s understand this with the help of an example. 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 the requirements were not delivered on time. The question and answers continues as follows: Why were the requirements not documented in time? The Product Owner was not available. Why was the Product Owner unavailable? The Product Owner was pulled into a parallel project. Why was there no substitute for the Product Owner? This role was not defined. Why was the escalation channel not used to identify a workaround? 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 occur: 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 helps 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.

Escaped defects are those which are not captured by the Quality Assurance team during testing, and are identified by the end user or business during live operations of the developed software. Capturing this metric over every release for multiple releases helps you understand if the Quality Assurance and Quality Control measures are robust or have to be revisited. Escaped defects are the most costly to fix, as they occupy the top of the ‘Cost of Change’ curve. The impact of escaped defects is more than just the work required to fix them. It affects the product’s brand value and the organization’s reputation, and gives rise to litigation costs. Product defects can also adversely impact customer property or even people’s lives. Escaped defects are captured and tracked over a period of time–a day, week, or month. Trend analyses help identify if the number of escaped defects increase or decrease over a time period. The illustration shows the number of escaped defects tracked on a weekly basis, represented as a bar chart.

Work in Progress or Work in Process, WIP, refers to those requirements the team has started working on, but are not yet complete; that is, 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: - Sunk cost, or the money that is invested but is not producing any returns - Hidden problem areas, making it difficult to diagnose the issue - More rework, if business expectation change suddenly 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 than can be handled, and difficulty in identifying persisting blockers.

The image depicts a Kanban board with the WIP limits set. In it, the work flow 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 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 emphasis on the team’s throughput, that is, how fast products are developed by 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 from 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 from 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 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 approach to identify if there are any bottlenecks affecting the delivery team’s throughput. Let’s see how in the next screen.

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.

Pausing to solve problems as soon as they appear is important for the success of any team. In Agile, problems can occur at the following levels: Process level: How well is the team adopting Agile? Quality and performance level: How can the team perform better? Team dynamics level: How can the team work better together?

Here are some problem-solving techniques useful in Agile projects. As an Agile project manager: Establish yourself as a devil’s advocate: The goal is to help the team re-verify their assumptions. Make it clear that you will ask a lot of questions. The questions should not be framed in a manner challenging the team, rather, they must help the team think differently and be open to alternatives. Don’t let the team linger on meta-problems: They are distractions from the real issue. Relentlessly focus on the big problem, as smaller or meta-problems only represent symptoms or side issues. It is tempting to stay on the meta-problems because they are smaller and easier. Be kind, rewind: Ask a lot of questions, forcing the team to step back and push towards the root cause. Ask probing questions: Make the team talk through each decision and ask questions. Scrutinize the team members, understand what they are thinking by asking a lot of probing questions. Use reflective listening: Reflective listening is a technique in which the listener repeats or paraphrases what is just heard. The purpose of this technique is to confirm understanding and reassure the speaker that the communication was heard. Avoid injecting your ideas: Do not prompt the team to select a new idea, even if it could be a better approach. This is to avoid the team stopping their analysis and looking to you to solve the problem for them. Lead them to the answer: If the team is not making progress, lead them to the solution by providing small cues, asking questions, and giving hints, and not the answer directly.

Following is the quiz section to check your understanding of the lesson. Select the correct answer and click Submit to see the feedback.

Let us summarize the topics covered in this lesson: • Agile projects have a strict and short delivery schedule. To ensure consistent delivery, problems impacting project’s progress must be progressively identified and resolved in a timely manner. • The Ishikawa or Fishbone diagram is one of the commonly used techniques to identify the root cause of a problem, and is mostly used in conjunction with the 5 Whys Technique. • Control limits are used to detect signals that indicate when a process is not in control, and therefore not operating predictably. • Escaped defects are the ones not found by the QA team, but by the end users post-release. • WIP refers to those requirements the team has started working on, but are not yet complete. WIP limits are set to minimize sunk cost and waste. • A CFD helps track work at different stages, the total scope, amount of work that is completed, and the amount of work in the “In-Progress” state.

This concludes ‘Problem Detection and Resolution, part 1.’ The next part of the domain is ‘Problem Detection and Resolution, part 2.’