×

Category: Leadership

Scrum Master or Delivery Manager – what’s in a name?

Are the roles of Scrum Master and Delivery manager the same?

Continuing on my recent musings on the different roles within Agile multidisciplinary teams, today’s blog focuses on the role of the Delivery Manager, or the Scrum Master, and whether these roles are really the same thing.

This is a conversation that came up a few weeks ago at the #ProductPeople community meetup in Birmingham, and something that causes quite a bit of frustration from those people I’ve talked to in the Delivery Manager community.

The role of the Scrum Master is that of facilitator within the multidisciplinary team, it is a role particular to Scrum, and they are the ‘expert’ on how to make Scrum work, often described as a ‘Servant leader’ they help everyone in the team understand the theory and practices of Scrum as a way of working together.

Within digital government the role has been widened out to include other responsibilities, and often mixed with the role of the Delivery Manager. Emily Webber did a fantastic blog a few years ago on the role of the Delivery Manger, and as she put’s it, while the roles are often used interchangeably, they really shouldn’t be.

But why not? What makes them different?

As said above, the Scrum Master focuses on the ‘how’ of Scrum as a methodology. The are the expert in the room on how best to utilise Scrum to deliver. They are more akin to an agile coach, guiding the team, and often the person best versed on the most up to date practices and ways of working.

But for me, the Delivery Manager focuses more on the ‘What’ and ‘When’. While the Product Manager (or Owner) focuses on ‘Why’ the team are doing what they are doing, the problems they are trying to solve, the vision they are trying to deliver. The Delivery Manager is looking at what could block the team from being able to deliver; what the right make up of the team needs to be in terms of roles and capabilities, what governance processes does the team have to meet in order to stay on track to deliver, and when delivery will happen.

As the Digital Data and Technology capability framework says, at the most basic level the delivery manager is accountable for the delivery of products and services. They are very much a doer paired with the Product Managers visionary thinker. They make sure things actually happen. They hold the Product Manager and the team to account and keep them on track.

They are the heart of the team, responsible for maintaining the health and happiness of the team; they understand who from the team will be available and when, making sure people are able to work well together, identifying conflicts and ensuring the team stay motivated and happy in order to enable delivery.

When you look at the role as explained in the capability framework it looks very straight forward, build and motivate teams, manage risk s and issues, ensure delivery, ok great. But then you get to the bit that merges the scrum master tole and the delivery manager role, and this is where a lot of individuals I know within the team struggle, “coach team members and others, facilitate continuous improvement and apply the most appropriate agile and lean tools and techniques for their environment”.

This is actually quite a big task, to stay on top of the most appropriate agile and lean tools and techniques requires a lot of self learning; which is fantastic, but also requires quite a bit of time away form the team you are meant to be supporting.

Most Delivery Managers that I know (certainly within CQC, and others I have talked to across Government) are involved with (if not directly responsible for) the business cases for their Products and Services. Unblocking issues, ensuring funding requests, requesting resources, etc. this all takes up a lot of a Delivery Managers time. When you are also meant to be running the daily stand-ups, managing team retrospectives, monitoring team velocity and organising show and tells you can find your days are very full.

More and more delivery managers that I know are finding they just don’t have time for the ‘people centric’ part that is meant to be at the heart of their role, as Projects and Programmes utilise them more and more as project Managers who are also scrum masters, and so our Delivery managers feel pulled in two directions, and our teams suffer because of it.

When organisations so often find they are struggling to deliver, often at the heart of that is the issue that they have not properly recognised the role of the Delivery Manager. This is a fundamental issues, especially when organisations are new to agile ways of working. Embedding ‘how’ to be agile, takes up just as much time as understanding ‘what’ you can deliver and ‘when’.

Perhaps in mature agile organisations bringing those roles together makes more sense, but for now I think we need to go back to letting our Delivery Managers focus on making sure we can deliver, and our scrum masters helping us use the right techniques to be able to delivery well.

What is the value in a Head of Product?

