×

Tag: transformation

The Disability Price Tag

How bad service design punishes those with a disability.

If you’ve never heard of the ‘Disability Price Tag’; the simplest way to describe it is that it’s the price you pay for costly mistakes due to symptoms of (or a byproduct of) your disability.

An image by the ADHD treatment centre describing the common issues that cause the 'ADHD tax'
The ADHD tax – as described by the ADHD Treatment Centre

People with ADHD are so often hit by the disability price tag; it’s been nicknamed the “ADHD Tax“, some obvious examples of this are parking and traffic tickets, late fees, high interest debt (i.e. credit cards), and low credit score (leading to higher interest debt, inability to get loans, problems renting apartments and buying cars, etc.) But this isn’t the only way people with disabilities are being hit financially.

Heating, insurance, equipment and care cost’s are all higher for people with Disabilities; and the Scope Extra Cost Commission in 2014 found that people with a Disability faced an extra £550 a month on their living expenses due to disability-related expenditure. In fact a study in 2015 by MacInnes, T., Tinson, A., Hughes, C., Born, T.B., Aldridge, H: Monitoring poverty and social exclusion found the poverty rate among people in families where someone has a disability is 8% higher than of those in families where no one is disabled.

For able-bodied and/or neurotypical folks, these can be really hard to comprehend; and even when they can comprehend the truth is, they have little sympathy for it.

But even if we acknowledge that people with Disabilities face the Disability Price Tag; there’s little recognition of the fact that bad service design can make these problems significantly worse for people with disabilities.

Many companies deliberately make it hard to cancel your subscription after a free trial period; or to register a complaint or appeal an unjustified fine; this is a fact everyone can easily recognise. What people fail to recognise if that this disproportionately affects people with disabilities, who are likely they to find it much harder to navigate these systems.

An image showing some complicated cancellation instructions
Complicated cancellation instructions

Let’s examine an example we’ve been dealing with recently; my family recently paid for parking in Manchester‘s Arndale shopping centre; where they’ve recently swapped their parking system to a new paperless (but still not digital) system.

The new system requires you to enter your Registration number on the machine and pay, but doesn’t issue you a ticket. There are a number of flaws in here that makes this utterly inaccessible and un-user friendly for people; so lets consider the issues this could cause:

  1. You have to guess how long you’ll need to park; if you need longer there is no easy way to top up your time without physically returning to the machine to extend it. Not very practical for those with a physical impairment, or who have caring responsibilities which would make nipping back to the car difficult.
  2. As users aren’t issued a ticket, and the machine doesn’t capture your mobile number or any way of issuing an e-ticket or reminder, users have to remember what time their ticket ends; this is not designed to support those with a cognitive disability which may make remembering information difficult.
  3. The system requires you to enter your registration number from memory; there are no reminders or prompts on the system; which features a normal alpha-numeric keyboard, relying on you to know your registration by heart; which means it can be very easy to enter your registration plate wrong. As the system doesn’t issue you a ticket/receipt; nor does it email you your ticket information, there is no way to check you entered the information correctly. This can easily trip up people with a learning difficulty like Dyslexia, or for those whom the English Alphabet is not their default.

My partner has Dyslexia and ASC and I have ADHD (always a winning combination when it comes to the Disability Price Tag). When we parked and went to purchase the ticket we managed to accidentally mix up the O for a 0; because we didn’t receive a copy of our ticket, we had no way of knowing we’d made this mistake, and simply assumed everything was fine. Upon returning to our car we spotted the fine sitting on the car window. We went to speak to the parking warden, who acknowledged we did indeed have a valid ticket on the system, but that the reg was technically wrong, and therefor we’d been fined. The warden acknowledged this was a very common issue that caught many people out; and recommended we appeal.

Appealing in and of its self is not an easy process; and what many able-bodied and neurotypical folks don’t understand is how much privilege it takes to appeal things; and how many spoons it can take to do so. Lets use our example of the the parking fine again:

  • The details of the fine and how to appeal it was only available on a piece of paper, and you have to wait unto 24hrs for the system to be updated before you can appeal (very easy to lose for those with ADHD etc.)
  • The print is extremely small (not good for those with a visual impairment and/or Dyslexia etc.);
  • and the reference number is not only small but also long and complex (very easy to get wrong for those with Visual Impairments or ADHD/ Dyslexia etc.)

Of course, to make matters more frustrating Manchester City Council then rejected the appeal, saying it’s the users responsibility to make sure they have bought their parking ticket correctly; which is a prime example of the higher price tag people with a Disability can face for doing that so many people would consider relatively simple.

So, how when we’re designing services can we do better? The answer is easy than you think; carry out research and test with users! User research and testing aren’t only applicable when we’re developing web services; they are equally important when developing and rolling out new systems in the physical world. Within Disabled service provision, this co-production of services is being seen as more and more important.

Co-Production is a term used to describe the partnership between people with disabilities or health conditions, carers and citizens and those who develop and run public services. While the upfront costs of co-production may seem higher; by designing services with users needs at the heart, we can significantly reduce the financial and emotional burden inaccessible services place on those with Disabilities; in turn improving their quality and way of life.

