×

Tag: Agile

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.

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.

Notes from some Digital Service Standard Assessors on the Beta Assessment

The Beta Assessment is probably the one I get the most questions about; Primarily, “when do we actually go for our Beta Assessment and what does it involve?” 

Firstly what is an Assessment? Why do we assess products and services?

If you’ve never been to a Digital Service Standard Assessment it can be daunting; so I thought it might be useful to pull together some notes from a group of assessors, to show what we are looking for when we assess a service. 

Claire Harrison (Chief Architect at Homes England and leading Tech Assessor) and Gavin Elliot (Head of Design at DWP and a leading Design Assessor, you can find his blog here) helped me pull together some thoughts about what a good assessment looks like, and what we are specifically looking for when it comes to a Beta Assessment. 

I always describe a good assessment as the team telling the assessment panel a story. So, what we want to hear is:

  • What was the problem you were trying to solve?
  • Who are you solving this problem for? (who are your users?)
  • Why do you think this is a problem that needs solving? (What research have you done? Tell us about the users journey)
  • How did you decide to solve it and what options did you consider? (What analysis have you done?) 
  • How did you prove the option you chose was the right one? (How did you test this?)

One of the great things about the Service Manual is that it explains what each delivery phase should look like, and what the assessment team are considering at each assessment.

So what are we looking for at a Beta Assessment?

By the time it comes to your Beta Assessment, you should have been running your service for a little while now with a restricted number of users in a Private Beta. You should have real data you’ve gathered from real users who were invited to use your service, and your service should have iterated several times by now given all the things you have learnt. 

Before you are ready to move into Public Beta and roll your service out Nationally there are several things we want to check during an assessment. 

You need to prove you have considered the whole service for your users and have provided a joined up experience across all channels.

  • We don’t want to just hear about the ‘digital’ experience; we want to understand how you have/will provide a consistent and joined up experience across all channels.
  • Are there any paper or telephony elements to your service? How have you ensured that those users have received a consistent experience?
  • What changes have you made to the back end processes and how has this changed the user experience for any staff using the service?
  • Were there any policy or legislative constraints you had to deal with to ensure a joined up experience?
  • Has the scope of your MVP changed at all so far in Beta given the feedback you have received from users? 
  • Are there any changes you plan to implement in Public Beta?

As a Lead Assessor this is where I always find that teams who have suffered with empowerment or organisational silos may struggle.

If the team are only empowered to look at the Digital service, and have struggled to make any changes to the paper/ telephony or face to face channels due to siloed working in their Department between Digital and Ops (as an example) the Digital product will offer a very different experience to the rest of the service. 

As part of that discussion we will also want to understand how you have supported users who need help getting online; and what assisted digital support you are providing.

At previous assessments you should have had a plan for the support you intended to provide, you should now be able to talk though how you are putting that into action. This could be telephony support or a web chat function; but we want to ensure the service being offered is/will be consistent to the wider service experience, and meeting your users needs. We also want to understand how it’s being funded and how you plan to publish your accessibility info on your service. 

We also expect by this point that you have run an accessibility audit and have carried out regular accessibility testing. It’s worth noting, if you don’t have anyone in house who is trained in running Accessibility audits (We’re lucky in Difrent as we have a DAC assessor in house), then you will need to have factored in the time it takes to get an audit booked in and run well before you think about your Beta Assessment).

Similarly, by the time you go for your Beta Assessment we would generally expect a Welsh language version of your service available; again, this needs to be planned well in advance as this can take time to get, and is not (or shouldn’t be) a last minute job! Something in my experience a lot of teams forget to prioritise and plan for.

And finally assuming you are planning to put your service on GOV.UK, you’ll need to have agreed the following things with the GOV.UK team at GDS before going into public beta:

Again, while it shouldn’t take long to get these things sorted with the GOV.UK team, they can sometimes have backlogs and as such it’s worth making sure you’ve planned in enough time to get this sorted. 

