×

Tag: Digtial

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.

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

When is Digital not Digital?

When it’s not about user needs or human centric design, but instead about fixing technological infrastructure.

When it’s not about transforming the service but keeping the lights on systems.

When it’s not about asking “why?”, because you already know the solution you want.

A sign asking “Why?”

As Tom Loosemore said, Digital is applying the culture, practices, processes & technologies of the Internet-era to respond to people’s raised expectations.

There are lots of conversations online about being digital, not doing digital. Digital is not a process, it is a cultural mind-set.

It is a way of asking questions and prioritising needs. It’s about delivering value and designing services that meet user needs and expectations.

A person using a smart phone.

Now and then you can still see organisations that use Digital as a label when they mean technology or IT.

However, those things are not interchangeable. The culture and mindset of of the teams of the teams, and the organisations itself, is very different.

In organisations that use digital as a label but are not embracing what it means to be digital you will still see a separation between change or transformation and digital. They will still have siloed ways of working.

The business will still separate the programme funding, governance and strategy from the digital teams tasked with delivery.

Organisations where digital is a way of working, not just a label, you will see properly empowered teams made up of people from across the business. You will have teams who ‘own’ the holistic service they are delivering from strategy to delivery.

Open plan digital office space

These are organisations where the multidisciplinary team isn’t just something that digital ‘do’ but the whole organisations embraces.

This comparison between Digital and Technology is equally relevant when considering the role of the Chief Digital Officer vs. a Chief Technology Officer or Chief Information Officer. There’s a good discussion of the various roles here. As with the other roles the Chief Digital Officer looks after an organisations data and technology assets. However, they go one step further and have a wider eye, considering the strategy and the possibilities for innovation and wider transformation. Their focus is not on keeping the lights on, but understanding why the lights are needed and are there any other options?

Servers

For me this sums up why digital is wider ands more far reaching than Technology, and why the Digital mind-set and culture is so important to get right for organisations trying to deliver transformation. And why, if you don’t have these things right, if you are digital in name but not culture, you are going to struggle to deliver real transformation.

What does a Product Owner own anyway?

Recently Ross Ferguson wrote a great blog about why GDS chose Product Manager rather than Product Owner as the role title of its Product people.

Ross is right when he says that Product Management is the profession, and more widely understood by the wider industry, so why do we in DWP not use that term for our people?

I could be, and often am, glib about why DWP chose to stick with Product Owner, even after we stopped purely using SCRUM methodology, but a good conversation on twitter got me thinking about the debate again.

So what is a Product Owner?

The question on Twitter was ‘does Business Analyst + Project Manager = Product Owner?’ And while a good PO needs some of the skills from both of those professions, that’s not all they are.

For me, a good Product Owner is part Business Analyst, part project manager, part researcher and part service designer.

They have to analyse and understand the problems and options whilst also researching and understanding the needs of their users. They have to understand and manage the details whilst also being able to dream big and understanding the opportunities.

But they don’t own the analysis, or the research, or the plans or the design, they don’t own the code or the solution. Agile is a team sport, and as @Scott offer says a good Product Owner is the generalist in a roomful of specialists. They manage the backlog and make sure all the things happen, but they don’t own those tasks.

Product Owners are accountable for making sure we develop the right thing. That we solve the right problem. That we meet the needs of our users in the right way. But accountability and ownership are different.

So, if they don’t own the tasks, is it actually the Product they own? In smaller organisations, absolutely. But in an organisation as big as DWP do our Product Owners really own the full end to end service?

Honestly? 8 times out of 10 probably not. Most of our Products and Services are so big they can only be owned by the Senior Responsible Officer.

So what do they own?

The vision.

The vision is what makes or breaks a Product or Service. A good vision solves a bigger problem. A good vision is the difference between transforming something or redesigning it. A good vision challenges and moves us all on.

And that is what a Product Owner owns.

I don’t think Product Manager is wrong, and in the future the community in DWP may choose to being Product Managers, they are all empowered to choose the term that they feel fits best, but it’s not the term that resonates with me.

I own the Vision, it does not own me.

Sorry, for the geeks amongst you, this is Vision…. I’ll get my coat.

Originally posted on Medium