Let’s look at the following scenario. You are a business or financial controller, in an organization that has adopted Agile principles and practices. Let’s assume there are obvious positive effects on product development and customer satisfaction. One thing bothers you, though…
Recent research in the Netherlands and Belgium shows that around 50 percent of managers feel like they are no longer, or less, ‘in control’ due to the organization’s becoming more Agile. They feel like they somewhat lost sight of project statuses and timelines, and thus of budgets and targets. These professionals are not dragging their feet, to be clear: they and their enterprise all support the Agile way of working. Their struggle lies with how to interpret their own role: how to still meet professional responsibilities, and how to secure and improve grip within the new(-ish) paradigm and its methods.
So, in short: how do you combine Agile principles and practices with your current role and responsibilities? Does it even still make sense to have someone on board that fills a controlling-role in the context of the Agile ways of working? (spoiler: yes, it does)
Recent sessions with financial controllers showed me…
If you download the white paper via the link below, you’ll read how this narrative continues: how the differences between Agile ways of working and the controller’s domain stem from different paradigms of trust, and an idea of how to mitigate those differences. How this plays out in practice is taught in the two-day course Agile for Finance and Control. By now we’ve given that course to around a hundred professionals in the finance and control function, coming in from banks, manufacturers and the transport industry.
And if there’s one thing I’ve learned from those professionals, it was how relieved they are that our course doesn’t ask them to work Agile, in order to have their work align better with the Agile ways of others. That’s right. You, as a controller, do not need to work Agile yourself in order to shape the control conditions for others to reliably do their work in. When our audience hears this, you can listen as the relief ripples through the room.
It’s only logical, though. The Agile ways to plan and deliver work were developed to recognize the inherent unpredictabilities of customer demand, technological advancement and development complexity. Yet the work of the financial controller suffers far less from such unknowables. Quite the opposite: where the work of the developer is to embrace change, the controller works to bring stability.
It’s in finding the intersection of these two seemingly opposed interests and capitalizing on that intersection that our course does its eye-opening work. Interested? Check out the white paper ‘Agile in Control’, and perhaps we’ll see each other at the related course ‘Agile for Finance and Control’ soon…!