The other things we will want to hear about are how you’ve ensured your service is scalable and secure. How have you dealt with any technical constraints? 

The architecture and technology – Claire

From an architecture perspective, at the Beta phases I’m still interested in the design of the service but I also have a focus on it’s implementation, and the provisions in place to support sustainability of the service. My mantra is ‘end-to-end, top-to-bottom service architecture’!

 An obvious consideration in both the design and deployment of a service is that of security – how the solution conforms to industry, Government and legal standards, and how security is baked into a good technical design. With data, I want to understand the characteristics and lifecycle of data, are data identifiable, how is it collected, where is it stored, hosted, who has access to it, is it encrypted, if so when, where and how? I find it encouraging that in recent years there has been a shift in thinking not only about how to prevent security breaches but also how to recover from them.

Security is sometimes cited as a reason not to code in the open but in actual fact this is hardly ever the case. As services are assessed on this there needs to be a very good reason why code can’t be open. After all a key principle of GDS is reuse – in both directions – for example making use of common government platforms, and also publishing code for it to be used by others.

Government services such as Pay and Notify can help with some of a Technologist’s decisions and should be used as the default, as should open standards and open source technologies. When  this isn’t the case I’m really interested in the selection and evaluation of the tools, systems, products and technologies that form part of the service design. This might include integration and interoperability, constraints in the technology space, vendor lock-in, route to procurement, total cost of ownership, alignment with internal and external skills etc etc.

Some useful advice would be to think about the technology choices as a collective – rather than piecemeal, as and when a particular tool or technology is needed. Yesterday I gave a peer review of a solution under development where one tool had been deployed but in isolation, and not as part of an evaluation of the full technology stack. This meant that there were integration problems as new technologies were added to the stack. 

The way that a service evolves is really important too along with the measures in place to support its growth. Cloud based solutions help take care of some of the more traditional scalability and capacity issues and I’m interested in understanding the designs around these, as well as any other mitigations in place to help assure availability of a service. As part of the Beta assessment, the team will need to show the plan to deal with the event of the service being taken temporarily offline – detail such as strategies for dealing with incidents that impact availability, and the strategy to recover from downtime and how these have been tested.

Although a GDS Beta assessment focuses on a specific service, it goes without saying that a good Technologist will be mindful of how the service they’ve architected impacts the enterprise architecture and vice-versa. For example if a new service built with microservices and also introduces an increased volume and velocity of data, does the network need to be strengthened to meet the increase in communications traversing the network?

Legacy technology (as well as legacy ‘Commercials’ and ways of working) is always on my mind. Obviously during an assessment a team can show how they address legacy in the scope of that particular service, be it some form of integration with legacy or applying the strangler pattern, but organisations really need to put the effort into dealing with legacy as much as they focus on new digital services. Furthermore they need to think about how to avoid creating ‘legacy systems of the future’ by ensuring sustainability of their service – be it from a technical, financial and resource perspective. I appreciate this isn’t always easy! However I do believe that GDS should and will put much more scrutiny on organisations’ plans to address legacy issues.

One final point from me is that teams should embrace an assessment. Clearly the focus is on passing an assessment but regardless of the outcome there’s lots of value in gaining that feedback. It’s far better to get constructive feedback during the assessment stages rather than having to deal with disappointed stakeholders further down the line, and probably having to spend more time and money to strengthen or redesign the technical architecture.

How do you decide when to go for your Beta Assessment?

Many services (for both good and bad reasons) have struggled with the MVP concept; and as such the journey to get their MVP rolled out nationally has taken a long time, and contained more features and functionality then teams might have initially imagined.  

This can make it very hard to decide when you should go for an Assessment to move from Private to Public Beta. If your service is going to be rolled out to millions of people; or has a large number of user groups with very different needs; it can be hard to decide what functionality is needed in Private Beta vs. Public Beta or what can be saved until Live and rolled out as additional functionality. 

