×

Tag: Agile

Delivering Digital Government 2019

This week Claire Harrison (Head of Architecture from CQC) and I had the opportunity to attend the Delivering Digital Goverment event run by Worth Systems in The Hague.

The event was focused on how digital has transformed governments across the world, sharing best practices and lessons learned. With speakers from the founding of GDS, like Lord Maude, as well as speakers from the Netherlands, and it was a great opportunity to meet others working on solving problems for users in the Government space wider than the UK.

A lot of the talks, especially by the GDS alum were things I had heard before, but I actually found that reassuring, that over 5 years later I am still doing the right things, and approaching problems in the right way.

It was especially interesting to hear from both Lord Maude, and others, about the work they have been doing with foreign governments, for example in Canada, Peru and Hawaii. The map Andrew Greenway, previous of GDS now from Public Digital, shared of the digital government movement was fantastic to see, and really made me realise how big what we are trying to achieve around the world really is.

@ad_greenway sharing a map of the Digtial Government transformations happening around the world

The talks from some of the Dutch speakers were really interesting. I loved hearing about the approach the council in The Hague are taking to digital innovations, and their soon to be published digital strategy. One of the pilots the city are running in particular intrigued me; in an effort to reduce traffic, they put sensors onto parking spaces in key shopping streets and all disabled parking bays in the city. This gave them real time information on the use of the parking spaces, and where available spaces were and successfully decreased traffic from people driving around searching for spaces. They were now looking at how to scale the pilot an manage the infrastructure and senor data for a ‘smart’ city, working with local business to enable new services to be offered.

The draft digital strategy for the city of The Hague

We also heard about the work the Netherlands has been doing to pilot other innovative digital services, like a new service that allows residents in an area to submit planning ideas to improve their neighbourhoods, with the first trial receiving over 50 suggestions, of those 4 have been chosen to take forward. We heard about the support that was given to enable everyone to take part, and it was nice to hear about the 78 year old resident who’s suggestion came 5th.

It was also great to hear from the speaker from Matthij from Novum, a digital innovation lab in the Netherlands, who talked about his own personal journey into Digital transformation, learning from failures and ensuring that you prepare for failure from the start. He also told us about some fascinating research they have been doing into the use of smart speakers, especially with the elderly, to enable better engagement and use of government services to those that need assistive technologies.

An image of an older lady talking to an AI robot, courtesy of Novum

Realising that 30% of eligible claimants for the Dutch state pension supplement were not claiming it, they believed that this was potentially down to the complexity of the form. They hypothesised that smart speakers might be one way to solve this problem. However recognising that it was no good to make assumptions and design a solution for users without ensuring they had understood the problem their users were facing properly they did a small sample test with elderly users to see whether they could use smart speakers to check the date of their next pension payment (one of the largest contributors to inbound calls to the Sociale Verzekeringsbank), they found that not only could elderly users use the smart speakers, but that the introduction of smart speakers into their homes decreased loneliness dramatically.

There were other good sessions with James Stewart from GDS & Public Digtial on technology within digital, and an interesting panel session at the end. Every session was good, and I learnt something I heard something new at each one. My only grumble from the day was the lack of diversity in the speakers. Which the organises themselves put their hands up and admitted before they were called out on it. A quick call on twitter and the ever amazing Joanne Rewcaslte from DWP shared a list of amazing female speakers, so hopefully that will help with the next event.

One key thing I took away from the day is that the challenges are the same everyone, but the message is also the same, involve users from the start. In the practical steps everyone could start tomorrow, Matthij talked about ensuring you interview 5 end users, and some steps to simple prototypes you could develop to engage your users.

This slide from Lord Maude summed up three of the main things any organisations needs to succeed in delivering Digital Transformation

Lord Maude talked about the importance of a strong mandate, Novum talked about having a good understanding of the problem you are trying to fix at the start. The digital strategy from the Hague highlights the fact they want everyone to be able to participate and deliver a personal service to their citizens. As Andrew Greenaway said, they key thing is to “start with user needs”.

