Scaled Agile - Difficult?

Last year I was given an opportunity to write a paper on how to design, lead and manage large organisational transformation in businesses of over 5000 personnel. I noted all of the elements every business has (Leadership Governance, Financial Discipline, Stakeholder Support, Strategy, Operations, Sustainable Funding and People) and how it could set the conditions whereby all elements were mutually dependent in order to create a high performing and resilient organisation.

Today I read a short paper written by Santiago Comella-Dorda, Swati Lohiya and Gerard Speksnijder all from McKinsey. It was titled ‘An Operating Model for Company Wide Agile Development’ and shared high level insights about how other companies are transitioning/transforming into an agile organisation. An interesting side note was how many of the points I wrote about last year resonated throughout it such as delegation of responsibility, improved decision making/time to decide a course of action, creating concurrent activity, business constraints to enable freedom of action etc etc.

However, I felt that McKinsey missed a trick. All of what was said, I feel, was straight forward, but it’s what’s omitted said that struck me the most. Throughout the paper they only spoke about how IT departments are transitioning from Waterfall to Agile and scaling this across the whole department (dept) from just individual teams. And this was odd…or in my opinion, short sighted.

Why would a company only look to making but one of its departments more effective and efficient? Surely the dichotomy of this is making the overall company output decrease? Here’s why.

You have 4 departments: Finance, Operations, IT and HR. The IT dept (addressed fully in the paper) are working in an agile environment; creating new products and releasing those products to customers in a more effective and rapid way. The Operations dept are okay as they, according to the paper, are now working with IT to create said products. But, the other business depts are still operating the ‘waterfall’ methodology.

This, therefore, means that the company as a whole are unable to realise the improvements that agile could give them. In fact, it would give the finance team such a backlog of work (due to the continual release of new products and subsequent updates to those products) that there would come a point by which the IT team would have to slow their output, or the finance dept would need to take on more staff. Or, and this is the sweet irony, become agile themselves in order to deal with the increased turnover/output.

My belief is that if the whole of business isn’t operating under the same model then no matter how good your new business methodology is, you’ll never realise its full potential.

The scalability of something like agile isn’t that hard. There may be gurus out there writing large tomes of work about how you can do it, and in doing so making it sound harder than brain surgery, but it’s not that tricky.

If, as a business, you want to change your culture or your operating system, get your people directly or indirectly involved in co-designing the future state and then get on with applying it. This will make them want to help achieve success as they feel as though they are part of its creation. Give the staff the requisite tools, training and support to achieve the aim and you’re off and running.

It all comes back to what I mention in my own paper; get the ‘Why’ and Values of your business right and everything else will falls easily into place.