The other things to consider is, what does your rollout plan actually look like? Are you able to go national with the service once you’ve tested with a few hundred people from each user group? Or, as is more common with large services like NHS Jobs, where you are replacing an older service, does the service need to be rolled out in a very set way? If so, you might need to keep inviting users in until full rollout is almost complete; making it hard to judge when the right time for your Beta assessment is. 

There is no right or wrong answer here, the main thing to consider is that you will need to understand all of the above before you can roll your service out nationally, and be able to tell that story to the panel successfully. 

This is because theoretically most of the heavy lifting is done in Private Beta, and once you have rolled out your service into Public Beta, the main things left to test are whether your service scaled and worked as you anticipated. Admittedly this (combined with a confusion about the scope of an MVP) is why most Services never actually bother with their Live Assessment. For most Services, once you’re in Public Beta the hard work has been done; there’s nothing more to do, so why bother with a Live Assessment? But that’s an entirely different blog! 

Reviewing the service together.

 

The art of Transferring Knowledge

One of the most common questions that comes up in Bid opportunities is usually some variant of “how do you transfer your knowledge to us before you leave?”

This is completely valid question, and really important to both ask, and to understand, but also hard to answer well in 100 words without risking looking like knowledge transfer is only a nice to have!

Having been on the other side of the commercial table, making sure you get a supplier who will want to work with you and up-skill your own people so you are not reliant on the supplier forever is generally vital to both making sure the project is successful, and cost effective.

Developers comparing code together

I’ve written Invitations to Tender that ask for examples of how suppliers would go about transferring knowledge and up-skilling my teams. I’ve sat through bid tender presentations as the buyer and listened to suppliers try to persuade me that they know best, and that they have the expertise my organisation needs to deliver a project or programme.

I was generally able to spot very quickly those organisations that took this more seriously than others, those that would work collaboratively with us vs. those more likely to just come in and do a sales job and leave us none the wiser reliant on their services.

But, if I’m honest, I never really judged that feel on the words they said, but more through the words they didn’t say, and more importantly HOW they said or didn’t say it.

Everyone can say the words ‘show and tell’, but how are you doing them? How are you getting stakeholders engaged? How are you making sure you have the right people turning up to engage with the project?

A person standing in front of a whiteboard moving a post it note in a team meeting

You can say you use Trello, JIRA, or Confluence etc. to create shared digital spaces to run your backlogs or share information; but how do you make sure the right people have access to them and know how to use them? How do you agree what information is going on there and when? How do you determine what information the team can see vs. your stakeholders, and make sure the information is understandable to everyone who needs it?

As long as suppliers are putting in key buzzwords, that nuance is hard to judge within 100 words, but so key to understand. And it’s not only important for the buying organisation to understand how the supplier would transfer knowledge, but it’s actually really important for the supplier to understand how receptive an organisation is as well.

I always assumed ‘knowledge transfer’ was something that was easy for suppliers to do as long as they put in some effort.

Now I sit on the other side of the table, its something i’ve realised there is a real art too. Not just writing a bid response that gets the message across, but doing it once you hit the ground. I’d always assumed that, as long as the team/ buying organisation was keen and engaged, knowledge transfer would be easy to do.

Two people talking in front of a white board that shows flow charts and prototypes.

Eight months later I’ve realised it’s not as easy as it looks, as a supplier there’s a very fine line to walk between supporting an organisation, and looking patronising. Just as every organisation is somewhere different on their agile/digital journey, so is every individual.

A one size fits all approach to transferring knowledge will never work. You can’t assume because an organisation is new to agile or digital, every individual within the organisation is. Some organisations/people want more in the way of ‘coaching and mentoring’ others want less. Some organisations/people will say they are open to changing their ways of working, but will resist anything new; others are champing off your hand for every new tool or technique. Some want walking through everything you are doing so they can learn from it, others want you to just get on and deliver and tell them at the end how you did it.