Our numbers are growing, but what is the role, and what value does it add?

When I first took up the role of ‘Head of Product Management’ back in October 2016, I was one of the first in Government to have the title, and within a few months there was a very small band of 5 of us, who were responsible for looking after the Product Management professionals within our own Government Departments. We were professional leaders, tasked with building capability and skills, and building communities of practice. The original job description we created for a Head of Product was very different to what I do now.

In my first 12 months of the role I focused on the people, working with the others across government to develop a capability framework, training and development plan and a career pathway that Product Managers could use to develop a proper career as a Product Manager within Government.

A lot of our time was spent debating the skills Product Managers needed, and what value Product Managers brought to Projects and teams. It was, upon reflection, a very inward focused role; which given the maturity of the profession at that time made sense. But several years later user needs have changed and I think it’s a good time to reflect on the value we Heads of Product now find ourselves adding within our work, and making sure everyone understands the work some of us are now doing and why. To discuss what that difference is between what we were doing and what we are doing now, and does everyone understand and agree that difference.

This change in the dichotomy of the Head of Product role came up at our last Head of Product catch up, for those of us in role a few years ago, we have all separately found that our focus isn’t purely on developing that community and the professional skills and capabilities of Product Managers anymore.

Instead we are now focussing on Product strategies, on aiding Prioritisation of portfolios, of working with Senior leaders to break problems down, understanding the value we are trying to gain, or the outcomes we are trying to achieve through the Products and Services we are developing. We’re running roadmap workshops across directorates, debating Targeting Operating Models and strategic alignment.

Most departments are now hiring ‘Head’s of Product’ or ‘Deputy Directors of Product’ to be part of their Senior Leadership teams within Digital, and personally I think that is the right move.

As organisations mature in their agile ways of working, the role of prioritisation has become ever more important, and as Product Management professionals, the ability to weigh up data and evidence to make decisions about priorities is our bread and butter. As organisational budgets continue to be constrained we all need to get better at focusing on outputs and understanding the value we are looking to deliver through our projects and programmes, ensuring we are meeting user needs whilst spending public money wisely. Determining priorities and ensuring we are delivering value for users are the fundamental objectives of the Product Manger role, and as such it makes sense to utilise those skills at an organisational level.

We are, in fact, much closer to our counterparts in the private sector determining Returns on Investment etc. than we have ever been before. Yes, we as Head’s of Product still work with Product Managers and teams to help them ensure they are meeting the standards and delivering value, and we still look at the resource demands of teams and make calls on which person within our professional community might be best placed to work on with Product; and in some departments the community is so big that actually they still need someone to focus onleading that; but for the most part, our communities and our people have grown along with us, and most don’t need the level of support from us as community managers that they did before.

#ProductPeople

Most of the communities now across government are self-sustaining, events like #ProductPeople are being set up and run by members of the community; and while we as Heads of Product are still here to help champion Product Management, and to support the people in our communities, the role of the Head of Product Management as a community lead, has adapted and gown into what our organisations need now, someone who can use those Product Management skills at an organisational level.

As such, I think it’s time we look at the Digital Data and Technology capability framework again for Product Management, talk to community, and review the job description for the Head of Product role we initially developed and iterate that. We need to understand the role of the community lead and the need for that, whilst also recognising the value of Product Management and the skills Head’s of Product can bring to our senior leadership and our organisations.

Why focusing on productivity isn’t productive.

One thing that comes up time and again from senior managers is “My focus or priority is improving Productivity”.

Early on in my career I worked on a number of ‘productivity improvement inniatives’ and sometimes they would seem to make some improvments, sometimes they wouldn’t, but they never really solved the issues and there always seemed to be more to do to ‘improve productivity’, so I began to wonder whether these projects were ready adding any value.

Nowadays when I talk to a manager to understand why they are prioritising any productivity initative, the answer is usually something like, “we can be more productive, it’ll help us cut costs and deliver a better service.” If I then ask how they plan to do this, the answer is generally “by improving our processes/ transforming our service/ getting more staff”.