How do we make legacy transformation cool again?

Guest blog first published in #TechUk’s Public Sector week here on the 24th of June 2022.

Legacy Transformation is one of those phrases; you hear it and just… sigh. It conjures up images of creaking tech stacks and migration plans that are more complex and lasting longer than your last relationship.  

Within the Public Sector, over 45% of IT spend is on Legacy Tech. Departments have been trying to tackle legacy transformation for over 20+ years; but it remains the number one blocker to digital transformation.  

An image of some servers in black and white covered in wires.
Black and White servers

So why is it so hard and what can we do about it?   

The fundamental problem with Legacy transformation is that as an approach it’s outdated.  

The problem companies are trying to solve is that their technology systems need modernising or replacing; usually (at least in the public sector) these programmes come about because a contract is coming to an end and/or the platform the companies’ technology was built upon is effectively burning and can no longer be maintained.  

The problems with this approach are:  

  • That it so often ends in a big bang transition due to the desire to avoid hybrid running of services because of the complexity of migration 
  • The architecture of the new system is constrained by the need to remain consistent with the technical architecture used across the organisation,   
  • Transformation programmes can easily fall into the trap of delivering a ‘like for like’ solution that misses out on opportunities for innovation; this can be for many reasons, often as they have a cliff edge contract leaving them in a rush to find a replacement quickly,   
  • The programmes are developed in siloes, only considering the technical changes needed; but they don’t consider the wider business change needed to make transformation stick.  
  • The value is only delivered once the new service goes live and replaces the old system when it’s turned off.  This leaves many organisations needing to run both systems at once; but not wishing to due to the large cost implications.  

Due to these issues the big bang delivery often ends up being a lot later than planned; costing significantly more while neither meeting the users or business needs; and quickly becoming outdated.  

Don’t forget, the latest thing you’ve just updated will itself be considered Legacy in 5 years; so do we need to start thinking about legacy transformation differently? Is there an iterative approach to legacy transformation that works, and how should we approach it?  

Within Kainos we’ve worked hard to bring the User Centred design principles we’ve used to successfully deliver Digital Services to accomplish high impact legacy transformation programmes. By understanding user needs and business requirements we can plan early for ‘just enough’ legacy change to support the transformation; prioritising and identifying the value that can be added where and when; building scalable and extensible services that will maximise automation opportunities; carefully evaluating transition options and data migration dependencies so we can ensure we’re meeting user needs and adding value at each stage without risking business disruption.   

A whiteboard covered in post it notes and a user journey to demonstrate user centred design
User Centric Design

This incremental, user centred approach allows us to identify opportunities for innovation and truly enable digital transformation that focuses on the business benefits, reducing overall costs whilst realising value early and often.  

By thinking about business change and taking this iterative approach to realise value early and often we’ve been able to stop assuming that every element of the old legacy service needs throwing out and replacing; and instead, we’re identifying those elements that can be kept with just a bit of love and care to update them and make them work, and which elements we need to deliver something new. By prioritising where we focus our effort and making sure whether it is something old or something new, or a combination of the two, we can meet those critical user and business needs.  

Up-cycling doesn’t just work for vintage furniture and clothes after all, maybe it’s time we take that same mindset when we’re think about technical transformation; reinventing something old and making it into something better and new. After all tech changes faster than ever, so if we don’t change our mindset and approach, we will be left behind and quickly not just become out of fashion, we’ll be outdated.  

By adapting our approach to Legacy Transformation, Kainos are able to build excellent services that are secure and that users want to use; transforming business processes to fully embrace digital channels; microservices architecture that reduces future legacy risk; and costs that are optimised to benefit from public cloud platforms. 

Maximising the Lean Agility approach in the Public Sector

First published on the 26th June 2022 as part of #TechUk’s Public Sector week here ; co-authored by Matt Thomas.

We are living in a time of change, characterised by uncertainty. Adapting quickly has never been more important than today, and for organisations, this often means embracing and fully leveraging the potential of digital tools.

A lot has been said about Lean Agility but for an organisation in the Public Sector facing the prospect of a digital transformation, it is still difficult to understand what to do and how.

In our mind, while lean helps to solve the right problems, agility supports quick adaptability and the ability to change course whenever necessary.

A poster saying 'build, measure, learn" with an image of a pencil eraser removing the "L" or learn
Build, Measure, Learn

At Kainos working in the Digital Advisory team the one problem we hear about repeatedly from clients is the difficulties they face of delivering the right thing at pace, and how they struggle to maximise their efficiency. Some of the typical red flags we see when beginning to understand why clients are struggling to deliver effectively are:

  • evergreen delivery projects that never end; without an end product in sight or a product nobody uses constantly being tweaked; as opposed to teams delivering units of quantifiable value,  
  • lacking prioritisation; everything is a priority and so everything is in-flight at the same time,  
  • development is stalled or slow; with poor delivery confidence and large gaps between releases, 
  • traditional long-term funding cycles requiring a level of detail which doesn’t match near-term agile planning and responsive delivery, 
  • ineffective communication and lack of experienced deliver leadership; so decision making is made on gut feel and who shouts loudest rather than being firmly tied to desired business outcomes, 
  • Siloed pockets of various stages of Agile adoption /maturity and effectiveness making coordinated planning and collaboration difficult. 

