Increasingly, our clients are coming to us talking about introducing, or improving Agile work design, particularly in a virtual or matrixed environment. Many are concerned that their current business infrastructure and way of working lacks the ability to self-disrupt.
Self-disruption is a challenge because the barriers to entry across many industries are falling and new entrants are changing the rules. This means that instead of waiting for your industry to become a hunting ground for new start-ups, there is a requirement to focus externally at the customer experience of your product or service and internally at processes and ways of working to ensure the two together are best serving your customer. The challenge comes when the experience and resources are locked away by internal bureaucracy & siloed politics. The answer is some variant of Agile working.
Going Agile means different things to different companies, from using the strict The Agile Manifesto methodology in development projects through to, in some instances, simply implementing hot-desking. It is important to define what Agile is in your organization, but also important to clarify what Agile is not, so that a conversation can emerge about how best to implement the way of working you need. Agile is not just hot-desking or allowing employees to work from home once a week. We see Agile as an arm of Digital Transformation, it is about work design & new ways of working.
Note that structure does not form part of our definition. There are many structures which achieve the goal of Agile, whether that is Scrum, Holacracy, Start Up Way, Regenerative Organizations, Exponential Organizations etc. However, you will not self-disrupt by changing your formal structure. At the same time, we do not see Agile as necessitating a structural change. Companies have the capacity to challenge & change, whilst still operating in the virtual and matrixed reality which most large companies operate in.
Instead, the initial focus should always be around what is your goal and what is the capability of your people for change. ING are often used as a good example of how an Agile transformation can succeed having implemented a Spotify-esque self-managing structure. However, the management team at ING had already been through multiple change programs in the preceding years. This is not to minimise the value that Agile brought, merely to explain that the process for achieving a structural change was a challenge, even at a company adept at progressing through change.
But if you are looking to just test out Agile working, you can do it without having to overhaul your entire organizational structure. In Eric Reis’s The Startup Way, he highlights one of the most “cherished, universal beliefs” in the startup movement is that small teams beat big teams. Most Agile methodologies advocate a customer-led, cross-functional, small team as the mechanism by which work gets done. This is nothing new, however it is still incredible to see how many companies fail to adopt these practices. Since the work of Dunbar & Gladwell we have been told that around 6-9 people are the most that can truly cohesively work together interdependently on a single task. Beyond this, you end up with a looser coordinated group or a fragmented network. This is more of a way of working change, appreciating that smaller may be better, than a structural one, but ultimately requires experimentation and embracing Agile as a concept and set of practices.
We have discussed some specific examples of Agile throughout this blog, but they serve a wider purpose. Agile has the capability to make some positive changes to the way a company operates. For example, redesigning workstreams around a customer journey and continually experimenting makes for a cheaper and a less risky R&D function. But the company and team goal should always be front of mind. Structure will solve some problems, but the ways of working is often the wider issue. Only by “walking the talk” and trying some internal experiments yourself, will you find out how best to address your own challenges.
If you would like to discuss how to make a reality of agile working in your virtual & matrix world then reach out to firstname.lastname@example.org.