Anyone who has ever been responsible for transforming processes or services acknowledges that when you introduce a change or a new way of working productivity drops, at least for a short time. This is a truth pretty much universally acknowledged. In fact lets repeat that, just to be clear, when you introduce any new change to processes, technology or ways of working productivity will drop. This can be as much as 30% while people learn the new processes, or get up to speed with any changes. This drop generally doesn’t last for too long, but it will happen.

Next, when you hire more staff, your existing high performing staff are often the ones tasked with training them and building capability. So, for those staff at least, productivity will drop while they help support and build the capability of your new staff. There’s evidence that it can take new staff 6-12 months to fully get to the same capability and productivity levels as existing staff, and that the productivity of the staff responsible for training and coaching them will be impacted as well.

This is all fine, as long as it is acknowledged upfront. If we tell people that we know their productivity will drop while they get up to speed with these new changes, or help train new staff, then we are helping to reassure them, and managing our own expectations.

But the biggest mistake I often see is a reluctance by senior managers to face that truth. We refuse to change people’s targets, we expect them to still meet the previous demands, and what happens?

First morale drops, and then productivity drops, morale drops more because people are struggling to meet unrealistic targets and then they leave or go off sick, and productivity drops further. In the end the change we’ve introduced fails or we have less staff than we did to start with and we’re actually achieving less than we did before not more. It is almost Oedipal in it’s obviousness, you can see it coming a mile off. So why do Managers do it?

For me this conversation comes down to Managers rather than Leaders, and a failure to look at the actual problem we are trying to fix.

When I work with organisations to understand the outcomes they are trying to reach, or the problems they are trying to fix, productivity is often mentioned, especially in operational delivery spaces.

But by working with both the leadership team and the people delivering on the front line, productivity itself is never really the problem. It’s the IT, or the processes, or the checks and balances we’ve put in place creating multiple handoffs, or generally a mixture of all of the above. So, we’re back to changing processes or introducing new tools or ways of working, but we’ve already said that doesn’t help, right? No.

Changing the tools or processes is absolutely the right thing to do, BUT, we have to really understand why we are doing it. Equally investing in people and training them is absolutely the right thing to do, but, we can’t solely make it all about upping productivity, because that forgets the people who are at the heart of getting things done, treating them solely as resources rather than individuals with thoughts and feelings. By telling people we’re trying to improve productivity we make it sound like they are not already being productive. By imposing change on them to simply improve productivity we are treating them like cogs in a factory and demotivating them before we even start.

Instead we need to talk to them to really understand the problems they are facing, and what blockers or issues they are having to work around to do actually their job. We need to consider their views and ideas and involve them in the process of making any changes. By empowering our people to talk to us about the issues they are facing and consulting them we are hopefully getting them motivated and invested in any changes we make, rather than making the change happen to them we are doing it with them.

We also need to look wider than one particular function or area, it’s likely that what looks like a productivity issue in one function, is actually a more systemic issue. By just trying to improve productivity in one area we are not considering the design of the whole service, but instead working ourselves into a silo.

While we may have assumptions about what changes will work, we we have to accept we may need to try out different options to really improve things, and we have to acknowledge this out loud. Again, it’s important to manage everyones expectations so that people don’t feel disempowered and like the change is happening to them.

And finally we have to reassure people that we know that for a short period of time productivity will drop and that is ok. And you know what? It is ok. Yes, we all have targets to hit, but if for 2 or 3 months every case worker out there processes 13 cases rather than 15, that is acceptable, because within 12 months’ time, if we as change leaders have done our job right, they’ll be processing over 20 cases rather than 15. And they’ll feel listened to, they’ll feel supported, and in the end productivity will go up.

But it’ll be a biproduct of successful change. We’ll have taken people with us, we’ll have learned from the work we have done, and probably given ourselves a nice backlog of things we can do to keep improving things, so that productivity can keep improving; but more importantly our organisation will hopefully be a better place for everyone in it.