Within Kainos our belief was that by introducing Lean-Agility Management we could scientifically remove waste & inefficiency whilst Increasing delivery confidence, employee job satisfaction and visibility of the work being undertaken. As such we. introduced a lightweight and straightforward Lean-Agility approach that could be adopted across multiple portfolios. 

Our approach does not just focus on Agile coaching (although that’s part of it) or other isolated elements of a transformation, but on 4 distinct pillars: Lean-Agility Management, Lean-Analytics & Dashboarding, Product & Design Coaching and Agile Coaching & Architecture.  This gives us the opportunity to build sustainability and in-house expertise to continue this journey. 

Recently we’ve been working with an integrated energy super-major to help them improve in several of these key areas.  We were asked to help, whilst contributing to the wider Agility transformation by bringing consistent high standards in delivery culture and ways of working through Lean and Agility. 

The results have delighted the client; we have managed to improve delivery speed by over 70%, delivery confidence by more than 50% and job satisfaction by over 20%.

This approach is one we’re using with several other clients in the commercial sector, all with similar positive effects; but it’s not something we encounter being used within the Public Sector much; either by us or by other consultancies.

How can this approach help the public sector and what is needed to make this a success?

From our experience, we have found the key elements to getting this right are:  

  • Starting with a Proof of Value (POV) – We tend to pick two volunteer squads to test with and prove this approach can work and add value.  
  • Senior Buy in and time – Agility transformation lives and dies by the clarity and direction of its leaders; teams need clear leadership, the support and empowerment to innovate and improve.  
  • Pod structure connects the transformation from exec to squads 
  • Multi-disciplined Agility team with knowledge of Product, Design and DevSecOps as well as Agility 
  • Desire to change culture – We don’t just mean continuous improvement, everybody does that, the difference is evolving to a resolute passion to rigorously improve everything 
  • Data at the core – clear metrics give teams a direction of travel and an idea of where targeted improvements could add real value   
  • Consider the people – We track job satisfaction because it’s important. Improvements come from your people. If you keep losing your people, you’re constantly going to be in a state of hiring and retraining, which is costly in terms of time and money. Happy people innovate and perform better.

Our Lean-Agility approach is very much an Agile approach to an Agile transformation, we start small prove the value, learn your business, customise and adapt. Lean-Agility is something we mould to you rather than a theory we try to plug and play, in that sense Lean-Agility for you will look and feel different to Lean-Agility for a different client and so it should! 

Becoming Product Led

Recently I was asked how I would go about moving an organisation to being Product Led; when agile and user centric design are equally new to the company, or when agile has not delivered in the way that was expected.

Before diving into the how, I think it’s worth first considering the what and they why.

What do we mean by being ‘product led’?

A product led approach is where your product experience is the central focus of your organisation. Within the public sector we incorporate user centric design into our products to ensure that we deliver real value by:š

  • Taking an outside-in perspective (starting with user needs)š;
  • Rapid, early validation of ideas (testing early and often); š
  • Maturing through iteration (based on user feedback)š and
  • Disciplined prioritisation (using quantitative and qualitative data) to deliver value.

Is this not just another name for agile?

This is a question that comes up regularly; and in my opinion, no it’s not. Agile is a delivery methodology; being product led is wider than that. it’s the wrapper that sits above and surrounds the delivery approach you use. It comes ‘before’ you decide on which delivery methodology you will use; and continues long after. It’s your culture and ways of working. The two can often go hand in hand; but if agile is the how, product is the what and the why.

Why is being product led important?

šWell, by moving to a product led approach we allow the organisation to link their outputs to their customer needs and ensuring they align to their organisational capabilities and strategy. šIt also allows organisations to focus on their customers needs and understand their users perspectivesš. By understanding and focusing on user needs it allows organisations to deliver value faster, making it quicker and easier for organisations to learn from what has gone well (and what hasn’t)š which in turn makes cheaper and faster to address any issues or risksš. It also makes it easier for organisations to spot opportunities for innovation and growth.

How do you move your organisation to being product led?

First things first, a culture that empowers the asking of questions and testing of hypothesis is essential for innovation. But to allow that to happen, organisations need senior leaders who understand and support their teams to work in this way. The appropriate ,light weight/ adaptable, governance and funding approvals processes being in place are critical to enable product innovation and empower delivery teams.

The second element that’s key is having the right data. Good product orientation depends on having access to quality data; what are our current metrics? Where are our current pain points? Do we understand our current costs? What products/ services have the highest demand? etc. This data enables us to make quality decisions and measure our progress our successes.

Thirdly, we need to have clearly articulated strategy/vision for the organisation; what is our USP (Unique Selling Proposition)? What do we want to achieve? What are our goals? What value are we looking to add? What do we want to be different in 5/10 years from now?

To develop that strategy/vision, we need to have a clear understanding about our users and stakeholders. Who are we developing these products for? Who are our stakeholders? How are we engaging with them? What do they need from us?