The other second key message from the day was that, as Lord Maude put it… “Just Do it!” A digital strategy delivers nothing, the strategy should be delivery, instead of spending months on developing a digital strategy, “you just have to start” by doing something, this in turn will help you develop your strategy once you understand the problems you are trying to solve, the people you will need, and the set up and way of doing things that works best in your organisation. This was a message reinforced by every speaker throughout the day.

@jystewart sharing a statement from Ivana Osores from Interbank… “You have to just start”

The third key message was the importance of good leadership, good teams and good people. Talk in the open about the failures you’ve made and what you have learned. Build strong multidisciplinary and diverse teams. As Andrew Greenway said, Start with teams, not apps or documents. In the round table discussion on building capability we spent a lot of time discussing the best ways to build capability, and the fact that in order to get good people and be able to keep them, and to go on to develop good things, you need strong leadership that is bought in to the culture you need to deliver.

I left the day with a number of good contacts, had some great conversations, and felt reinvigorated and reassured. Speaking to Worth I know they are aiming to run another event next year, with both an even more diverse international cohort and an equal number of female speakers, and I for one will definitely be signing up again for the next event.

Lord Maude, myself and Claire Harrison at the social gathering after the event

Service Standards for the whole service

How the service standards have evolved over time….

Gov.uk has recently published the new Service Standards for government and public sector agencies to use when developing public facing transactional services.

I’ve previously blogged about why the Service Standards are important in helping us develop services that meet user needs, as such I’ve been following their iteration with interest.

The service standards are a labour of love that have been changed and iterated a couple of time over the last 6 years. The initial digital by default service standard, developed in 2013 by the Government Digital Service, came fully into force in April 2014 for use by all transactional Digital Products being developed within Government; it was a list of 26 standards all Product teams had to meet to be able to deliver digital products to the public. The focus was on creating digital services so good that people preferred to use them, driving up digital completion rates and decreasing costs by moving to digital services. It included making plans for the phasing out of alternative channels and encouraged that any non-digital sections of the service should only be kept where legally required.

A number of fantastic products and services were developed during this time, leading the digital revolution in government, and vastly improving users experience of interacting government. However, these Products and Services were predominantly dubbed ‘shiny front ends’. They had to integrate with clunky back end services, and often featured drop out points from the digital service (like the need for wet signatures) that it was difficult to change. This meant the ‘cost per transaction’ was actually very difficult to calculate; and yet standard 23 insisted all services must publish their cost per transaction as one of the 4 minimum key performance indicators required for the performance platform.

The second iteration of the digital service standard was developed in 2015, it reduced the number of standards services had to meet to 18, and was intended to be more Service focused rather than Product focused, with standard number 10 giving some clarity on how to ‘test the service end to end’. It grouped the standards together into themes to help the flow of the service standard assessments, it also clarified and emphasised a number of the points to help teams develop services that met user needs. While standard 16 still specified you needed a plan for reducing you cost per transaction, it also advised you to calculate how cost effective your non transactional user journeys were and to include the ‘total cost’ which included things like printing, staff costs and fixtures and fittings.

However, as Service design as a methodology began to evolve, the standards were criticised for still being too focused on the digital element of the service. Standard 14 still stated that ‘everyone much be encourage to use the digital service’. There were also a lot of questions about how the non digital elements of a service could be assessed, and the feeling that the standards didn’t cover how large or complicated some services could be.

Paper and Digital

The newest version of the Service standard has been in development since 2017, a lot of thought and work has gone into the new standard, and a number of good blogs have been written about the process the team have gone through to update them. As a member of some of the early conversations and workshops about the new standards I’ve been eagerly awaiting their arrival.

While the standards still specifically focus on public facing transactional services, they have specially be designed for full end to end services, covering all channels users might use to engage with a service. There are now 14 standards, but the focus is now much wider than ‘Digital’ as is highlighted by the fact the word Digital has been removed from the title!

Standard number 2 highlights this new holistic focus, acknowledging the problems users face with fragmented services. Which is now complimented by Standard number 3 that specifics that you must provide a joined up experience that meets all user needs across all channels. While the requirement to measure your cost per transaction and digital take up is still there for central government departments, it’s no longer the focus, instead the focus of standard 10 is now on identifying metrics that will indicate how well the services is solving the problem it’s meant to solve.

