info@netfork.io

The Green STE B Dover, DE 19901, United States

Agile Coaching Scrum

What are “true impediments” and how to recognize them?

Agile Coaching Scrum

What are “true impediments” and how to recognize them?

1775x845_21

Do you feel like every sprint there is something that causes difficulties in your attempt to make a high-quality delivery? It can be something like sick leave, or plain lack of motivation of a single team member. It can also be something like “product owner does not understand that making changes to requirements constantly will cause us to be late with delivery”, or  “we did not estimate that feature well enough and I found that there is this big chunk of code I need to refactor before I move on with my feature implementation”. I heard these two more than once before in different teams.

In general according to Scrum.org, “an impediment in Scrum is a factor that blocks the Development Team in its creation of a valuable piece of software in a Sprint, or that restricts the team in achieving its intrinsic level of progress”. Sure, Scrum is a framework, and not a methodology, so it gives only a broad definition, but when it comes to the actual practice sometimes simply removing impediments is not good enough. It does not solve the problem long-term. Therefore we need to define the term “true impediment” and in my view, it should be a part of official guidelines in what Scrum Master duties are all about. 

Let’s see what a true impediment could be in the next example. Let’s say one of the team members did mention the famous impediment: “Product Owner keeps changing requirements and I am late with my feature because of that”. One way to solve this impediment is to immediately call a meeting and see how we can lock down requirements using the definite acceptance criteria (or decide to postpone the feature altogether and take something else to sprint instead). However this is only a surface-level insight, and proposed actions will take care of it only for current feature, or current sprint. In the next sprint, similar impediments will ricochet back to your table again. It is the only natural way of things.

Imagine a beautiful garden where big red roses represent harmonious relationships within the whole scrum team. There are also tulips that are a reflection of the team’s retrospectives and sprint reviews and orchids are sprint planning and refinements. The healthy and dense green carpet of grass represents a steady team’s growth and delivery. Now imagine a seed of poison ivy or another undesirable plant rooting within your garden. If you only cut the plant but leave the root, it will grow again and again and will start spreading. Other weeds will come as well. If none of the roots are pulled out your garden will keep struggling until eventually the weeds completely take over.

The weeds in this metaphor represent impediments and their roots are what we defined as true impediments. In my mind, a Scrum Master’s job is not much different than being a gardener, you need to continuously make sure your team grows in harmony. How do you get to the root level of impediments? One good technique to always have in your pocket is the 5-way technique.

To go back to the original story of PO who changes requirements, instead of jumping to solve the issue, you need to ask that powerful 1st “Why are requirements constantly changing?”. Most often than not developers will say something like: “how am I supposed to know, ask the PO”. 🙂 Here you can spot that you have more than one weed in your garden, the attitude weed, but let’s explore that topic on some different occasion. When you go into discussion with PO on the topic you might hear something like: “because there is active development on another part of the system not handled by our team that requires it to work like that”.

Your pursuit for true impediment has only started and it is time for the 2nd why: “Why is there a strong dependency between these two parts of systems?”. After you check the code and system design you find that it is because the part of the feature is actually intended to be sort of an authentication layer between systems. 

Now you guessed it, the 3rd why: “Why does system design advocate to introduce tight coupling between two parts of the system by putting an auth layer in one of them?”. You reach the system architect who wrote the design and you hear the following: “because of the pressure from the business the compromise was made to make a new auth layer and replace the old one that is a legacy but cannot handle the requirements of the most recent big customer the company has recently bid”. There was a huge timeline pressure for the whole product team to meet in order to win the deal.

The 4th why: “Why can’t we keep the system simple and make the original auth layer meet requirements”? After asking that question, the bitter answer quickly arrived: “because that part of the system is already 15+ years old, written in Haskell as a console application and are too afraid to even touch it in production”. Naturally, the 5th why: “Why are we afraid to make changes to that system?”. Instantly the answer: “because nobody today in the company knows anything about Haskell and there was never any documentation kept for that system”. Now you found the true answer that you needed in order to remove the true impediment your team is facing today. And the pressure will only be building up until the deadline.

Please take note of another important aspect of doing correctly the 5-why technique. It is the “why-because” chains, where every question needs to have an appropriate answer. What I mean by this is that drifting away from the main question is fairly easy and you need to be aware of this to stay on track. As an example, our 2nd why could have gone like this: “Why is there an active development in another system?”. Although chained to the answer of your first why you have moved your attention away from the actual problem and focused it into a more general topic of what the other team is working on or what the roadmap looks like for another system. You may expand your knowledge more about other parts of the system but could get limited insights that are very hard to act on.

Please take note of another important aspect of doing correctly the 5-why technique. It is the “why-because” chains, where every question needs to have an appropriate answer. What I mean by this is that drifting away from the main question is fairly easy and you need to be aware of this to stay on track. As an example, our 2nd why could have gone like this: “Why is there an active development in another system?”. Although chained to the answer of your first why you have moved your attention away from the actual problem and focused it into a more general topic of what the other team is working on or what the roadmap looks like for another system. You may expand your knowledge more about other parts of the system but could get limited insights that are very hard to act on.

The example in this article may be extreme, but it does show how deep the true impediment can be. In general, you should keep asking why questions until you are satisfied with the depth of the problem you have achieved. Sometimes it can happen only after 3 whys, but rarely (read never) it happens before that. The beautiful thing about reaching the correct depth is that solving a deeper problem may resolve 1 or more surface problems your team is facing from time to time. Fixing an impediment like this could lead to fewer requirements changes in the future and improve the stability of your applications which you could measure via a number of “weird legacy production bugs reported” per month. So your team may end up spending less time debugging and searching for ghosts in code and build new useful features instead.

The technique described above will not help you solve problems but will help you find the actual problem that needs solving. At this point, you can choose your course of action as your response to this deep-level insight you generated. You need to find what is the best solution long-term. Remember, you should be always interested only in the long-term solution as anything shorter than that might not be a solution at all, it could only be another procrastination (“let someone else deal with this problem”). You can coach your team on how to adopt this insight-generation technique. In the next post, we will go into the adaption strategies.

What are your thoughts on true impediments? How do you fight with impediments in your Scrum team? Let me know in the comments below.

Write A Comment