Finally, once we’ve got the strategy, the vision, an understanding of our user needs and a set of hypothesis we want to test; we need a healthy delivery approach, with skilled teams in place to enable us to test our ideas and deliver that value. As we’ve said previously, to be product centric we need to be able to design services that are based on user needs, so that we can test regularly with our users to ensure we understand, and are meeting, those needs.

What are the sign of a good product led culture?

  • You are regularly engaging with the users; working to understand their needs and iterating your approach and services based on their feedback.
  • Your culture empowers and encourages people to ask questions. “Why are we doing this?”; “Who are we doing this for”, “Is anyone else already doing this?”, “What will happen if we don’t do this {now)?”, “What have we learnt from our previous failures/successes?”
  • Your teams are working collaboratively, policy and operations teams working hand in hand with tech/digital teams; to ensure you’re delivering value.
  • You’re considering and testing multiple options at each stage; looking for innovative solutions, and working to understand which options will best meet your users needs and add the most value.
  • Linked to the above; You’re testing regularly, being willing to ‘throw away’ what doesn’t work and refine your ideas based on what does work.
  • You’re delivering value early and often.
Prioritising the backlog

Which comes first, the Product Manager, or the product culture?

If you don’t have any trained product people, can you begin to move to a product led culture, or must you hire the product people first? This is the chicken and the egg question. For many organisations, especially those already using agile delivery methodologies or engaged in digital transformation; they may have already sunk a lot of time and money into delivery, and pausing their work whilst they change their culture and hire a load of skilled product folk just isn’t going to work; but, you can begin to move towards a product led approach without hiring a load of Product Managers. Whilst having experience product folk can definitely help, you probably have lots of folks in the organisation who are already over half way there and just need some help on that road.

One stumbling block many organisations fall over on their move to a product led approach is the difference between focusing on outcomes, rather than outputs or features.

An output is a product or service that you create; an outcome is the problem that you solve with that product. A feature is something a product or service does, whereas a benefit is what customers actually need. If we go straight to developing features, we could be making decisions based on untested assumptions. 

There are 5 steps to ensure you’re delivering outcomes that add value and deliver benefits vs. focusing on features that simply deliver an output:š

  • State the Problemš – what are we trying to solve/change?
  • Gather User Data – have we understood the problem correctly?
  • Set Concrete Goals and Define Success Criteria – what would success look like? š
  • Develop Hypothesis – how could we best solve this problem? š
  • Test Multiple Ideas – does this actually solve the problem?

When you’re trying to identify the right problem to fix, look at existing data from previous field studiescompetitive analysisanalytics, and feedback from customer support. Use a mix of quantitative and qualitative data to ensure you have understood your user needs, and their behaviours.  Then analyse the information, spot any gaps, and perform any additional research required to help you verify the hypothesis you have developed when trying to decide how you could solve the problem your users are facing.

They key element to being product led is understanding the problem you are trying to fix and focusing on the value you will deliver for your users by fixing it. It’s about not making assumptions you know what your users want, but by engaging with your users to understand what they need. It’s about spotting gaps and opportunities to innovate and add value, rather than simply building from or replacing what already exists. It’s about focusing on delivering that value early and often.

Digital Transformation is still new

We’re punishing those who are less experienced, and we need to stop.

The timeline of Digital Transformation. Courtesy of Rachelle @ https://www.strangedigital.org/

In the last few weeks I’ve had multiple conversations with clients (both existing and new) who are preparing for or have recently not passed their Digital Service standard assessments who are really struggling to understand what is needed from them in order to pass their assessment.

These teams have tried to engage with the service standards teams, but given those teams are extremely busy; most teams cant get any time with their ‘link’ person until 6 weeks before their assessment; by which time most teams are quite far down their track and potentially leaves them a lot of (re)work to try and do before their assessment.

Having sat in on a few of those calls recently I’ve been surprised how little time is set aside to help the teams prep; and to give them advice on guidance on what to expect at an assessment if they haven’t been through one before. Thos no time or support for mock assessments for new teams. There may be the offer of one or two of the team getting to observe someone else’s assessment if the stars align to allow this; but it’s not proactively planned in; and instead viewed as a nice to have. There seems to be an assumption the project teams should know all of this already; and no recognition that a large number of teams don’t; this is still all new to them.

“In the old days” we as assessors and transformation leads used to set aside time regularly to meet with teams; talk through the problems they were trying to fix, understand any issues they may be facing, provide clarity and guidance before the assessment; so that teams could be confident they were ready to move onto the next phase before their assessment. But when I talk to teams now, so few of them are getting this support. Many teams reach out because the rare bits of guidance they have received hasn’t been clear, and in some cases it’s been contradictory and they don’t know who to talk too to get that clarity.

Instead, more and more of my time at the moment, as a supplier, is being set aside to support teams through their assessment. To provide advice and guidance on what to expect, how to prepare and what approach the team needs to take. Actually what an MVP is; how to decide when you need an assessment, and what elements of the service do you need to have ready to ‘show’ at each stage. What the difference is between Alpha/ Beta and Live assessments and why it matters. For so many teams this is still almost like a foreign language and new.

So, how can we better support teams through this journey?

Stop treating it like this is all old hat and that everyone should know everything about it already.