For all the changes, one thing has remained the same thorough out, the first standard upon which the principles of transformation in the public sector are built; understand the needs of your users.

Apparently the new standards are being rolled out for Products and Services entering Discovery after the 30th of June 2019, and I for one I’m looking forward to using them.

Launch!

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.

What is the role of Business Analysts within agile?

Analysisng the role of the Business Analyst.

When we were looking at the Digital, Data and Technology (DDaT) roles and capabilities back in 2016, one of the roles we really struggled with was the role of the Business Analyst (BA).

Not because we didn’t agree that it was a role (because we absolutely did) but because we struggled to define the scope of the role in comparison to things like; Product Management, Design or User Research roles.

It’s one of the questions, that three years later still comes around regularly. Who is responsible for defining the requirements? What is the role of the BA?

Who holds the requirments?

The role of the BA in an agile team

One of the problems we had back when we were defining the BA role as part of the DDaT professions, was that the Government Digital Service didn’t have BA’s in their teams. Similarly, the original Scrum Manifesto only has 3 roles in an agile team, the product owner, development team members and scrum master.

Because traditionally, the BA acted as the link between the business units and IT, helping to discover the requirements and the solution to address them; when multidisciplinary teams bought those members together the role of the BA became less clear.

This has meant when adopting agile, different government departments implemented the role in slightly different ways. The biggest trap I have seen teams fall into was the BA getting stuck with all the admin roles for the project.

Roman Pilcher argued for those BA’s moving into Scrum there were two options, becoming the Product Owner, or becoming a ‘team member’.

While I agree that Business Analysts are a key member of a multidisciplinary team, I disagree with this assumption that everyone on an agile team who isn’t the scrum master or the PO is simply ‘a team member’ I think the Business Analyst is a critical role (especially for Product Managers!) that brings unique skills to the team.

So, first things first let’s look at what requirements are in the agile space.

Certainly, within digital government at least, we use a user centric design approach. We are developing products and services that fix the problems that our users are facing. We are identifying user needs and testing and iterating those throughout the product development lifecycle. A lot of the time this conversation about ‘user needs’ has replaced the more traditional conversations about ‘requirements’. Which is good in some ways, but has also led to a bit of confusion about what Business Analysts do if it’s not gathering requirements. Who owns the requirements now?

Are user researchers responsible for gathering the requirements from external users (user needs), whereas Business Analysts are responsible for gathering requirements based on what the business needs (sometimes called business user needs)?

That line of conversation worries me, because it suggests that we don’t need to carry out user research on internal staff, it forgets that internal staff are users too.

So, what is the role of the BA?

In my experience the conversation about who is responsible for gathering requirements is symptamatic of the limitations of the English language, and our obsession with ‘ownership’.

User researchers primarily focus on gathering more qualitative data; why users behave the way they do, how things are making them feel; probing their views and opinions to understand what it is they actually need etc. They will help understand who they users are and verify what the users need. They will work with the team to test design assumptions and help ensure the options being developed meet user needs.

Business Analysis primarily focus on gathering the more quantitative data about the process; both the ‘as is’ process, and the future process we are designing. They work to understand how many users are being or will be affected? What are the cost/time impacts of the problem as identified? What value could be gained through the implementation of any of the options the team are considering?

They help identify the stakeholders that will need to be engaged, and how to best engage with them. They will turn the user needs into user stories that the team can develop and identify the metrics and success criteria for the team to help them measure value.

Where you have a Product or Service that is live and being used by real users, the BA will work with Performance Analysts to understand the feedback data coming from the users.

User Researchers and Business Analysts will often work closely together, while BA’s will use tools like process mapping to identify pain points, user researchers will work with them to map the emotions users are experiencing so that we can fully understand the impact of our current processes and the value we can release by fixing the problem. When User Researchers are planning in research sessions etc., they will often work with BA’s to get the data on where best to test in terms of locations or user groups.

Good Product Managers will use both the Quantitative and Qualitative data to help them pick which options to test. Designers will help both the user researchers and business analysts look at the data and design prototypes etc. to test with users.