So please, next time you hear a senior manager say “My focus is improving Productivity” just ask them how? And if you are that Senior Manager, ask yourself, “Why?” What is the problem you are really trying to solve? Is it really just about productivity?

We need to lead people, not simply manage productivity.

Originally posted on Medium

Making a change or making progress.

At a leadership conference recently there was an interesting debate about whether people perceived making a change or making progress to be more important.

Everyone on my table voted for making a change, my vote initially was for making progress, and so we debated what the difference was.

For me, change can be positive or negative. A negative change isn’t necessarily bad, you can learn from it, but it won’t necessarily move you in the right direction. If you don’t know what outcome you’re looking to acheive or how you will measure whether the change has had the effect you want, how do you know if the you have delivered value or not. There is little value in making changes just for the sake of it.

Progress to me means you are moving in the right direction, towards the outcomes you are looking to acheive. It can be slow, or achieved in small increments, but it is always valuable.

But both good changes and delivering progress both depend on you knowing the outcomes you are looking to achieve, and in my experience that is where organisations tend to struggle most.

They can say what they think the problems are, recognise that things are right, and be willing to make changes to help themselves make progress, but a lot of the time the changes are superficial, offering what are thought to be quick solutions to what are actually much deeper problems, and so the progress is slow and painful.

To transform an organisation and the services it delivers requires a massive change in how the organisation is structured, and more importantly how it thinks.

In my experience this change often starts within Digital, because the organisation views its technology or digital teams as not delivering. And yet the teams can not deliver because the organisation can not express the outcomes it is seeking to achieve or understand the wider problems it is seeking to fix.

This is why user research and business analysis are so important. Why we run Discoveries and encourage service design approaches that span the organisation as a whole, rather than remain within the silos the organisation has structured itself into.

These conversations can be uncomfortable, they challenge hierarchies, organisational structures and traditional assumptions, but they are there to help. Service Design and Product Management is about fostering and supporting those people able to lead those critical conversations, creating the environment we need to deliver outcomes for users and value for organisations.

Being transparent about what the real problems are, and open to new ideas and approaches at an organisational level is key if we want to change and adapt in order to make progress.

When looking to make changes its important to consider the environment we are working within. No conversation is best done via board papers or email, it is best done in the room face to face.

If we can’t move to a culture that values the time and commitment it takes to have those conversations then we must acknowledge that any progress we make will be slow and painful and not deliver any real value or acheive the outcomes we were looking for.

But for all that, recognising that change is needed is the best first step. Stepping up and admitting there is a problem that needs fixing in order to allow you to make any progress against the outcomes you want to acheive is not always easy, but it is important and something we should talk about more.

Needing to change doesn’t mean you have failed or not made progress or delivered no value. It just means you have learnt from what you have done, and recognise there is still more to do and we should celebrate that and talk about it more positively.

Originally posted on Medium

My user manual:

A user manual is a document that tells users how to use a particular system. More recently personal user manuals that help others work with you better have begun to spring up.

I’ve seen a few great examples of personal user manuals recently, most recently from Dan Barrett, and I really like the idea; Unfortunately I’ve never had the time to sit down and draft one.

As I approach the end of my current role and prepare to start at somewhere completely new, I thought it was a good time to reflect on myself, and what it might help others around me to know.

Conditions I like to work in:

  • I like open plan offices, but every now and then I will need a day working from home or a quieter office where I can focus and recharge.
  • I have a high tolerance for background noise, but I don’t like harsh or unexpected noise; similarly with lighting, harsh lighting can give me migraines. •I’m not a fan of hot desking, I prefer having a desk I know is mine. Even when visiting other offices I will always default back to the desk/s I normally sit in. In my office you can always spot my desk as it will have my lego name plate and some bobble heads on it. This may seem odd, but it helps me feel ‘in control’ even when evening else keeps changing.
  • I do enjoy a good workshop, especially if it has post it notes and sharpies, but I’m less of a fan of traditional meetings.
  • My favourite environment is sat with my team, where we can discuss and share what we’re doing, solving problems and achieving things together.
  • I enjoy working in fast paced environments, I’m best when I’m busy and getting things done.