Digital Transformation has been ‘a thing’ for one generation (if you count from the invention of the internet as a tool for the masses in 1995); Within the public sector, GDS, the Digital Service Standards and the Digital Academy have existed for less than one generation; less than 10 years in-fact.

By treating it as a thing everyone should know, we make it exclusionary. We make people feel less than us for the simple act of not having the same experience we do.

We talk about working in the open, and many team do still strive to do that; but digital transformation is still almost seen as a magical art by many; and how to pass what should be a simple thing like a service standard assessment is still almost viewed as Arcane knowledge held by the few. As a community we need to get better at supporting each other, and especially those new to this experience, along this path.

This isn’t just a nice thing to do, its the fiscally responsible thing to do; by assuming teams already have all this knowledge we’re just increasing the likelihood they will fail, and that comes with a cost.

We need to set aside more time to help and guide each other on this journey; so that we can all succeed; that is how we truly add value, and ensure that Digital Transformation delivers and is around to stay for generations to come.

Talking Digital Transformation

It’s something that has come up a lot in conversations at the moment, what is Digital Transformation? What does Digital Transformation mean to me? I always joke that it’s my TED talk subject, if I had one; as such I thought why not write a blog about it?

What is Digital Transformation?

According to Wikipedia, Digital Transformation “is the adoption of digital technology to transform services or businesses, through replacing non-digital or manual processes with digital processes or replacing older digital technology with newer digital technology.

The Wikipedia definition focuses on 3 of the main areas of Digital Transformation; technology, data, process; which are the areas most people quote when but doesn’t reference organisational change; which is often recognised as the 4th pillar needed for successful transformation.

If we’re being specific, then I agree with the Wikipedia definition at the project or service level, but when someone says Digital Transformation to me; I automatically start thinking about what that means at the organisational level, before moving onto the other areas.

I’ve done plenty of blogs previously on the importance of considering your organisational culture when trying to implement change; and how likely it is that your transformation will fail if you don’t consider your culture as part of it; but that as we see from the Wikipedia Definition; the people side of Digital Transformation is often forgotten.

There’s a good blog here that defines the 4 main challenges organisations face when looking to implement Digital Transformation, which it defines as:

  • Culture.
  • Digital Strategy and Vision.
  • IT infrastructure and digital expertise.
  • Organisational Structure.

Here, we see Culture is the first/largest challenge mainly organisations face; which is why it’s important is’t not treated as an afterthought. Why is that? Is our methodology wrong?

So how do we go about delivering Digital Transformation?

The Enterprise project has a good article here on what it views as the 3 important approaches leaders should take when implementing Digital Transformation.

  • Solve the biggest problem first.
  • Collaborate to gain influence.
  • Keep up with information flows.

There’s (hopefully) nothing revolutionary here; this is (in my opinion) common sense in terms of approach. But so often, when we start talking about Digital Transformation, we can quickly fall into the trap about talking about frameworks and methodology; rather than the how and why of our approach to solving problems. So, are there any particular frameworks we should be using? Does the right framework guarantee success?

There are lots of different frameworks out there; and I can’t document them all; but below are some examples…

This article sums up what it deems as the top 5 Digital Transformation frameworks, which are the big ones; including MIT; DXC; CapGemini; McKinsey; Gartner; Cognizant and PWC. It’s a good summary and I won’t repeat what it says about each, but it looks at them in the following terms that I think are key for successful Digital transformation:

  • customer-centricity
  • opportunity and constraints
  • company culture
  • simplicity

There are obviously a few others out there; and I thought I’d mention a couple:

The first one is this AIMultiple; this one interestingly has culture as the final step; which for me makes it feel like you are ‘doing transformation to the teams rather than engaging teams and bringing them into the transformation; which doesn’t work well for me.

AIMultiple Digital Transformation Framework
https://research.aimultiple.com/what-is-digital-transformation/#what-is-a-digital-transformation-framework

This second one; from ionology, has Digital Culture and Strategy as its first building block; with user engagement as its second building with equal waiting to Processes, Technology and Data. It recognises that all of these elements together are needed to deliver Digital Transformation successfully. This one feels much more user centric to me.

https://www.ionology.com/wp-new/wp-content/uploads/2020/03/Digital-Transformation-Blocks-Equation.jpg

So where do you start?

Each of these frameworks has key elements they consider, in a particular order that they feel works best. But before panicking about which (if any) framework you need to pick; it’s worth remembering that no single framework will work for every business and any business will need to tailor a framework to fit their specific needs. 

How you plan to approach your transformation is more important than the framework you pick. Which is why the Enterprise article above about good leadership for me is spot on. We should always be asking:

  • What is the problem you’re trying to solve within your organisation by transforming it, and why?
  • Who do you need to engage and collaborate with to enable successful transformation?
  • What is the data you need to understand how best to transform your organisation?

Once you know what you’re trying to achieve and why, you can understand the options open to you; you can then start looking at how you can transform your processes, technology, data and organisational structure; at which point you can then define your strategy and roadmap to deliver. All of the above should be developed in conjunction with your teams and stakeholders so that they are engaged with the changes that are/will be happening.

