Digital Leaders Embedding an Agile Mindset into Organisations: 10 Take-Aways
Date posted
8 June 2016
Reading time
12 Minutes
Digital Leaders Embedding an Agile Mindset into Organisations: 10 Take-Aways
As part of its mission to deliver world class digital services to government, Kainos gives special focus to the digital transformation of organisations to better prepare them to serve their users and deliver value faster. A key element of this is Agile transformation, and so we were pleased to host an event in partnership with Digital Leaders to address the topic of "How to Embed an Agile Mindset into Organisations".
The event was in a Salon format, kicked off by two speakers: Alison Webster, Head of Strategic Projects, and Norman Driskell, CDO at the Home Office.
Alison spoke first about work we had done with her organisation recently (a case study is available here), and Norman spoke about what he had learned from leading his own organisation's transformation.
Following this, the session opened up into a general discussion amongst all participants (from a good mixture of public, private and third sector), which was chaired marvellously by Gary Coyle.
The event was run under the Chatham House Rule, which gives me license to share some insights from the session, but not to attribute them in any way. Some of these insights may well resonate with you already, and some might be new.
1] It Takes Time
According to one attendee, GDS has suggested that it can take at least 18-24 months to embed agile into an organisation. Others around the table offered much longer timescales, which some citing timescales well in advance of several years.
The key takeaway is that it's difficult to quantify when you're done as it's not a binary "agile" vs "non-agile" state. Rather, it's a journey.
2] Mindset and Motivation is Key
There was broad agreement around the table that the key changes must be around an organisation's mindset to align with agile principles, rather than just implementing an agile process.
Mindset changes, include an appetite to experiment, to fail fast and safely, and to collaborate. Mindset changes need to be fostered by an environment that supports Autonomy, Mastery and Purpose.
Some participants noted that mindset changes are harder to implement in teams that are contractor heavy as their incentives are different to those of permanent staff.
3] Learn From Others
One participant reported finding great value in learning from other organisations to gain new insights into their own challenges. That same participant reported having learned a great deal by visiting several different organisations of varying sizes and stages of the transformation.
My own observation was that the group of people at Digital Leaders was learning a lot from the discussion, so a lesson I took away was that any opportunity to come together and candidly discuss issues of concern with others was a very useful thing.
4] Measurement is Important but be Careful with it
"What gets measured gets done", goes the saying. However, measures can have a distorting effect on the positive changes you want to see. Some measures, such as comparing velocity between teams, are meaningless and potentially dangerous.
One participant reported that their measures were intended to chart the progress of the agile adoption, and so found that coaching, and observing changes in behaviours aligned to agile principles was a good approach.
Ultimately, if you're leading change, it's incumbent on you to be very clear why you're embarking on this agile journey and what problems you're trying to solve. This leads on to...
5] Leadership From the Top is Crucial
It was very clear that strong leadership must be in place to complement any grass roots change. This leadership needs to make very clear "What" it wants to change and "Why" it is changing, and should leave the "How" up to the teams to decide.
Strong leadership creates an environment in which real change can grow, as well as support to unblock hindrances to changes in the organisation.
6] Be Wary of Agile Abuse
Some attendees noted that agile is often conflated with Digital, and this isn't helpful. Digital should just be seen as a way of solving problems, with agile as an approach to solving problems, and shouldn't be limited to Digital.
GDS, with its Digital Transformation agenda, has contributed massively to implementing change and showing the way through the exemplars - and now departments see themselves as being self-sufficient.
However, there can be a delayed reaction against change and often the terminology of agile can become objectionable to some. In government, Agile is in a war of methodologies - and the initially bullish stance of GDS has created some resistance. Attendees recognised that position was important if they were to start changing behaviours.
Agile adoption can be met with outright hostility, or simply misunderstanding. There was consensus around the table that you shouldn't let your teams "hide behind agile" as a reason not to do certain things, such as document, plan or meet objectives and commitments. Nor does agile adoption entail a relaxed attitude to risk - rather the reverse is true.
One strategy is to avoid terminology: talk about outcomes and principles. Avoid talking about Digital/ Agile.
7] Show the Thing
One of the mantras from GDS was the idea of "Showing the Thing", which refers to giving visibility of progress to stakeholders early and often.
There are good reasons for this approach, but it has been difficult for some stakeholders in government to accept an ostenisbly incomplete solution.
The group agreed that it's imperative to help stakeholders understand that they are looking at the kernel of a new service and are being asked for early feedback.
8] Products and Services/ Not Projects
Many attendees reported that they are moving away from or should move away from thinking in terms of projects with a finite end date.
Instead they are thinking of their teams as persistent, and working on products or services. Thinking in these terms supports continuous improvement of the service and the team delivering it.
9] Start Small, Then Grow
The Salon had consensus on the need to start an agile transformation at small scale, and to focus on starting and finishing one thing well. Proving and tuning your approach this way will support your attempts later to scale.
10] Optimise the Organisation - Never Stop
Beyond working at the grass roots and starting small, it's vital to consider an agile transformation as a holistic effort, which involves all levels of an organisation.
Consider your strategic planning cycles, prioritisation of work and the vision you have for improving the organisation as a whole. Whist all of these layers impact one another, they often run at different cadences, which must be planned for. Agile transformation is about minimising friction between these elements.
One attendee described running monthly "Organisational Sprints" to show that there is more to agile than software development: the whole organisation is transforming.
The challenge is to resist talk of target operating models, which imply a static end state; rather seek to create an organisation that is continuously adaptive.
Many thanks to all who attended and contributed to the Salon. I was delighted with the engagement from everyone, and pleased to see so much consensus. Now we just have to go out there and make it all happen!
Following this, the session opened up into a general discussion amongst all participants (from a good mixture of public, private and third sector), which was chaired marvellously by Gary Coyle.
The event was run under the Chatham House Rule, which gives me license to share some insights from the session, but not to attribute them in any way. Some of these insights may well resonate with you already, and some might be new.
1] It Takes Time
According to one attendee, GDS has suggested that it can take at least 18-24 months to embed agile into an organisation. Others around the table offered much longer timescales, which some citing timescales well in advance of several years.
The key takeaway is that it's difficult to quantify when you're done as it's not a binary "agile" vs "non-agile" state. Rather, it's a journey.
2] Mindset and Motivation is Key
There was broad agreement around the table that the key changes must be around an organisation's mindset to align with agile principles, rather than just implementing an agile process.
Mindset changes, include an appetite to experiment, to fail fast and safely, and to collaborate. Mindset changes need to be fostered by an environment that supports Autonomy, Mastery and Purpose.
Some participants noted that mindset changes are harder to implement in teams that are contractor heavy as their incentives are different to those of permanent staff.
3] Learn From Others
One participant reported finding great value in learning from other organisations to gain new insights into their own challenges. That same participant reported having learned a great deal by visiting several different organisations of varying sizes and stages of the transformation.
My own observation was that the group of people at Digital Leaders was learning a lot from the discussion, so a lesson I took away was that any opportunity to come together and candidly discuss issues of concern with others was a very useful thing.
4] Measurement is Important but be Careful with it
"What gets measured gets done", goes the saying. However, measures can have a distorting effect on the positive changes you want to see. Some measures, such as comparing velocity between teams, are meaningless and potentially dangerous.
One participant reported that their measures were intended to chart the progress of the agile adoption, and so found that coaching, and observing changes in behaviours aligned to agile principles was a good approach.
Ultimately, if you're leading change, it's incumbent on you to be very clear why you're embarking on this agile journey and what problems you're trying to solve. This leads on to...
5] Leadership From the Top is Crucial
It was very clear that strong leadership must be in place to complement any grass roots change. This leadership needs to make very clear "What" it wants to change and "Why" it is changing, and should leave the "How" up to the teams to decide.
Strong leadership creates an environment in which real change can grow, as well as support to unblock hindrances to changes in the organisation.
6] Be Wary of Agile Abuse
Some attendees noted that agile is often conflated with Digital, and this isn't helpful. Digital should just be seen as a way of solving problems, with agile as an approach to solving problems, and shouldn't be limited to Digital.
GDS, with its Digital Transformation agenda, has contributed massively to implementing change and showing the way through the exemplars - and now departments see themselves as being self-sufficient.
However, there can be a delayed reaction against change and often the terminology of agile can become objectionable to some. In government, Agile is in a war of methodologies - and the initially bullish stance of GDS has created some resistance. Attendees recognised that position was important if they were to start changing behaviours.
Agile adoption can be met with outright hostility, or simply misunderstanding. There was consensus around the table that you shouldn't let your teams "hide behind agile" as a reason not to do certain things, such as document, plan or meet objectives and commitments. Nor does agile adoption entail a relaxed attitude to risk - rather the reverse is true.
One strategy is to avoid terminology: talk about outcomes and principles. Avoid talking about Digital/ Agile.
7] Show the Thing
One of the mantras from GDS was the idea of "Showing the Thing", which refers to giving visibility of progress to stakeholders early and often.
There are good reasons for this approach, but it has been difficult for some stakeholders in government to accept an ostenisbly incomplete solution.
The group agreed that it's imperative to help stakeholders understand that they are looking at the kernel of a new service and are being asked for early feedback.
8] Products and Services/ Not Projects
Many attendees reported that they are moving away from or should move away from thinking in terms of projects with a finite end date.
Instead they are thinking of their teams as persistent, and working on products or services. Thinking in these terms supports continuous improvement of the service and the team delivering it.
9] Start Small, Then Grow
The Salon had consensus on the need to start an agile transformation at small scale, and to focus on starting and finishing one thing well. Proving and tuning your approach this way will support your attempts later to scale.
10] Optimise the Organisation - Never Stop
Beyond working at the grass roots and starting small, it's vital to consider an agile transformation as a holistic effort, which involves all levels of an organisation.
Consider your strategic planning cycles, prioritisation of work and the vision you have for improving the organisation as a whole. Whist all of these layers impact one another, they often run at different cadences, which must be planned for. Agile transformation is about minimising friction between these elements.
One attendee described running monthly "Organisational Sprints" to show that there is more to agile than software development: the whole organisation is transforming.
The challenge is to resist talk of target operating models, which imply a static end state; rather seek to create an organisation that is continuously adaptive.
Many thanks to all who attended and contributed to the Salon. I was delighted with the engagement from everyone, and pleased to see so much consensus. Now we just have to go out there and make it all happen!