And as suppliers, there is often as much we have to learn from the organisation as there is to ‘teach’, while we might be the experts in agile or digital or delivering transformation; we need to learn about and understand how their organisation works and why.

Two people having a conversation

There is no ‘one answer’ on how to do knowledge transfer, and it’s not a one way street. It’s how you approach the question that is important. Are you open to working with an organisation (either as the buyer or the supplier) to understand how you can work together and learn from each other? As long as you are open to having those conversations and learning from each other, then the knowledge transfer will happen.

Why SME’s are important, but shouldn’t be the Product Manager

Along time ago in a land far away; well four years ago and sat in a very cold office in trafalgar square; Ross Ferguson , Alex Kean , Scot Colfer and I plus a few others sat discussing the DDaT capability framework for Product Management.

The discussions we had at the time focused on “how do we actually define the role? And what makes a good product manager?” And there have been plenty of blogs written on those questions over the years. It definitely feels like the role has matured and progressed over the last few years, and now is generally pretty well recognised.

However yesterday chatting to Si Wilson about SME’s and Product Managers, and why they were different roles, I realised this may be one area not touched on much, and actually a pretty key difference it’s important to understand.

In the private sector, the Product Manager is often “the voice of the business”, they are equally seen as the “voice of the customer” but when developing products to take to market and make a profit, it’s less about what the users need, and what the business can sell to them.

In the Public Sector, the role of the Product Manager is a bit different. The Product Manager is NOT the voice of the business, instead they are the voice of the vision. The Product Manager is responsible for ‘what could be’ they ensure the team are delivering quality and value, weighing up the evidence from everyone else in the team and making the decisions on where to focus next in order to meet the desired outcomes.

This slight change in focus is where the role of the Subject Matter Expert (SME) comes in. The Scrum Dictionary states the SME is the person with specialised knowledge; in my experience the SME provide’s the voice of the business; and what ‘is’ rather than what will be. They understand the in’s and out’s of an existing product, service or any sacred cows that need to be avoided (or understood) within an organisation. They usually work closely with the Business Analyst to map out business processes and User Researchers to understand staff experiences.

Back when we merry band of Head’s of Product were trying to understand the role, the decision to not have Product Managers ‘be the voice of the business’ was a very deliberate move as we felt it hampered the move to User Centred design, as it felt it was hard to step back and be agnostic about the solution if you’ve had years in the business and know every pain point and workaround going etc.

Some of the dangers of having a Product Manager who is also an SME are:

  • They feel they know everything already because of their experience, so feel that user research or testing is a waste of time.
  • They become a single point of failure for both knowledge and decision making, with too many people needing their attention at the same time
  • They can get lost in the weeds of details, which can lead to micromanaging or a lack of pace

That is not at all to say that Product Managers can’t ‘come from the business’ because obviously having some knowledge about the organisation and the service is helpful. But equally, having a clear delineation between the roles of the Product Manager and the SME is important; so if you do have someone covering both roles, it’s important to understand which hat is being worn when decisions are made; and for that individual to be able to draw a line between when they are acting as the PM and when they are the SME.

A person presenting at a whitewall to a team

As a Product person, a good SME is worth their weight in gold. good ones bring loads of speed and stretching thinking — and even packaging thinking. They can help identify pain points, and help user researchers and business analysts find the right people to talk to when asking questions about processes’ etc. They give the Product Manager room to manoeuvre, and make sure things are moving on. Equally the best SME’s can be pragmatic, they understand that what the business wants doesn’t always match what users want, and work with the team to find the best way forward.

Where the role of the SME hasn’t worked well, in my experience, it tends to be because the individual hasn’t been properly empowered to make decisions by their organisation or line manager; or don’t actually have the knowledge required, and are instead their to capture questions or decisions and feed them back to their team/manager. Another common issues is that the SME can’t be pragmatic or understand the difference between user needs and business needs; and won’t get involved in user research or understand its importance. Rather than helping the team move work forward, they slow things down; wanting every decision justified to their satisfaction; wanting to make decisions themselves rather than working with the Product Manager.