Any framework you pick should be flexible enough to work with you to support you and your organisation; they are a tool to enable successful Digital Transformation; not the answer to what is Digital Transformation.

So, for me; what does Digital Transformation mean?

As the Enterprise Project states; Digital transformation “is the integration of digital technology into all areas of a business, fundamentally changing how you operate and deliver value to customers. It’s also a cultural change that requires organisations to continually challenge the status quo, experiment, and get comfortable with failure.” Which I wholeheartedly agree with.

Agile at scale

What do we even mean when we talk about agile at scale and what are the most important elements to consider when trying to run agile at scale?

This is definitely one of those topics of conversation that goes around and around and never seems to get resolved or go away. What do we even mean when we talk about agile at scale? Do we mean scaling agile within a programme setting across multiple teams? Do we mean scaling it across multiple programmes? Or do we mean scaling it using it at scale within a whole organisation?

When ever I’m asked about what I believe to be the most important elements in enabling successful delivery using agile, or using agile at scale, the number one thing I will always talk about isn’t the technology; It isn’t digital capability; or experience with the latest agile ways of working (although all those things are important and do obviously help) it’s the culture.

I’ve blogged before on how to change a culture and why it’s important to remember cultural change alongside business transformation; but more and more, especially when we’re talking about agile at scale I’ve come to the conclusion that the culture of an organisation; and most especially the buy in and support for agile ways of working at a leadership level within an organisation, is the must fundamental element of being able to successfully scale agile.

Agile its self is sadly still one of those terms that is actually very marmite for some, especially in the senior leadership layers. They’ve seen agile projects fail; it seems like too much change for too little return, or its just something their digital/tech teams ‘do’ that they don’t feel the need to really engage with. GDS tells them they have to use it, so they do.

Which is where I think many of the agile at scale conversations stumble; it’s seen as a digital/tech problem, not an organisational one. This means that time and again, Service Owners, Programme Directors and agile delivery teams get stuck when trying to develop and get support for business cases that are trying to deliver holistic and meaningful change. We see it again and again. Agile delivery runs into waterfall funding and governance and gets stuck.

As a Service Owner or Programme Director trying to deliver a holistic service, how do you quantify in your business case the value this service and this approach to delivery will add? The obvious answer, hopefully, is using data and evidence to show the potential areas for investment and value it would add to both users and the business. But how do you get that data? Where from? How do you get senior leaders to understand it?

In organisations where agile at scale is a new concept, supporting senior leaders to understand why this matters isn’t easy. I often try and recommend new CDO’s, CEO’s or Chief Execs ‘buddy up’ or shadow some other senior folks who have been through this journey; folks like Darren Curry, Janet Hughes, Tom Read and Neil Couling; who understand why it matters, and have been through (or are going through) this journey themselves in their organisations and are able to share their experiences for both good and bad.

I will always give full praise to Alan Eccles CBE who was previously The Public Guardian, and chief exec of the Office of the Public Guardian, with out whom the first Digital Exemplar, the LPA online, would never have gone live. Alan was always very honest that he wasn’t experienced or knowledgeable about agile or digital, but he was fully committed to making the OPG the first true Digital exemplar Agency; and utilising everything digital, and agile ways of working, had to offer to transform the culture of the OPG and the services they delivered. If you want an example of what a true Digital culture looks like, and how vocal and committed Alan was to making the OPG digital, just take a look at their blog which goes all the way back to 2015 and maps the OPG’s digital journey.

Obviously, culture isn’t the only important factor when wanting to scale agile; the technology we use, the infrastructure and architecture we design and have in place, the skills of our people, the size of our teams and their capacity to deliver are also all important. But without the culture that encompasses and supports the teams, the ability to deliver at scale will always be a struggle.

The commitment to change, to embracing the possibilities and options that a digital culture and using agile at scale brings at the senior leadership level permeates through the rest of the organisation. It encourages teams to work in the open, fostering collaboration, identifying common components and dependancies. It acknowledges that failure is ok, as long as we’re sharing the lessons we’ve learned and are constantly improving. It supports true multidisciplinary working and enables holistic service design by encouraging policy, operations and finance colleagues etc to be part of the delivery teams. All of this in turn improves decision making and increases the speed and success of transformation programmes. Ultimately it empowers teams to work together to deliver; and that is how we scale agile.

How to change a culture

When delivering digital or business transformation, one of the things that often gets overlooked is the cultural changes that are needed to embed the transformation succesfully.

There can be many reasons why this happens, either because it’s not been considered, because it’s not been considered a priority, or simply because the people leading the transformation work don’t know how to do this.

In my experience the culture of an organisation can be the thing that makes or breaks a successful transformation programme or change initiative; if the culture doesn’t match or support the changes you are trying to make, then it’s unlikely that those changes will stick.

Below are some common causes of failure in my experience:

  • The scope of transformation programmes have been considered and set in silos without considering how they fit within the wider strategy.
  • Decisions have been made at ‘the top’ and time hasn’t been spent getting staff engagement, feelings and feedback to ensure they understand why changes are being made.
  • Decisions have been made to change processes without validating why the existing processes exist or how the changes will impact people or processes.
  • Changes have been introduced without ensuring the organisation has the capability or capacity to cope.
  • Lack of empowerment to the transformation teams to make decisions.
  • When introducing agile or digital ways of working, corresponding changes to finance/ governance/ commercials haven’t been considered; increasing siloed working and inconsistencies.

