If your Agile transformation has been a painful experience you are not alone. This seems to be very common. They say change is hard. I strongly believe that we’re making a HUGE mistake with the approach in implementing this type of change in our organizations and we are making it much more difficult than it needs to be. There is a better way and I believe I have discovered what it is. I am confident that if you take a different approach it will reduce the amount of difficulty your organization experiences trying to improve and you will yield much more effective outcomes.
But first, let’s understand what a lot of us experience.
Most of you use the same approach and have the same goals and then feel surprised and frustrated when the plan doesn’t yield the desired results
You realized at some point that you need to work with your teams to improve delivery so that it is more effective for your business and for your customers. In order to do this, most of you probably create a plan which includes teaching your team how to implement the trending industry best practices. You probably make sure to explain the end goal to improve time to market, increase quality, or improve overall effectiveness. Sounds pretty solid so far and everybody and their grandma is trying this to be more competitive in the market.
Then you try to implement it and everybody becomes frustrated and annoyed, resistance is high and morale takes a nose dive. The practices aren’t deriving the value you had hoped for and has caused more frustration than benefit. You keep pushing forward, but soon people start begging to return back to the old way of working because it was “better”.
If this sounds familiar there is a reason this happens and I’m about to tell you why. Read on, soldier.
Agile was created out of a burning desire to continuously improve but they go too far and tell us how to work instead of how to improve
There is one line in the agile manifesto that you should pay very close attention to. That line is that “We are uncovering better ways of developing software by doing it and helping others do it”. To me this translates to “We are uncovering better ways of working by learning as we work”. The Agile manifesto was created out of a desire to find new and improved ways of working.
The problem is that Agile frameworks and a lot of associated practices tell you a SPECIFIC way of achieving a desired outcome and that it is supposed to be better than your current way of working. They define HOW you should work instead of focusing only on WHAT outcome we should try to achieve and WHY. They lock us into an approach and so Agile frameworks and practices DO NOT actually help us learn how to uncover better ways of working. They tell you a specific way of working that we must follow. This makes it very difficult for you to learn what works best in your context.
For example, according to the Scrum guide, the team must only show done work in a sprint review. With refinement, the Agile industry practice is to use story points for sizing and so most teams use them, and also use stories. These are rules that define HOW the team should run based on industry best practice. They don’t consider the context of your environment or the challenges your team has currently. Applying these rules blindly and strictly will cause the negative result I described earlier; an extreme amount of frustration.
Teaching teams the rules actually sends a message that this is the way they must work and that you don’t want them to find better ways of working. Implementing Agile frameworks or best practices is contradictory to why Agile was created to begin with. So the first step to improving and trying to achieve those goals for your business and your customers is to actually stop making teams apply these frameworks and practices blindly. Instead teach your teams how to continuously improve and build a culture that encourages it. Easier said that done, and in a future blog post I will be explaining a few new techniques that I’ve discovered that can help you to achieve this.