Scaling Agile & Change: Principles, not Frameworks
The secret to enterprise change – scaling agile, for instance – isn’t in a framework, a book, or an agile methodology. I spent the last decade investigating successful technology change across multiple efforts to modernise and introduce agile practices. We did formal research along the way and discovered that successful leaders in this area shared a set of internalised principles. These Principles helped them to introduce and navigate change while adhering to the strictest governance requirements. That’s to say, these principles allow one to be agile rather than worry about how to do agile. I’ve outlined the 5 Principles below along with a bit of context and things you can do to help your efforts along.
Agile & the weight of governance
I was lucky enough to work across many projects at a time that agile working practices were being introduced into the UK government over the past decade. Along the way, we ran formal research to understand critical success factors and barriers to change projects, both under the GDS governance structure and otherwise.
Tasked with understanding how and if the GDS technology governance process could be applied more broadly to technology change and smaller, internal processes, we concluded that it’s just not possible. The cost and complexity of such a bureaucracy isn’t feasible relative to an organisation that’s undergoing constant change. The governance structure was meant to prevent the largest of failures, but what of the death by a thousand paper cuts we have seen?
The question still needed answering. How can an organisation with the strictest of governance requirements extend agile working practices and reap its benefits at scale? Grand ideas of governance nirvana scrapped; we continued our enquiries.
We discovered in our research that many of the successful people we interviewed weren’t agile practitioners of any formal sort, but rather embodied a set of principles. These principles gave them some success and marked them as mavericks prior to the introduction of agile methodologies. They then thrived with better tools, support, and the methodologies.
We also found that the people at the acting director level are a key element to ensuring that agile principles are scaling. That’s because they’re both close to the reality on the ground and have the ability to marshall resources and react to day-to-day challenges and evolving information. They have the authority to slow things down when the organisation requires stability and move things forward when the opportunity comes.
When this only happens organically, an organisation is counting on getting lucky.
Hoping for luck that the right person is in the right place at the right time is the opposite of good governance.
Making it stick - more than surface change
Since then, I’ve had many conversations that keep bringing me back to these Principles. The topic of the conversions is the friction between internalised belief systems and change. In the worst cases the introduction of agile practices becomes the defining success parameter. People go to courses, project managers are renamed scrum masters, and so on. But management is largely left unchanged.
In government and very large enterprises where organisational memory is long, these failed efforts become a self-fulfilling cycle of failure and then apathy. As one research subject said to us upon reviewing a draft of the Principles:
Oh, great, another set of posters on the wall.
There was an apprehension that we were bringing another alien set of procedures with their alien nomenclature. The message we got was pretty clear: “We’ve seen this sort of thing before.” They weren’t kidding either. I often marvelled at these relics of past efforts that are to be found on government office walls exposed like a grand canyon of organisational process change.
The feedback we got on the Principles was pretty positive in the end. People liked that they weren’t overly-restrictive, and that they could focus on outcomes, try and develop their own ways of manifesting them. Unfortunately, the programme was swept away in the grand wave of Brexit budget reallocations. Still, the next steps from our research should also be considered, as they were another key finding.
We found that the principles were all well and good, but they needed to be contextualised and backed by hands-on examples of the sorts of things that needed to be done to achieve them.
So, while organisational memory can create difficulties in introducing change, it’s also a key component in maintaining. People need evidence that the thing they’re being taught works, in their context. Alien references in alien language are no substitute for guidance and working examples in the native tongue.
Doing this sort of thing takes time. Time to make the examples, to record them, to share them in a way that works. Funny enough, that’s one of the principles – not just doing the thing, but doing all the other things that the thing requires.
Principles for Agile Leadership
These principles should be considered for what they are. Useful if you’re trying to introduce large-scale technology, not words to live by. There’s only five of them, so hopefully easy to digest, and I’ve added commentary to flesh them out a bit in lieu of the required contextualisation.
More importantly, they can serve as a model for thinking about implementing change at more than a surface level. If you’re not finding them useful, then consider what sorts of principles you and your leadership applied when you were successful in the past. If you focus on how you’ve reacted when things were iffy, but then went right, it can make it easier to have discussions when things are going wrong in the future.
With that in mind, the first principle:
1. Start with people
Understand needs and problems from the perspective of those that use and also are most directly affected by change and technology. Face-to-face research & analysis, on an ongoing basis, will ensure those needs are met.
When dealing with internal technology projects, people can get lost in the mix. Technology projects span organisational boundaries, outlive people’s stay at the organisation, and take on a life of its own. When the tech stops filling a need, or organisational needs change, then the focus becomes the technology.
But, often, the people who use the tech have built up informal processes around it that go unaccounted for. Other times the informal processes solve a problem created by the technology itself, and the core problem doesn’t get addressed.
Deals for tech can be done between vendors and CIOs over lunches, focused on features and perceived savings. Worst of all, the people who are meant to use it, often internal to the organisation aren’t consulted. Organisations can barely be bothered to do user research for public-facing projects, let alone for internal projects.
Talk to the people that will use the tech. Not just the managers. That includes your staff, operations people, even contractors.
And then, keep doing it.
2. Deliver measurable change, not technology
Technology is only ever a means to an end. Ensure that your effort will provide clear benefits to your organisation by agreeing on the business and user needs that will be met. Diagnose the problem or need and identify the evidence that you need to collect so that you can measure and share your progress.
In many technology change efforts, success is defined as “doing the thing”. That is, the introduction of technology is often separated from adoption of its use, which can take time. People pat themselves on the back, get promoted and leave the hard work of fixing the mess to those that follow (often consultants).
In one enterprise procurement effort that we researched, we found that most users would never benefit from the most advanced features of a product. Their biggest concerns were an older, established feature and tech support.
We determined that the support process and costs would be untenable with one vendor. Not part of the main deal, it wouldn’t have been accounted for. Something that looked great on paper by features and numbers was a ticking time bomb that was avoided in this case.
We also recognised that people’s usage patterns were going to change. Probably around the time the contract renewals would come up. We could now track this and make an informed decision later.
Never let “doing the thing” be the measure of success. Focus on outcomes and increasing visibility of evidence. Then, don’t pat yourself on the back. Assume things will change and keep updating those measures.
3. Communicate & engage
Set up lines of communication with key stakeholders early to bring them along on the journey. Break barriers, but value relationships. Gain an understanding of the broader organisation and its relationship to what you’re doing so that you know who to involve, and when to involve them.
A common misconception about agile methodologies is that they’re disruptive. Many practitioners at the development level, especially in the early days, tended to be the sort of purists that were praised for “breaking barriers”
What our research found, however, was that those individuals were often, eventually, sidelined. With too much disruption these mavericks outlast their stay, and efforts try to continue without them. Separated from the context that came with those practitioners, however, their ideas sometimes died.
The more successful ones worked under the auspices of much more politically savvy lifers within organisations. This combination of maverick with politician-sponsor creates a super-team for change.
If there’s a lesson to be learned here it’s that organisations have a history, as do the decisions and motivations of those that made them. Often, it’s these underlying issues that must be addressed for agile practices to flourish. These pitfalls and levers can only be understood by individuals with organisational history in their armoury.
4. Uncertainty, in the right amounts
Skillful management isn’t about control, it’s the ability to use information to make decisions as things evolve. Increased information flow when things are uncertain is preferable to documentation, which is evidence of maturity. Constant agreement on outcomes reduces uncertainty, but uncertainty can never be eliminated.
Large organisations require the sort of certainty that year-on-year strategic planning brings. They think in three-and-five-year increments. How then, to be agile? How to translate the language of T-shirt sizing to that of corporate strategy?
The successful leaders that we interviewed and observed knew how to create a perimeter around the innovative work they were doing that protected it from the normal flow of work and information. They didn’t impose the rules, but they also didn’t break them. For instance, finding an ally in the security and IT spaces that could create safe and temporary spaces for experimentation.
For those trying to introduce agile working practices, it’s important to never lose sight of an organisation’s need for stability. You wouldn’t take a novice skier down a black diamond or even red or blue slope their first time out.
Take the time to understand an organisation’s risk tolerance, and make sure the information flow is set at the right level. Be moving toward something that looks like a formal process the organisation likes already.
5. Think beyond delivery
Delivery is successful only when a tool has been well-integrated into an organisation. Learning & development, operations, monitoring, analytics, data use, and disaster recovery should all be part of your plan from the beginning, not at the end.
The time between bringing in new tech and diffusing it across a large organisation can be long. The most static parts of an organisation are often the last ones to be brought along on a journey. This can be a vicious cycle – they’re the most reactive or resistant to change, so they get left to last. And so on.
Keeping in mind the above ‘communication’ principle, successful introduction of change means anticipating all the blockers and naysayers, the old-timers and cranky-pants. And then, rather than preparing for battle, it’s time for empathy. Thinking through all the non-technical aspects of technological change will make or break any effort.
That’s on the non-technical side. On the technical side, establishing success metrics from the start brings things forward that might get otherwise pushed to the end, like monitoring, alerting, and data use. If metrics are agreed, then you need a way to deliver them. Even incremental movement toward this goal is always valuable
Taking action
If you agree with the Principles and are living them, well, great. But principles can be easier to agree on than to act upon. In those times, they serve another purpose. As measures, they can help you to think about what’s getting in their way. The answer to the ‘why’ of this is often the real reason agile and other change efforts struggle.
Here’s what you can do to help others find their way to the Principles:
If you’re charged with leadership of an agile effort
When we aren’t living our principles, it’s useful to understand the competing interests and priorities that are getting in the way. As the agent of change, you may find frustration aimed in your direction, but often its source is the inability to do the thing that we know is right.
Time and economic pressures can cause short term thinking. Structural issues prevent the sort of cross organisational work that allows one to live principles.
If you can identify these barriers and quantify them as risks early on, then it’s easier to proceed with an agreement that we’re taking some risks. Sometimes the first step is bringing others along.
Externalising risks and watching them arise is, unfortunately, the only way some organisations learn and change.
If you’re leading an organisation
It’s useful to think about your leadership team at the director and acting-director levels. Evaluate their experience and actions to-date. What evidence exists that they’ll be able to act according to these (or your) Principles.
Many technologists and managers of technology, for instance, don’t have sufficient experience with research and product strategy to understand the first Principles. Others don’t have the experience with data to think about what makes for good measures and that going from none to some is a journey.
Supporting your leadership with direct training isn’t the only way to achieve this. Ensuring they have explicit support from other areas of the organisation or team members is another. They don’t have to get good at everything; but they must understand their needs and learn how to close the gap themselves.
Finally
Consider effective use of outside resources and consultants. Your organisation has to ensure that its learning, bringing skills in when it goes outside for support, and not becoming over-reliant. That’s when it becomes a cover for other, deeper issues.
Focusing on principles and people over technology is, coincidentally, the start of the agile manifesto. Ensuring that your people have what they need to make it scale, that’s good leadership.