Why Won’t We Change?
Exploring Reluctance in Automation of Manual Development Practices
When building software for clients, a key driver is providing value and improvement to current manual user procedures. We should always look at ourselves in the same light. Without eliminating the manual processes in our own software engineering practice, how can we advocate the same lean focused benefits when automating client processes?
Maintaining manual elements of the software development cycle in fully remote situations such as the ongoing COVID-19 lockdown is rather difficult. Rather than trying to communicate more via informal channels to keep things going, teams resort to communicating less to “just get things done”.
Automated release and deployment mechanisms that could help reduce the amount of manual intervention are being ignored. Each dismissal often comes with mutters of “oh, I’ll do it next time”. Yet next time the recursive rejection cycle continues.
It is easy for the agent of change to become frustrated at the reluctance to change being exhibited by others. I imagine many of you are now reflecting on a time where you have faced hesitation for changes you are passionately advocating. With my most recent experiences in mind, I reflect on the reasons for automation hesitation.
The Certainty of Chance
Firstly, consider for how long these activities have been conducted in this way. How long have manual release procedures existed in your organisation in their current guise? 1 year? 2 years? Perhaps more than 5 years? Manual processes tend to hang around for a long time like a bad smell. New elements are bolted on over time. It’s rare steps are removed.
The longer things remain the way they are, the more difficult it becomes to change minds. Especially in times of strife. Even the most burdensome elements can be transformed over time into elements of comforting certainty.
Don’t confuse this comfort as acceptance in how things are done. Strangely enough, complaints on the degree of manual effort required have persisted for some time. Developers do raise concerns about the amount of time it takes to perform manual elements of our process such as release management, migration to testing environments and undertaking of manual testing. Nevertheless, when opportunities are presented to address these gripes we chicken out.
Tracking repeated rumbles is imperative to identify your complacent counterparts. Those are the individuals that will require support to adopt anything different. Just like all change and influencing forums tell us, it’s important to sell the change to them, including the cultural support, to encourage them to try using this new mechanism.
Feel the Pressure
Another cause of reluctance to automate our own processes is the degree of delivery pressure applied to teams. As process automation requires upfront effort, there can be a misconception that the automation takes longer than “just doing it”. Even with the best intentions and willing colleagues, they will take the easy way out and justify waiting until next time to take action.
If clients are continually yelling for new features to be delivered yesterday, the last thing developers want to focus on is automating procedures in their own back garden. There is a perception that, at least this time, it will take longer. If the team doesn’t see a potential future time saving, they won’t automate. Also, if they are pressed to get something out now, they will default to the old ways and still won’t automate.
We’ve all been guilty of thinking “it’ll take X to automate, I don’t think it’s worth it”. It’s not that they don’t want to be good scouts and leave the campground in a better state than it was found. It’s that they observe that users and Product Owners don’t appreciate the value or benefit. That the PO dictates all work that they complete.
I implore anyone who perceives that their Product Owner controls their sprint backlog to re-read the Scrum Guide very carefully. In particular, focus on the below two quotes:
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.
The Sprint Backlog is a forecast by the Development Team.
— The Scrum Guide, Jeff Sutherland and Ken Schwaber
To foster innovation and improvement, development teams need to feel empowered to control the sprint backlog and accept the work they undertake. It should be a conversation with the Product Owner to explain the value of process automation, along with the benefits they will see. Leaders need to protect teams from client pressure and ensure there is sufficient breathing space for teams to learn, grow and automate for their own collective benefit.
Learn to Fly
Think back a few years ago when you were just starting out at a portion of your educational or professional journey. Did you know absolutely everything you needed to complete work assignments? Of course not!
Fast forward to today and contemplate your current position. Do you always know the answer to everything? Is there never a situation where you need to search for an answer using your friendly neighbourhood search engine? I don’t believe I’m being presumptuous in assuming the answer is no for you as much as it is for me.
We may not be in education anymore, but we should be constantly learning. Lack of learning mindset is detrimental to any team. With technology frameworks, programming languages and paradigms continuously evolving, being a software engineer is a lifelong commitment to learning new and better practices. That includes learning how to automate your current processes. Especially those where established team members have a high degree of muscle memory.
Stronger
Of course a collaborative and continuous improvement culture across organisation should make change easier to apply. However, team cultural pockets also impact the willingness of squads to embrace change. Closed minds at both the individual and management levels can promote change resistance, even in the midst of top down transformations.
The reality is that unless all colleagues share the continuous improvement mindset and the desire to automate wasteful stages in their software development cycle, they will continue to follow the same repetitive manual procedures. Although we are privileged to have individuals willing to embrace change, that enthusiasm is not present across the entire collective.
I implore all teams in varying stages of DevOps adoption to consider any manual step in your process as waste to be eliminated. Don’t wait for that dreamy post-lockdown utopia to improve your own ecosystem. The benefits will still be there whatever that new normal is, and you will be a stronger team for undertaking the journey. So act now!
Thanks for reading! Claps, comments and shares are always appreciated.
