Using the Five Whys to Find Change Management and DevOps Impediments to Agile Transformation

Agile - DevOps - Organizational Change Management

Becoming more agile in your organization is not a simple change. It requires discipline, focus, and anticipation from all involved. Let's look at using the "5 Whys Technique" when examining Agile transformation issues and see if we can derive some relationships between Agile Success, DevOps Practices, and Organizational Change Management.

While there are an infinite number of things that can cause issues that keep the team from finishing stories, having the discipline and rigor to continually discover the root cause will more often than not lead to change management challenges. These change management issues usually are not within the team but are caused by the servant leaders who support the team. In each of the scenarios below, the team is perfectly capable of developing and testing software that solves problems identified by the product owner. However, in each case the support system for the team is ineffective or doesn't accurately set priorities which has unintended impacts on the team.

Scenario A: We didn't finish stories during the sprints.

• Why: The testing is not complete by the end of the sprint
• Why: The testing did not start on time given the original estimate
• Why: The code was not available in the test environment with the proper data provisioned
• Why: The code was not checked in on time to meet the release cadence
• Why: The developer was waiting for a peer review, so she started something else new and forgot to check in the code

Root Causes:

• Distractions
• People not process
• Waiting for others
• Efficiency is being valued over effectiveness

Scenario B: We didn't finish stories during the sprints.

• Why: We had to wait for the product owner to answer several questions before we started.
• Why: We committed to stories where acceptance criteria were not detailed
• Why: Our team definition of ready is not strong enough or was ignored
• Why: The product owner said this had to be done now
• Why: Our product owner and leadership did not support the team definition of ready and asked for commitment anyway

Root Causes:

• Waiting for others
• Impediments are not recognized
• Culture of commitment from leadership is lacking

Scenario C: We didn't finish stories during the sprints

• Why: The integrated development environment was down for three days
• Why: A deployment broke the environment
• Why: Someone fat-fingered an entry during deployment
• Why: The deployment process is manual and complex, and the deployment was completed in a hurry to support a defect
• Why: Leadership has not allowed, or supported the time investment to automate repeatable high-risk processes

Root Causes:

• Waiting for others, available environments
• Working across priorities (Defects vs New Work)
• Leadership did not recognize the value of automation on a team's predictability

Using the "5 Whys" to move closer to root causes and key drivers of behaviors is a wonderful technique that can be applied to many situations. If you have a challenge that your team or organization is facing and want us to take a crack at different 5 whys, or if you have other scenarios that match the above, submit it here!