The times/ hours I like to work:

  • I don’t work Fridays, there will generally be an hour or two where I catch up and respond to emails, but Friday is my day for sorting out all the things I need to at home so that at the weekend I can give my son my full attention.
  • I’m usually in the office by 9:30, but I’ll log on at 8 am and start responding to emails and calls on my commute in. I generally leave the office by 4:30, but will answer emails up till 5pm, and then usually log back in for an hour or so once my son goes to bed.
  • For childcare reasons I have one day a week I can’t travel far and tend to work from home or finish a bit earlier, but I balance that by having one day a week I can stay over night or work late.
  • I have the most energy late morning or early afternoon.

The best way to communicate with me:

  • I generally respond quickly to text messages or WhatsApp. •Twitter DM’s are ok, but if I don’t follow you I probably won’t spot DM requests.
  • I don’t like ringing people, and prefer to only answer calls from people I know.
  • I’m not a big fan of emails, especially not long formal email chains. I respond best to quick and easy requests that I can deal with on the move. If it needs proper consideration it will probably have to wait until I have time set aside to be at my desk.
  • I much prefer informal conversations, and respond best to people coming and talking to me. If I’m in an open plan office I’m always interruptible unless I have my headphones in, at which point leave me a note and I’ll come find you when I’m ready.

The ways I like to receive feedback:

  • I prefer feedback one to one in person, rather than in a group.
  • I’m trying to be better at receiving positive feedback and not being embarrassed/self-deprecating,
  • I do like written feedback especially if it’s constructive or critical feedback so that I can properly reflect on it and refer to it, but positive feedback is good in writing too so I can save it and share it with my manager, or with myself when I need a boost.

Things I need:

  • I need to know I am empowered, I need to feel trusted and given autonomy.
  • But I also need to feel supported, I need to know where to go when I need help or just to talk something through.
  • I need to have open conversations, both in a group and one to one.
  • I need big messy problems to solve.
  • I need to be doing things that matter, that are helping people.
  • I need the opportunity to coach and support others, especially when I’m not hands on with a project as it helps me feel like I’m still helping others.
  • I need to have the time to go to events and network, these help me recharge.

Things I struggle with:

  • Putting my thoughts down coherently or capturing action points etc. I’ve worked hard to improve my written and organisational skills, but I know they are not my greatest strengths. When asked for written briefs etc I do better when I’ve got the chance to run it past someone else before submitting. When it comes to organising things, I tend to surround myself with those who are better at it than me.
  • I can find conflict draining, especially if it carries on for a long period. When dealing with conflict I need to be doing something else at the same time where I’m working with ‘my tribe’ and achieving results positively.
  • My memory isn’t great, and I’m usually balancing a lot of things, so if I forget something, do remind me.
  • Delegation, I’m trying to get much better at delegating, but my tendency will always be to protect those working for me, so I need to be reminded that people want me to delegate so that I don’t feel like I’m putting burdens on others.
  • I struggle with unnecessary hierarchy or process. I find it frustrating to explain the same thing over and over again.
  • I struggle to initiate conversations, and I’m not great at small talk with people I don’t know, but I do love talking to and getting to know people.
  • I’m not always great with connecting names to faces, even of people I know, so please don’t be offended if I need a reminder.
  • Talking at people, conferences/ events/ even large meetings are hard for me, but having one or two friendly faces makes all the difference.
  • Eye contact, it’s not you, it’s me. I am listening and I do care. The same with fiddling or doodling. It’s how my brain works, please don’t take it as a sign I’m not paying attention because I am.

Things I love:

  • I love coming up with ideas and solving problems •I love working with a team or one or two others.
  • I like making people laugh
  • I like feeling needed
  • I love building teams
  • I love making a difference, and improving things for people.
  • I love getting to know people, what their interests are, what makes them tick.
  • I love to smile.