Walk the talk:

Within Difrent we use tools like the Rich Picture and Wardley mapping to help Senior Leaders to understand their strategic priorities and clearly define the vision and strategy in a transparent and visual way. These help them be able to agree the strategy and be able to ‘sell it’ to the wider organisation and teams in order to get engagement and understanding from everyone.

The Rich picture Difrent developed for the NHSBSA
The NHSBSA rich picture

In my experience this works especially well when the assumptions made by the SLT in the strategy and vision are tested with staff and teams before final version are agreed; helping people understand why changes are being made and how they and their role fit into the picture.

This is especially important when it comes to the next step, which is developing things like your transformation roadmap and target operating model. These things can not be developed in isolation if you want your transformation to succeed.

People always have different views when it comes to priorities, and ways to solve problems. It is vitally important to engage people when setting priorities for work, so they understand why changes to a data warehouse or telephony service are being prioritised before the new email service or website they feel they have been waiting months for. Feedback is key to getting buy in.

A whiteboard with the word 'feedback' written in the middle with written notes around it
‘Feedback’

Equally assumptions are often made at the top level about something being a priority based on process issues etc. Without understanding why those processes existed in the first place, which can miss the complexity or impact of any potential changes. This then means that after changes have been delivered, people find the transformation hasn’t delivered what they needed, and workarounds and old ways of working return.

One thing I hear often within organisations is they want ‘an open and transparent culture’ but they don’t embody those principles when setting strategic or transformation priorities; as such people struggle to buy into the new culture as they don’t understand or agree with how decisions have been made.

Think wider:

While people are the most important thing when thinking about transformation and business change, and changing a culture; they are not the only thing we have to consider. The next step is processes.

Whatever has inspired an organisation to transform, transformation can not be delivered within a silo; it is important to consider what changes may need to be made to things like finances; commercials and governance.

While these aren’t always obvious things to consider when delivered digital transformation as an example, they are vitally important in ensuring its success. One thing many organisations have found when changing their culture and introducing things like agile ways of working, is that traditional governance and funding processes don’t easily support empowered teams or iterative working.

As such, it’s vitally important if you want transformation to succeed to not get trapped in siloed thinking, but instead take a holistic service approach to change; ensuring you understand the end to end implications to the changes you are looking to make.

Taking a leap:

Equally, when making changes to governance or culture, one thing I have found in my experience is that senior leaders; while they want to empower teams and bring in new ways of working, they then struggle with how to ‘trust’ teams. Often as Senior Responsible Owners etc. they don’t want to be seen to be wasting money. As such they can enter a loop of needing changes ‘proving’ before they can fully embrace them, but by not being able to fully embrace the changes they aren’t demonstrating the culture they want and teams then struggle themselves to embrace the changes, meaning the real value of the transformation is never realised.

A woman standing in front of a project wall
A project board full of post it notes

There is no easy answer to this, sometimes you just have to take that leap and trust your teams. If you have invested in building capability (be that through training or recruitment of external experts) then you have to trust them to know what they are doing. Not easy when talking about multi-million pound delivery programmes, but this is where having an iterative approach really can help. By introducing small changes to begin with, this can help build the ‘proof’ needed to be able to invest in bigger changes.

There is no one ‘thing’

When delivering transformation, and especially when trying to change culture, there is no quick answer, or no one single thing you can do to guarantee success. But by considering the changes you will be making holistically, getting input and feedback from staff and stakeholders, engaging them in the process and challenging yourselves to demonstrate the cultural changes you want to see, it is much more likely the transformation you are trying to deliver will succeed.

The word 'change'
Change.

What even is agile anyway?

So you’re a leader in your organisation and Agile is ‘the thing’ that everyone is talking about. Your organisation has possible trialed one or two Agile projects within the Digital or Tech department, but they haven’t really delivered like you thought they would, and you think you can ‘do more’ with it, but honestly, what even is it in the first place?

It’s a question that comes up fairly regularly, and if you are asking it, you are not alone! This blog actually started from such a conversation last week.

Tweet https://twitter.com/NeilTamplin/status/1220608708452999170

First and foremost there is Agile with a capital A, this is the project methodology, predominantly designed for software development, as defined here. It “denotes a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”

However nowadays, especially in the public sector, agile doesn’t only apply to software. More and more of the conversations happening in communities like #OneTeamGov are about the culture of agility. How you create the environment for Agile to succeed, and this is where many people, especially leaders, are getting lost.

So how do you ‘be agile?’

Being agile is borrowing the concepts used in agile development, to develop that culture. As Tom Loosemore says when talking about Digital, it’s about “applying the culture, processes, business models & technologies of the internet-era to respond to people’s raised expectations.”

But it’s more than what you transform, it’s how you do it.

The Agile manifesto says that Agile is about:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

