Unsurprisingly, the mainstream media have jumped on this to provide their views on the company’s restructuring approach, with some employment experts calling it a “recipe for disaster”.
It would be useful to separate Spark’s choice of Agile as a new way of working from other sort of issues like Spark’s right to change employment contracts with little consultation with his employees.
What is Agile? At its essence, Agile was born as an approach to software development by which small, self-managing teams deliver partial, but frequent, improvements to software as opposed to delivering one big, final development. It is based on the concept of incorporating ongoing user feedback on the small improvements to software.
Recently, the concept of Agile has expanded to other areas of the business like product and service development. Despite the many misconceptions around it, it is an approach to reduce uncertainty around customer requirements.
Customers generally cannot articulate what they want clearly, so giving customers a product prototype or sample to test is usually the best way to get accurate feedback. Agile is a customer-led approach where empowered teams learn from and adapt quickly to customer feedback.
Learning and adapting fast are key. Spark’s products and services are complex, features are initially unknown, and customer requirements will most likely change – that’s why Agile can help Spark.
Agile is useful if collaboration with customers is possible. It is usually said that the vast majority of the top 1000 American companies use Agile, in particular every technology and big Internet businesses do. So, it shouldn’t come as a surprise that Spark is also doing it.
This is a superficial way of looking at Agile. Agile is about a radically different way of thinking and leading. And here is where the problem lies. Agile is opposed to traditional planning and control.
Planning and control are anathema to organisational responsiveness and nimbleness, which Agile is based on. While organisations try to implement Agile principles, senior management and board still demand planning, command, control, and adherence to inflexible business plans. They apply traditional decision-making by demanding business plans and business cases for every project. As the saying goes “no business plan survives first contact with a customer”.
If we have learned anything from the innumerable business plans that have failed, such plans embed an enormous amount of uncertainty – they are only hypothesis, but treated as valid. Agile attempts to address this shortcoming.
But the question is whether Spark’s senior managers and board are ready to work in a different way. Has Spark focused only on pushing Agile to staff rather than looking at the overall company and how management and board make decisions in conditions of uncertainty? Does Spark’s senior management and board use Agile’s principles when making board-level decisions? Has Spark adopted Agile to the leadership context, and aligned management with staff?
Sceptics of Spark’s move will think of Agile as a business fad – and with reason. Another fad like management by objectives in the 1970s, total quality management in the 1980s, and business process re-engineering in the 1990s.
Although new techniques start very logically and rationally, they become fads when managers become disillusioned with the lack of results after introducing them into companies.
The real problem is not that such business ideas are inherently wrong, but that managers are unable to lead people through the period of transition toward the new way of working.
An often quoted estimate shows that over 75 percent of attempts to introduce new business practices fail simply because of lacking proper change management – another practice that managers have little idea how to execute.
Managers become excited with some new business idea that can help them succeed. But they implement it without an understanding of the people aspects of the change. Interestingly, Agile has many features of practices now regarded as fads, like empowerment, self-managed teams, learning organisations, quality circles, etc, which were introduced in businesses without any proper change management – and failed.
Does it make sense for Spark to implement Agile? Yes, it does, especially when compared with other business practices – Agile is the best we know for practicing product development.
But introducing Agile without a philosophical change at the managerial and board levels would result in another disappointment.
Introducing a new way of working by giving two in five employees five days to either sign a new contract or accept redundancy – no matter what preceded that – sounds distinctly un-Agile and makes me doubtful that it will produce fundamental change.
Ideally, Spark management would adopt Agile principles when dealing with its own workforce. Agile is about treating staff as customers by collaborating with them rather than intimidating them. Engaging with staff and bringing them alongside in the journey is the Agile way.
Unless this is happening, there is no evidence that Spark understands the new philosophy – until they do, they are just adopting a new slogan.