For me, each role is clear in its scope, and their need to work together to identify the right problems users are facing and the best way to test those; and it’s not about what individual owns the requirements, because the answer is the team do.

Round and round we go.

In other words Agile isn’t linear so stop making it look like it is.

Most people within the public sector who work in Digital transformation have seen the GDS version of the Alpha lifecycle:

Which aims to demonstrate that developing services starts with user needs, and that projects will move from Discovery to Live, with iterations at each stage of the lifecycle.

The problem with this image of Agile is that it still makes the development of Products and Services seem linear, which it very rarely is. Most Products and Services I know, certainly the big complex ones, will need several cracks at a Discovery. They move into Alpha and then back to Discovery. They may get to Beta, stop and then start again. The more we move to a Service Design mentality, and approach problems holistically, the more complex we realise they are, and this means developing Products and Services that meet user needs is very rarely as simple and straightforward as the GDS Lifecycle makes it appear.

And this is fine, one of the core principles of Agile is failing fast. Stopping things rather than carrying on regardless. We iterate our Products and Services because we realise there is more to learn. More to Discover.

The problem is, especially in organisations new to Agile and the GDS way of working, they see the above image, and its more linear portrayal seems familiar and understandable to them, because they are generally user to Waterfall projects which are linear. So when something doesn’t move from Alpha to Beta, when it needs to go back into Discovery they see that as a failure of the team, of the Project. Sometimes it is, but more not always, sometimes the team have done exactly what they were meant to do, they realised the problem identified at the start wasn’t the right problem to fix because they have tested assumptions and learned from their research. This is what we want them to do.

The second problem with the image put forward in the GDS lifecycle is that it doesn’t demonstrate how additional features are added. The principle of Agile is getting the smallest usable bit of your Product or Service out and being used by users as soon as you can, the minimum viable product (MVP), and this is right. But once you have your MVP live what then? The Service Manual talks about keeping iterating in Live, but if your Product or Service is large or complex, then your MVP might just be for one of your user groups, and now you need to develop the rest. So what do you do? Do you go back into Discovery for the next user segment (ideally, if you need to yes), but the GDS lifecycle doesn’t show that.

As such, again for those organisations new to Agile, they don’t’ factor that in to their business cases, it’s not within the expectations of the stakeholders, and this is where Projects end up with bloated scopes and get stuck forever in Discovery or Alpha because the Project is too big to deliver.

With Public Services being developed to the Digital Service Standards set by GDS, we need a version of the lifecycle that breaks that linear mindset and helps everyone understand that within an Ariel project you will go around and around the lifecycle and back and forwards several times before you are done.

Agile is not a sprint, a race, or a marathon, it’s a game of snakes and ladders. You can get off, go back to the start or go back a phase or two if you need to. You win when all your user needs are met, but as user needs can change over time, you have to keep your eye on the board, and you only really stop playing once you decommission your Product or Service!


Speak Agile To Me:

I have blogged about some of these elsewhere, but a quick glossary of terms that you might hear when talking Agile or Digital Transformation.

Agile: A change methodology, focusing on delivering value as early as possible, iterating and testing regularly.

Waterfall: A Change methodology, focusing on a linear lifecycle delivering a project based on requirements gathered upfront.

Scrum: A type of Agile, based on daily communication and the flexible iteration of plans that are carried out in short timeboxes of work.

Kanban: A type of Agile, based on limiting throughput and the amount of work in progress.

The Agile Lifecycle: Similar to other change methodology lifecycles, the agile lifecycle is the stages a project has to go through. Unlike other lifecycles, agile is not a linear process, and products or services may go around the agile lifecycle several times before they are decommissioned.

Discovery: The first stage of the agile lifecycle, all about understanding who your users are; what they need and the problem you are trying to fix. Developing assumptions and hypothesis. Identifying a MVP that you think will fix the problem you have identified. Prioritising your user needs and
turning them into epic user stories.Akin to the requirements gathering stage in Waterfall.

Alpha: The design and development stage. Building prototypes of your service and testing it with your users. Breaking user needs and Epics into user stories and prioritising them. Identifying risks and issues understanding the architecture and infrastructure you will need prior to build. Akin to the design and implementation stage in Waterfall.