When you consider individuals and interactions over processes and tools, then you remove unnecessary hierarchy and empower people to make decisions. You don’t enforce rigid processes for the sake of it, but iterate your governance based on feedback of users (in this instance your staff!). By being agile you focus on communicating directly with human beings, looking to how you can accommodate more actual conversations, and time together, rather than relaying on emails and papers as your only way to communicate.

By prioritising working software over comprehensive documentation you are constantly testing and iterating what works based on what is meeting your user needs, rather than deciding upfront what the answer is before knowing if it will actually work. You involve user research in your policy and strategy discussions. You analyse and test your new processes before you implement them. You change your funding and governance models to allow more innovation and exploration, and base your decisions on data and evidence, not theory. By being agile you are able to demonstrate working product or tangible services to stakeholders and customers, rather than just talking about what will be done.

Customer collaboration rather than contract negotiation is about bringing people along with you and working in partnership, achieving results together. Embracing and managing change to be innovative and deliver value whilst still being competitive and minimising unproductive churn and waste.

When thinking about responding to change over following a plan, it’s about being able to innovate and iterate. Prioritising and working on the most important work first. Building in short feedback loops and taking on board feedback.

Post it notes on a wall

Why is ‘being agile’ important?

Because as the market changes, and users expectations change, companies that can not take onboard feedback and iterate their products and services loose out. This is also true when it comes to companies themselves in terms of what they offer their staff, less people now go to work just for the money, people want more job satisfaction, empowering staff to make decisions and cutting bureaucracy are not only ways to cut costs, but also increase the value to both your users, your stakeholders and your staff.

Resources to help:

  • Scrum.org have a decent blog on Agile Leaders which can be found here
  • For Leaders in the Public Sector, the Digital Academy has an Agile for Leaders course, details of which can be found here
  • The Centre for Agile Leadership has a blog on business agility here (and for those in the US they run courses)
  • And the Agile Business Consortium have a white-paper describing the role of culture and leadership within Agile which can be found here

Welcome to the Dark Side.

Last week I started working for @BeDifrent, a business transformation agency working with both Public and Private sector clients to help them deliver #TechForGood.

This is a massive change for me, I spent almost 15 years in the Public Sector, I always said I was a public servant for life, and in my heart I am, when people have asked me this week what I do it’s been very odd to not reply “I work in the public sector”.

But the thing is, I still am, Difrent’s clients are predominantly public sector at the moment (at least the ones I’ve been dealing with in my first two weeks). The challenges our clients are facing are so similar to those I’m used to facing, but the opportunities are so much bigger.

At my interview I got asked why I was interested in this role, and my answer was very honest and in two parts.

One, for my career development. I’ve spent three years working at Deputy Director level as a Head of Product in the Public Sector, and I loved my role. Product and Service design are things that I am passionate about, and designing and delivering services to users that really matter, that improve things for them, is the thing that drives me.

But I’d also realised what I did was wider than the label “Head of Product” really allowed for. So much of my effort and time was on the cultural and organisational changes organisations needed to make to enable them to deliver and change into a Product and User led organisation.

Which is what led me to consider Difrent. When I saw the job advertised I did my homework on the company and the people. Who were they? What made Difrent different? Why did they care?

My mentor for years had been recommending I consider doing a stint outside of the public sector to gain experience from the other-side of the table, but the thought had always made me twitch, but what I saw from Difrent’s information, from reading up on the amazing Rachel Murphy and from talking to colleagues who had made the jump into the dark side to both Difrent and other like minded agencies recently made me feel that maybe this was the time to take that leap into the dark.

My focus will be on working with our clients to ensure we can deliver. Supporting our teams and building our capability to ensure we keep doing the right things in the right ways.

So yes, not only will this give me experience on the other side of the contracting table, and the opportunity to see how the other side live. But the public sector still need us suppliers, there will always be short term projects and pieces of work that it makes sense to use suppliers to help with rather than massively increase their headcount’s, and more importantly (for me) we have more flexibility sometimes, the chance to quickly bring in different perspectives and points of view.

Difrent describe themselves as being activists for change and doing the right thing. They are passionate about delivering things that matter, and only working with clients who meet their #TechForGood ethos.

And for me that is Difrent’s main attraction, they want to help bring about that change, to ensure we are delivering the right things in the right way for the right reasons. Advocating and agitating for that change and real transformation.

As someone who talks a lot about finding their tribe, I look around the company and see a lot of great people passionate about delivering real change. It was especially great to see and hear the diversity and inclusion stats for the company being proudly discussed at events. One of the things that attracted me to Difrent is how much they talk about their people, and how important their people are to them, it feels like a real community of people who care. As stated by Dan Leakey, what ever our makeup, Difrent are 100% awesome.

With credit to @RachelleMoose for the inforgraphic

And while it’s only midway through week two, what I’ve seen so far has already made me feel like the dark side is full of bright lights. I’ve spent time in both Newcastle and Blackpool with some of our delivery teams, getting to understand the outcomes we are trying to deliver and why, and how we can best support our clients to meet their user’s needs.

Darth Vader with wings and a halo

So while I do intend to return to the public sector in the future with lots of new great experience under my belt, for now I feel like the message is “welcome to the dark side, we’re not all bad.”