I was recently involved in preparing for an enterprise agility engagement survey. Surveys of this kind are a great way to capture the pulse of the people working in the organization, and an opportunity to gather feedback from multiple perspectives. As a result of these new insights, we can adjust our focus for ongoing transformation and launch new improvement experiments.
In this survey, we mixed up response styles for our questions with simple yes and no, scaled and Net Promoter types. We also had a free text question. It was in these written comments from our survey responders that we found the real gold.
While scanning through the comments, my eye was drawn to one particular response. It really caught my imagination and for me was the standout comment from them all. It said …
“Agile adds too much overhead for the benefits received. If you can have communication and teamwork without Agile, then mission accomplished”
This is exactly the sort of comment I love to respond to. There are so many issues encapsulated in this simple statement. I was immediately desperate to engage in a conversation about the ‘whys’ and ‘whats’ surrounding this opinion.
Sadly I couldn’t do that. The survey was totally anonymous and I genuinely have no idea who wrote this comment. I’m sure that over time the organization will find a way to address some of these concerns. But it won’t be the same for me as a simple dialogue with the person whose comment has triggered my actions here. So I’m writing this response in the hope that whoever provided the feedback on the survey may find this article
Dear Anonymous, this one is for you.
Let’s straighten one thing up. I think we have mixed up Agile with agile framework here. It would not be the first time that has happened.
Agility in software development is about providing an environment that encourages satisfaction of customers through frequent and iterative delivery of value by self-organising groups of motivated people working collaboratively and sustainably.
There are many frameworks used to achieve agile goals. It is the working methodology of these frameworks that consumes some team capacity. That is the ‘overhead’. In many frameworks such as Scrum or SAFe, there is time set aside for planning, retrospectives and demonstrations of software to stakeholders. These events have some purpose. They are helping break down work into achievable parcels of near term value and generating learning to improve working practices and delivery flow. They connect developers and customers together, providing faster feedback which in turn promotes further value and avoids waste.
It is absolutely correct to call out communication and teamwork as important to the successful running of teams and delivery of software. But we should also ensure that communication and collaboration are wider and include all stakeholders responsible for delivering or receiving that value.
“Are the events we participate in … delivering justifiable or, indeed measurable value?”
The frameworks for agile software development call out time to make this happen. Other ways of working may not do so formally. I would argue that in successful outcomes we are very likely spending this same time. Where we are not spending this time, we are most often exchanging it for increased wastage.
The heart of this response is hugely valid and we should be debating it at every available opportunity. Is our chosen framework right for us? Are the events we participate in and spend our available capacity on delivering justifiable or, indeed, measurable value?
My favourite agile value is ‘maximise the work we don’t do’. In other words, we should continue to optimise our value deliveries in the leanest possible way. If ceremonies are not earning their keep, drop them. Don’t slavishly follow every tiny element of the framework, just because it has been written in to the description. Use only those things that you need. Continue to develop your own bespoke working practices best suited for your particular organization and team. As you journey, you will discover a hand-crafted set of methods that fit neatly for you and limit those overheads to essentials.
Please don’t throw out the baby of agility with the bathwater of wasted time spent on unnecessary meetings.
There is one last point to make here. Anonymity in surveys of this kind serves a purpose. We want to receive feedback that isn’t filtered by unwritten rules of acceptable behaviour; to get genuine thoughts and feelings from the participants. At the same time, however, we’re building another wall. One between our real selves. Wouldn’t it be so much more convenient if I knew who that responder was, but you still felt you could provide this feedback, safe in the knowledge that there would be is no negative impact? That you will receive the help you need without judgement? It would allow us to engage in immediate dialogue and work to resolve these issues much more directly. But for that, we need to trust each other more. And perhaps that is the biggest lesson to draw from this experience.
About the Author
Richard Williams is a fan of business adaptivity in all its many forms. He is a Visiting Fellow in the Industry Faculty at Kingston University Business School and an IC Agile authorised instructor in Leadership, People Development and Adaptive Organization Design. Richard has 25 years of experience working in delivery and product roles for a variety of FinTech and Financial Services companies. He is a transformation coach and SAFe Program Consultant.