Other things to know about me:

  • I am neurodiverse, Dyspraxic with ADHD and Dyslexic tendencies; things like eye contact, doodling, memory etc are all part of this. But I’m good at thinking outside of the box and approaching things from a fresh angle.
  • I am incredibly loyal, if we are friends/colleagues I will always have your back, if you need help I will always do my best for you.
  • I am adaptable and resilient, I will always try to keep going and be flexible in my approach in order to deliver the right thing. I’m good in challenging situations. I get things done.
  • People don’t always think I’m taking things seriously, but I’m very committed and passionate about what I do, I will take on the toughest situations, but I’ll do it with a smile.
  • I’m a people person.
  • I’m a ridiculous extravert and a massive geek, I recharge by spending time with my tribe.
  • I’m a single mum to a neurodiverse child, I work hard to balance my work and home life, and talk openly about the challenges of that in order to support and encourage others to do the same.

Me in a nutshell:

I like to think I fight for what is right, helping others and using my networks and skills to solve problems, just like a certain lady detective. But obviously with less murders and less fantastic outfits.

The Honourable Phryne Fisher

Changing perceptions of Women in Leadership

Originally published at digileaders.com on November 3, 2017.

Zoë Gould, Head of Product and Sue Griffin, Head of User Support Services; DWP Digital

Last month we delivered a breakout session at the Women into Leadership conference in Leeds.

The conference is about managing the challenges of modern leadership, recognising and rewarding female leaders, and enhancing leadership opportunities for women so they can build skills to become the leader they aspire to be.

Redressing the gender balance

In DWP Digital we’re changing lives by transforming the services we deliver, using new technologies and modern approaches to improve things for our users. DWP is huge — we’re the biggest government department — we support 22 million customers and release over £168 billion in payments each year. We’re working to solve important issues, supporting people when they are at their most vulnerable; in order to transform our services we currently work on 50 million lines of code and have around ten thousand IT system changes per year.

However, there is gender imbalance in DWP Digital as we have a shortage of female specialists and leaders — a challenge we share with many large digital organisations where less than 25% of digital roles are filled by women.

We want to change this and improve the gender balance.

The size and scale of our work offers up a lot of scope for a career in digital technology — so how can we change perceptions to help women develop in a digital career?

Well, in DWP Digital, we’re making progress.

We have our Women in Technology group, with a pretty active core membership of people who are keen to maximise the value of being part of this community. People who want to improve gender equality and help members reach their full potential by encouraging personal and professional development. We’re working hard to avoid having all male panels at events, and we’ve developed a list of more than 350 women who work within digital and are able to speak at events.

We’re also developing a ‘Digital Voices’ programme initiative to build confidence and engagement skills in women in DWP Digital.

And in June we ran a Women in Digital event, which was open to delegates from across the sector, including cross-government and external private sector representatives.

Normalising, not diversifying

In DWP Digital we’re driving an ethos where a diverse organisation is seen as the norm; where it’s possible for women to be leaders and have our skills valued. One of the biggest hurdles isn’t the technology — its culture.

We’re aspiring to be an inclusive organisation where the outcome is the focus, and to get there we collaborate and develop together regardless of gender, race, sexuality or disability.

Being open and talking about the changes we need to make and why, is the first step, so we’re vocal on social media and through our blogposts. Taking action is the next step, so we’ve set up diversity groups and we have a diversity charter. We’re making sure our recruitment process is fair and that we have mixed panels at interview. We’re engaging our communities by telling our story.

But we know there is still work to do on breaking down the perceptions of digital and technology. We know the words themselves sometimes put women off from considering careers or roles within this area, and now we need to consider what we can do and how we help break down those perceptions. We need to talk more about the non-technology specialist roles, about the skills and characteristics we need within digital. We need to look hard at the language we use and consider how we be more inclusive with the words we use.

Why not check out Digital Leaders’ 2017 Attitudes Survey Results to see the key takeaways about view on Women in Tech.