Agile: YES, We welcome change.. BUT.. how much change is too much change? Are we losing the sense of completion?

Let me start this text by saying that I am a true Agile enthusiast, I do believe that Agile mindset can change organizations to their core. With that being said, there is an aspect in Agile/ DevOps mindset, that always scared me is how much the frequent changes in the prioritization or business approach to an application or MVP impact the teams and their morale.

One of the four values in the Agile Manifesto is “ Responding to change rather than following a plan”. This value is a game changer and one of the fundamental differences between waterfall and Agile. This very sentence is for me the essence of Agile thinking, this very principle makes us to respond to market needs on time and stay close to the customer and their needs. This way we allow ourselves to fail fast and recover even faster and take smarter decisions and pivot when its necessary to drive our product success.

BUT, what happens when these changes happen too fast or too much? And can we say there is too much change?

In the IT industry, we would be crazy to expect some kind of stable and rigid plan that is going to stay unchanged for an x period of time. The nature of the work, the frequent user feedback that is bombarding us, the new and shinny technologies that we want to implement, certainly do not make these plans more stable and long term, rather the opposite. So, it would be unreasonable to even search or request this kind of stability from our Product Owners, Product Managers or the organization itself.
However, at some point we need to step back and see the effect of all of these changes in our teams, in our people.

Frequent and big changes have a great impact in the teams flow of work and subsequently their cycle time/ time to deliver, and if there is no clear prioritization then we fell deeper in a black hole of unfinished work, big WIP limits, and bottlenecks are bound to appear soon in our team. The work is starting but never gets done, because there is something else, something of a higher priority, there is always a “ We can finish that later….(but not that later)”. Result, yet another item in the In Progress column, or back to the backlog with the other “later” items.

The team get confused, loses focuses, the estimates for completing their job get bigger, the cycle time increases, the customer is waiting for the features, the client gets frustrated, and thus begins a vicious and never-ending cycle.

And… on that big list of things that the team started and never finished, people lose their sense of accomplishment, the sense of completion. This great satisfaction that you get when you put your sticky note in the Done column, when you cross over your “to-do” item from your list. This activity that produces the “happy” hormone in your brain, it doesn’t get triggered when you are working… Is that weird and a bit sad? Team spends their day or days in developing a product that doesn’t go across the finish line, that doesn’t get to succeed or fail, because no users used it. Of course, this is expected at some level, we are IT, but when it happens often enough, it can impact greatly the team and subsequently the products.

Its not only the change that makes teams lose their sense of completion, its also the extremely fast pace that we are delivering products, that doesn’t give the team time to celebrate their wins. The backlog is a living organism, it gets bigger, it gets reprioritized, it is never-ending. When the team finishes one thing, then comes another and another. Small, incremental, fast (how it is supposed to be), but too fast for the team to take pride in their work done.

So now what?
Do we go back to years of development, to waiting for the big release? Certainly not.

Can we avoid making changes? No.

Do we even want to stop changing? Of course NOT. Besides the only constant in life is change. We need change in order to progress, to move forward, so what do we do?

One of the fundamentals of change management is awareness. Teams need to know “Why?”, why there is a need for a change, acknowledging and understanding that , will make the transition smoother with and get the teams’ buy in. The team will feel they are part of it, and they will embrace it. Another aspect to consider is negotiation. POs/ SMs/ PMs need to make sure that there is an absolute need to make the pivot now, right this moment. It might be a better alternative to deliver/complete something that the team is working on, then move on to something new. Again, this negotiation might be fruitful and might not be, but at least, there was an effort put in to protect the teams work and get some value from the already work done. Last but certainly not least, take time to celebrate even the small wins in your teams, celebrate the small release, the one change and activate the “happy” hormone in your brain.