Rarely have I found SME”s that could be dedicated full time to one project, they tend to be Policy or Ops experts etc. and so there are a lot of demands on their time. I suspect this is one of the reasons the role of the SME and Product Manager if sometimes blended together. However, while they ‘can’ be filled by the same person, in my experience having those roles filled by separate people does work much better, and allow the team to deliver value quicker.

Delivering in a crisis

One of the key personal aims I had when I joined Difrent, just over six months ago, was to work somewhere that would let me deliver stuff that matters. Because I am passionate about people, and about Delivery;

After 15 years, right in the thick of some pioneering public sector work, combining high profile product delivery with developing digital capability working for organisations like the Government Digital Services (GDS), Department of Work and Pensions (DWP), The Care Quality Commission (CQC), and the Ministry of Defence (MoD); I was chaffing at the speed (or lack thereof) of delivery in the Public sector.

Parcel delivery

I hoped going agency side would remove some of that red tape, and let me get on and actually deliver; my aim when I started was to get a project delivered (to public beta at the very least) within my first year. Might seem like a simple ask, but in the 10 years I spent working in Digital, I’d only seen half a dozen services get into Live.

This is not because the projects failed, they are all still out there being used by people; but because once projects got into Beta, and real people could start using them, the impetus to go-live got lost somewhat.

Six months into the job and things looked to be on track, with one service in Private beta, another we are working on in Public Beta; plus a few Discoveries etc. underway; things were definitely moving quickly and I my decision to move agency side felt justified. Delivery was happening.

And then Covid-19 hit.

Gov.uk COVID-19 website
A tablet displaying the Gov.uk COVID-19 guidance

With COVID-19, the old normal, and ways of working have had to change rapidly. If for no other reason than we couldn’t all be co-located anymore. We all had to turn too fully remote working quickly, not just as a company but as an industry.

Thankfully within Difrent we’ve always had the ability to work remotely, so things like laptops and collaborative software were already in place internally; but the move to being fully remote has still been a big challenge. Things like setting up regular online collaboration and communication sessions throughout our week, our twice-daily coffee catchups and weekly Difrent Talks are something created for people to drop in on with no pressure attached and has helped people stay connected.

The main challenge has been how we work with out clients to ensure we are still delivering. Reviewing our ways of working to ensure we are still working inclusively; or aren’t accidentally excluding someone from a conversation when everyone is working from their own home. Maintaining velocity and ensuring everyone is engaged and able to contribute.

This is trickier to navigate when you’re all working virtually, and needs a bit more planning and forethought, but it’s not impossible. One of the positives (for me at least) about the current crisis is how well people have come together to get things delivered.

Some of the work that we have been involved in, which would generally have taken months to develop; has been done in weeks. User research, analysis and development happening in a fraction of the time it took before.

Graffiti saying ‘Made in Crisis’

So how are we now able to move at such a fast pace? Are standards being dropped or ignored? Are corners being cut? Or have we iterated and adapted our approach?

Once this is all over I think those will be the questions a lot pf people are asking; but my observation is that, if nothing else, this current crisis has made us really embrace what agility means.

We seem to have the right people ‘in the room’ signing off decisions when they are needed; with proper multidisciplinary teams, made up of people from both digital but also policy and operations etc, that are empowered to get on and do things. Research is still happening; but possibly at a much smaller scale, as and when it is needed; We’re truly embracing the Minimum Viable Product, getting things out there that aren’t perfect, but that real people can use; testing and improving the service as we go.

Once this is all over I certainly don’t want to have to continue the trend of on-boarding and embedding teams with 24 hours notice; and while getting things live in under 2 weeks is an amazing accomplishment; to achieve it comes at a high price – Not just in terms of resources but in terms of people, because that is where burnout will occur for all involved. But I believe a happy medium can be found.