Beta: The build and test stage. Building a working version of your service. Ensuring your service is accessible, secure and scalable. Improving the service based on user feedback, measuring the impact of your service or product on the problem you were trying to fix. Can feature Private and Public Beta. Akin to the Testing and development stage in Waterfall.

Private Beta: Testing with a restricted number of users. A limited test. Users can be invited to user the service or limited by geographical region etc.

Public Beta: A product still in test phase but open to a wider audience, users are no longer invited in, but should be aware they product is still in test phase.

Live: Once you know your service meets all the user needs identified within your MVP, you are sure it is accessible, secure and scalable, and you have a clear plan to keep iterating and supporting it then you can go live. Akin to the Maintenance stage in Waterfall.

MVP: The Minimum Viable Product, the smallest releasable product with just enough features to meet user needs, and to provide feedback for future product development.

User Needs: The things your users need, evidenced by user research and testing. Akin to business requirements in Waterfall and other methodologies.

GDS: Government Digital Services, part of the Cabinet Office, leading digital transformation for Government, setting the Digital Service Standard that all Government Departments must meet when developing digital products and services.

The Digital Service Standards: https://www.gov.uk/service-manual/service-standard 18 standards all government digital services should meet when developing products and services.

Service Design: Looking at your Product or Service holistically, keeping it user focused while ensuring it aligns with your organisation strategy.

User Centric Design (UCD): The principles of user centric design are very simple, that you keep the users (both internal and external) at the heart of everything you do. This means involving users in the design process, rather than using ‘proxy’ users (people acting like users), you involve actual users throughout the design and development process. Recognising different users (and user groups) have different needs and that the best way to design services that meet those needs is to keep engaging with the users.

Theme vs. Epic vs. Feature vs. Component vs. Story

Probably the question I get most (after what is Product Management, and what is the difference between a Product Manager/ Product Owner/ Delivery Manger)… ok so the third most common question I get asked is “what I mean by Epic/ Theme/ Feature, Componant or Story, what is the difference?”

And given I get asked it so regularly I thought it was worth sticking my thoughts down in a blog, so that I can call upon it in the future for reference, but also so I can understand whether I’m using them differently to others.

Theme:

When I tall about a theme, I mean something like Accessibility. It weaves through pretty much all stories as a thing we need to consider, will be key in multiple epics, but is not a deliverable ‘chunk’ of stuff on its own.

Epic:

When I’m talking about Epics I’m talking about things like Payments. These are tied generally to a specific outcome or high level user need or part of the journey or process someone takes in using the service. “As a business I want to be able to pay my staff so that they are remunerated for their work” for example. All the stories within an epic are related to delivering that outcome, the stories collected in an epic deliver value together, but the Epic is too big to do in one sprint. An Epic may be made up of several Features, or it may not. If it contains several Features you may prioritise all the “must have” stories from the epic to deliver together, and come back to the “should’s and could’s” later. Or you may save up the stories to deliver all the stories together in one larger release.

Features and Components:

Sticking with the Payments analogy, given the scope of that Epic is large, it would probably contain several features and componants. a Feature would be something like your payments engine, a collection of stories you have to develop and deliver together to release value, whereas a Componant is generally something you can plug in like Bank Wizard. Neither of these things deliver the full outcome required, which is why they are not an Epic.

Just because you can physically pay someone doesn’t mean you can calculate the right payment for example, there will be other stories to allow you do that, all of those stories would sit within the Payments epic as you need them to meet the outcome you’re looking for, but would be developed separately to your payments engine or allowing you to plug in bank wizard.

Finally there are the stories and tasks that are fundamental to delivering everything:

Stories are the individual bits of ‘stuff’ you are trying to deliver. And the tasks are the actions you will undertake to deliver the story. So “as a manager I want to stop payments to members of staff who have left the business so that I’m not paying the wrong people” is a (terrible, sorry) story. It would still sit within the Payments epic, could possibly be part of a feature, but it meets an individual user need. The story would need to meet accessibility criteria, and there are several tasks you’d have to do to deliver it, develop a prototype or speak to stakeholders etc.

Originally posted on Medium

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