Using the 5 whys to find Change Management and DevOps impediments to Agile Transformation

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!