The Source of Our Problems Are Not Always Where They Show Up

Many Agilists work on symptoms and not root causes. There are several ways to avoid this. The first is to understand First Principles and Mindsets/Values.

You must also find the source of the problem. It may be that the problem itself is not the source. See Using the Value Stream to Get to Root Cause With ‘Five-Whys’ 

It is also useful to mentally run through a checklist of common root causes. Here are a few of those:

1. violating universal principles such as overloading people with work
2. non-linear events that create waste but could have been caught with quick feedback
3. coupling of events that cascade
4. forcing people to figure things out themselves instead of teaching well-known practices / principles
5. the attitude that complexity means we can’t figure out what’s happening

Common challenges

There are a number of challenges. It’s worth considering these to see how we often put our attention on the wrong thing. Here are a few to consider:

• The challenge is not that we’re not done with our stories at the end of the sprint the challenge is that we’re putting too many stories into the sprint
• The challenge is not that we need longer sprints so we can finish the stories in the sprint the challenge is that we need shorter sprints so we can more accurately tell how many stories will fit into the sprint.
• The challenge is not that we close too many stories out at the end of the sprint the challenge is that we open too many stories at the start of the sprint.
• The challenge is not that we have siloes the challenge is that siloes aren’t working together.
• The challenge is not that people aren’t following the Scrum values the challenge is Scrum won’t work if people need to change their values before Scrum will work.
• The challenge is not that people won’t “just do Scrum” the challenge is that “just doing Scrum” is not what people should be doing
• The challenge isn’t that people “weren’t following Scrum” the challenge is expecting people to follow anything
• The challenge isn’t that you don’t have time to write tests the challenge is that if you don’t write the tests before you write the code you won’t know what the code is supposed to do until after you’ve written it.
• The challenge isn’t that product development is complex, the challenge is that people think they have to understand the complexity
• The challenge isn’t that too many principles are confusing, the challenge is fearing that too many rules are confusing results in presenting too few.