My hope, once this is all over, is that we can find the time to consider what we in digital have learnt, and focus on what elements we can iterate and take forward to help us keep delivering faster and better, but in the right way, with less delays; so we can get services out there for people to use; because really, that is what we are all here to do.

Stay home, stay safe, save lives
Sign saying ‘stay home, stay safe, save lives’



How do we determine value?

And how do we make sure we are delivering it?

In a previous blog I discussed the importance of understanding the value you are trying to add, and how you measure cost vs vale. How we measure value and ensure we are delivering a valuable return on investment is one of the ‘big’ questions at the moment, that never seems to go away.

Scott Colfer has equally blogged before on the complexity of measuring value when there is no profit to measure against. When working in the public sector it’s not an easy problem to solve. There is a lot of conversations about making sure we don’t waste public money, but how do we actually make sure public money is being spent in a valuable way?

A jar of coins
A jar of coins being spilt

The first principle of the Agile Manifesto is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” But what is valuable?

At a kick off session this week, for a new project we’re shortly going to begin, a client said one of their hopes was that all code deployed would work first time; and someone else stated that they ‘didn’t want rework’. When we broke these thoughts down to understand where these fears were coming from, it was the need to add value and not waste money; which itself was coming from previous issues caused by a long time to deploy, and the cost to make changes.

There was equally the fear that by swapping out suppliers mid project we (as the new supplier) would want to redesign and rework everything to make it our own; which would slow down delivery and drive up cost even more.

There is obviously no value for anyone in doing that. The value comes by having a short feedback loop, co-designing and constantly testing, learning and iterating, working together in short weekly or fortnightly sprints, to get things delivered. Making sure there is little time as possible between designing something, to getting it tested and used by real users; ensuring it meets their needs as quickly as possible.

Through examining what has been delivered already against the user needs and the outcomes the organisation is looking to achieve; by identifying gaps and pain-points we reduce waste; and by prioritising the areas where improvements can be made we ensure that reworking only happens when there is actual value in doing so.

A parcel being delivered
Parcel delivery

At a talk this week I was asked how we prioritise the work that needs doing and ensure that we do deliver. The important thing is to deliver something, but ideally not just any old thing, we want to ideally be delivering the right thing. Sometimes we won’t know what that is, and it’s only by doing something that we can establish whether that was the right thing or not. But that’s why short feedback loops are important. Checking back regularly, iterating and testing frequently, allows you too recognise when there is value in carrying on vs. value in stoping and doing something different.

When I’m trying to decide where the value is, and where is the best place to start, I consider things like:

  1. Why are we doing this?
  2. Why are we doing it now?
  3. What happens if we don’t do this now?
  4. Who will this affect?
  5. How many people will it impact?
  6. How long could this take?
  7. Any indicative costs?
  8. Any key milestones/ deadlines?
  9. Any critical dependancies that could affect our ability to deliver?
  10. Will this help us deliver our strategy? Or is it a tactical fix?

Once we have started work, it’s important to agree measure of success (be they financial, reducing time, staffing numbers; or things like improved uptake or a better customer experience) and keep measuring what is being delivered against those targets.

At Difrent a key part of the value we add is about the people, not just the technology or processes; there is value in us working in the open, by being transparent; running lunch and learn sessions or talks; blogging or speaking at events etc. we can add wider value outside of a specific project or service.

A person presenting at a whitewall to a team
People listening to someone speaking/ sharing

When we are considering what adds value, the other thing it’s important to consider is the culture we are delivering in. Are there communities of practice in place already, any design patterns we should be adhering too? There is value in building in consistency, as this helps us ensure we are delivering quality.

There are many different ways to determine what adds value, and many different kinds of value, but the importance is by focusing on making positive improvements, and by constantly learning from mistakes and ensuring they don’t get repeated so no time is wasted and real value can be delivered.

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