The Role of the Product Owner in a Scrum Team

Last week I wrote about the roles and responsibilities of a Developer on the Scrum team. This week is about the Product Owner (often simply referred to as the PO). It’s worth noting that the PO can also be a Developer. However, in my experience the Product Owner is more commonly a non-technical ally for the team, a specialist in the product or the industry.

The PO should not be confused with a Project Manager, that is not their role! A scrum team should be self managing.

The Scrum Guide’s first few words about the PO define their role the most succinctly.

The Product Owner is accountable for maximizing the value

The Scrum Guide 2020

In other words it is the role of the Product Owner to ensure that the Scrum Team are always working on whatever will deliver the most value to the customers and the business. Whether that’s a bug fix, a new feature, or an investigation into upcoming work.

They use Product Goals to avoid this vision becoming too short sighted and reactive, sharing a future state of the product they are working on and working with the Scrum Master and the rest of the team to make that goal a reality.

It is the responsibility of the Product Owner to ensure that the Scrum Team are focused on the most valuable work at any given team.

There are also a few key points around the PO’s role:

  • Should the Sprint Goal become obsolete the PO is the only person with authority to cancel a sprint
  • The PO is a single empowered individual, it is not a committee. Two (or more) POs cannot share a product however the PO can delegate work to other people within the team they remain accountable
  • The business must respect the decisions made by the PO

It is also the Product Owner’s resposibility to understand and articulate the work and make sure that the Acceptance Criteria is well defined and the Product Backlog properly ordered.

It is the Product Owner’s responsibility to communicate the work to the developers so it is clearly understood and can be delivered.

Finally, the Product Owner should always engage with stakeholders to properly understand priorities and requirements. In order to maximise value they must speak with the business and the customers to understand the biggest issues. They must then work with the team to deliver it.

There are a couple of great resources out there for POs if you’re interested. The first is a video by Henrik Knibergwhich gives a great overview of Agile Product Ownership. The second is an article on Scrum.org which discusses the PO’s role in managing and understanding technical debt.

However you cut it the PO’s role is very challenging and includes lots of difficult decisions. Be nice to your PO – create transparency and openness with your point of view and then respect their decisions.

The Role of the Developer in a Scrum Team

Having covered the Scrum Events in recent blog posts I’m going to move onto the three Roles in any Scrum Team. These are Developers, Product Owner, and Scrum Master. This post will be about the Developers, I’ll cover the other two in subsequent posts.

Developer here is a rather broad term. Scrum is most commonly used in the software industry but not exclusively, and as we all know there are many other skills required to build and deliver software than crunching code. For the sake of simplicity The Scrum Guide has termed anyone working to create the product a Developer.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The Scrum Guide 2020

It goes on to explain that the skillsets that the developers will need are wide and varied depending on the domain and nature of the product. For all intents and purposes the “Developer” is anyone who does the work. This could include (but is not limited to) Programmers, Testers, Automation Engineers, Infrastructure Engineers, and UX Experts. From the point of view of Scrum there is no distinction between these roles.

Interestingly the Scrum Master and Product Owner can also be Developers, it’s just that they take on more responsibilities with the additional role.

In Scrum a Developer is anyone who is involved in creating the increment each sprint.

Where the Scrum Guide goes into in more detail is what the developers are accountable for.

Creating a plan for the Sprint, the Sprint Backlog in other words the Developers, as the people doing the work are the ones accountable for creating the plan and Sprint Backlog. This is in stark contrast to more traditional management models where “the boss” creates the plan and assigns work.

Instilling quality by adhering to a Definition of Done the Developers are experts in their domain and professionals. They will create the Defintion of Done with the Product Owner and Stakeholders and hold themselves accountable to adhering to it.

Adapting their plan each day toward the Sprint Goal usually during the Daily Scrum. The Developers will inspect the current progress and adapt if required. They may seek out the Scrum Master or Product Owner if the impediments need to be adapted or if the approach to the Sprint Goal needs to change.

Holding each other accountable as professionals the best teams hold themselves accountable because the end results are important to them. All Scrum Team members should hold each other accountable for their actions and behaviour in a open and respectful manner.

Developers should hold each other accountable as professionals

It’s not easy being a Scrum Developer, a lot is expected of you. However, the experience of working in a team where people respect each other and have the courage to speak up and respectfully challenge ideas and designs is hugely rewarding.

This is why Scrum makes the accountabilities and values of each developer so transparent in it’s guides and resources.

The Retrospective

The Sprint Retro is a key part of any scrum team which is looking to improve its process and adapt its ways of working to continuously improve. As with any adaption the key is transparency, the the more information the team can gather throughout the sprint around impediments or challenges they’ve faced the better. Personally I like to create a retrospective board at the start of a Sprint so team members can add their thoughts to the board as the sprint evolves rather than looking back (which always favours things which happen in the last few days).

The main challenge with the Retrospective is to avoid it turning into a moaning or helpless session. From The Scrum Guide:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Guide 2020

Scrum Masters use a wide variety of techniques to support gathering information about the sprint including anyonmous submissions, “What Went Well vs What Didn’t Go Well”, and often scenarios involving rockets or icebergs. However, it’s important to remember that the Retrospective is a working session to give the team some concrete actions on what they can do to increase either Quality or Effectiveness (or, ideally both). While having a good rant about something which went wrong or something which impeded them can be therapeutic unless an action is taken to lean from that then neither objective should be met.

Teams must look at how to improve and adapt to challenges, not just moan about what got in their way.

This kind of adaption is not easy. It requires teams to look honestly at what’s happened and see what they could have done different, this kind of self assessment takes real courage and for the team to have a real growth mindset. It’s the delicate role of a Scrum Master to balance between criticising what the team should have done and coaching them to look for alternative strategies of what could be done in the future.

Its easy to say that a Sprint Goal failed because X in the infrastructure team. It’s much harder to reflect on what the team could have done to prevent that issue arising. It requires taking acountability and to avoid casting other people as villains.

In earlier versions of The Scrum Guide the team were required to add at least one action to the next Sprint Backlog, however it is now recommended to be properly alongside other work.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Scrum Guide 2020

The Sprint Retrospective requires the three pillars of empirism to be effective however this time they must be focused inward, at what the team could change or could have done differently. It also requires the Scrum Values to be first and foremost in everyone’s mind. Impediments can come from within the team as often as outside it and we rely on our courage and respect to get us through those tough conversations.

Please feel free to post in the comments below of any retropectives which have worked really wel for you in the past, it would be great to read about them.

The Sprint Review

The Sprint Review is an invaluable session to demo progress, engage stakeholders, and discuss what to do next. However, in my experience mist teams don’t take full advantage of the session.

The Scrum Guide says

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

The Scrum Guide 2020

In other words the review is a chance to take a step back and look at the increments which have been completed during the sprint, consider the product goal, and decide the next short term objective.

This should be done in full view of stakeholders, the more transparency the better because this is how we avoid waste and poor quality.

Sharing work with clients and stakeholders is daunting but it’s far better than building the wrong thing.

Personally I’m always worried when I hear teams ask “Do we have anything to demo?”. This often implies to me that they think of the Sprint Review as a presentation of progress rather than a working and planning session. Furthermore, a scrum team should aim to release at least one increment, no matter how small each and every sprint so keep an eye out for these warning signs.

The Scrum Guide reminds us that:

The Sprint Review should never be considered a gate to releasing value.

The Scrum Guide 2020

It is far better to think of the Sprint Review as an opportunity to recap what has recently been completed (if not deployed) and a chance to engage with stakeholders on what should be done next.

Daily Scrum

Last week we talked about the Sprint Planning session, today I’m going to move on to one of my favourite scrum events. The Daily Scrum.

The fifteen minutes each day where the team catch up are some of hte most powerful, but also some of the most woefully misunderstood of all the scrum events.

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Scrum Guide 2020

In other words the entire purpose of those 15 minutes is to review the team’s progress against the Sprint Goal and ensure that they are still on track. They should consider progress, any new information they’ve discovered, and any risks they’ve found and discuss if any change of strategy is required to hit the Sprint Goal.

The Daily Scrum is about verifying progress against the Sprint Goal. Photo by cottonbro on Pexels.com

The Scrum Guide also says

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

The Scrum Guide 2020

However, more than in almost any other event I see zombie scrum going on in Daily Scrums. In team after team, company after company I see teams standing up around a screen answering the dreaded three questions “What Did I Do Yesterday?”, “What Am I Doing Today?” and “Do I have any Impedements?” (by the way – 99% of the time people apparently don’t).

While there’s nothing wrong with this approach there’s something seriously amiss if the team do not circle back to address the main point of the meeting. Given the raw data we’ve captured from the team on their progress and their blockers do we still believe we are capable of meeting the Sprint Goal? Has something someone has said put that in jeopardy and what can the team do adapt.

The Daily Scrum is the daily iteration of the inspect and adapt pillars of empiriscm (which only works if there is a feeling of safety in the team which creates transparency). Instead of simply waiting for their turn to write the three questions developers should be listening to each other’s answers and looking for indication that the team may not meet it’s objectives.

Don’t be afraid to mix up the Daily Scrum format, but do be very nervous if you’re not discussing the Sprint Goal in each and every meeting!

Sprint Planning

Last week we talked about the Sprint. This week we’re going to kick off with Sprint Planning. The Scrum Guide defines Sprint Planning as

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Scrum Guide 2020

It recommends you do this by answering three questions. How is this sprint valuable? What can be done this sprint? How will the work get done?

In my experience most scrum teams by estimating Product Backlog Items, or PBIs (often called User Stories) and estimating how much work they can deliver by looking at their historical velocities.

This, in my opinion is wrong.

When teams do this it’s very easy for them to let the work drive the goals instead of the other way around. Rather than identifying what they want to achieve and working out how to deliver it they look at lots of granular pieces of work and cram as many into the sprint as possible, often losing synergy and coherence in the future.

It is always better for a team to look at what they want to achieve and what the various people can do to make that happen than to try and assign particular tasks to each person. This sometimes means that people’s capacity isn’t 100% utilised. But that time is infested in collaborating, learning, paying down tech debt, and supporting their team mates who are on the critical path. Far better than having everyone so stressed by an arbitrary deadline because some random user story was included in a sprint.

Working out what to include, or not include in a sprint is never easy

A team should always identify the next step forward for their product, the one which would yield the most value and plan the work required to meet that goal. They can use estimates to assess whether a particular plan for doing it is feasible. They shouldn’t focus on trying to fill up a quota of story points from estimates of varying accuracy.

It’s the PBIs which are planned to meet the sprint goal which we will use to verify our progress in the Daily Scrum sessions. This will be the subject of next week’s post so make sure you’re following the blog if you want to read it!

Two “Magic Rules” for Achieving Great Things

Ok, I lie – but it got your attention.

This week I want to talk about the two most important rules you can follow if you want to deliver great work and hit goals. Regardless of whether they’re software projects, books you want to write, or exams you want to pass. They are utterly underwhelming…

Rule 1: Start doing it

Rule 2: Keep doing it until you finish

There you go, I told you they were underwhelming!

However, I want to go a little deeper (otherwise this would be a very short post).

Failure to start is one of the biggest reasons people don’t do things. How many times have you planned to do something one evening only to get home and fail to do it? The reason (according to James Clear in his book Atomic Habits) is because it takes energy and effort to start doing things. Far too often our brains follow a pre-programmed pattern to avoid decision fatigue. Do you want to go running tonight or watch television? What do you need to do to start running? You’ll need to get changed, then you’ll need to find your trainers, then you’ll need to actually do the running… oh, and then there’s the shower. But the TV remote is just there.

In his book James describes ways to reduce the friction required to take on these individual habits and actions and make them easier to do day to day. I do this myself. I want to listen to audiobooks each day, so I leave my headphones by the side of my bed so they’re the first thing I pick up each morning. If you want to go for a run after work then put your kit on your bed before you leave in the morning – or even better put it on before you leave the office so it’ll actually be more effort not to go for a run than it will be to just get out the door!

Photo by mentatdgt on Pexels.com

Once you’ve got started that’s a huge step forward. But a single run doesn’t make you fit. A thousand words doesn’t make a book. So how do you keep that momentum going day after day to make progress until the work is done?

The first step is to understand what “Done” is. Is there a done? If it’s about fitness then you may be looking for a particular weight or time, but you may also be looking to maintain. If you’re building a product you may be looking for a number of active users. Just like in product management and software development we should always be clear about what we want to accomplish before we set off. We can evolve that view, but it helps to act as a beacon.

This leads directly into the motivation question. If we understand our objective we can track our progress towards it. Visibly seeing our progress towards a concrete goal is a very powerful motivational tool (as well as the other benefits of transparency and adaptibility). Burn up charts for your personal goals may seem like overkill, but they’re really not.

Here’s my burn up chart for my reading goal (you can see I actually made the goal far more ambitious because I was doing so well).

You can see I’m doing something similar with my cloud computing exams. This one isn’t going so well, and what am I going to do about it? Revalidate the goal, recalculate the effort and expectations, and then really myself. As with all things agile create transparency, inspect, and adapt.

I know this post started a little tongue in cheek but hopefully it helps and has provided some valuable tools to meet your own goals. Don’t forget, start… and then continue until you are done!

Introducing Donuts and Dragons

After all the positive feedback I recieved writing Code Black last year I’ve been working on something else.

For those who don’t know Code Black is a business parable novel for DevOps techniques. In other words it’s a story, about a team at a failing IT company who embrace modern software development techniques to produce higher quality software in a much more efficient way.

Writing a book is not easy, it’s never turned into a best seller (although who knows, this post may go viral!) but I enjoyed the process and I learned a lot putting it together.

Deciding to push myself once again I’m dusting off my keyboard and writing Donuts and Dragons.

Once again Donuts and Dragons is a story, this time about Megan who joins a team who are working to develop the next best selling game. Instead of DevOps I’m focusing on agile techniques.

I’m publishing the story on LeanPub, the site (in a very agile manner) encourages you to publish early and often. The word count is going up, slowly and steadily as a first draft. As the story is very much in the early stages I’m not charging for anyone who wants to read it and provide feedback.

As I mentioned in my recent goals post, I’m hoping to finish the book in 2021. To do this I’m hoping to have the first draft completed by June and then I’ll have plenty of time to proof read and listen to your feedback. Why not have a look at what I’ve got so far? I’d love to hear your feedback!

Communities of Practice

Many larger companies are following the lead of companies like Spotify’s to create engineer led communities, sometimes called Guilds. The concept is simple, and very good. Creating a cross team culture of engineering excellence to drive best practice forward among employees sounds like a brilliant idea. In this post I’m going to discuss my experience of working with Communities of Practice and my thoughts on their true value.

Companies usually start a CoP initiative when they want to engineers to take ownership of:

  • Defining Standards and Best Practice
  • Training and developing it’s members
  • Breaking down Silos around teams
  • Hiring and building a better team

It sounds great right?

As with most things the reaslity isn’t quite as straightforward as that.

Teams collaborating and self directing through Communities of Practice is a hard, but powerful concept. Photo by Canva Studio on Pexels.com

As anyone who reads my blog may pick up I enjoy a little amateur psychology, I believe it helps me in my role as a team manager. One of the things I’m acutely aware is the tribe mentality of scrum teams, when people get so focused behind their products they often find it difficult to see other teams as allies – too often they’re seen as impediments to deliveries or competing products. Forming a Community of Practice asks people to shift their focus and split it away from their scrum teams to think as a wider team. It can be hard to sit with two hats on!

So, how do you get started?

There’s a very good book by Emily Webber called Building Successful Communities of Practice which outlines a very good approach. She talks about a Community Maturity Model which outlines various objectives the forming community should aim to hit as they grow. By splitting out into distinct Potential, Forming, Maturing, and Self Sustaining phases. It’s important to realise that giving someone a goal and letting them go is not enough to build a Community of Practice.

With CoPs I’ve helped develop it’s crucial to start with a small group of engaged people who set goals and achieve them. Using these successes and achievements as an example to recruit more members and take on more ambitious goals. You can force dozens of people to join a meeting but you won’t get engagement, you want to be able to hold up what the community has achieved, show it off, advertise it, and ask other people if they would help deliver the next goal.

Communities should set their own goals. They need the ability to ask their members what work is needed and the autonomy to be able to go and make it happen. Otherwise they’re simply a vehicle for management to share project work between teams.

Finally, these formative and fragile communities need real organisational support. They need people to have goals set around forming the community, these people need time (I recommend setting the expectation of a day a week out of regular team duties), they also need a discretionary budget. Breakfast, coffee, prizes, and events go a long way to getting people in the door to hear what you want to achieve and once you’ve got them a social budget is a great way to help those cross team relationships form!

If you’ve been involved in Community of Practices or “Guilds” as they’re sometimes known let me know. What advice would you give to someone who wants to form them in their organisation?

Four Types of Work in An Agile World – Revistied

It’s been over three years since I wrote my post Four Types of Work in an Agile World and a lot has changed since then but it is still, by far the most popular post on my blog. I wanted to take a minute to revise the post as I believe things have changed, in the industry in general – not just my head!

When I wrote about this topic originally I described the four types of work introduced by The Phoenix Project as:

  • Planned Work
  • Internal Projects
  • Changes
  • Unplanned Work

I discussed how we used the product backlog to mange the first three and introduced slack into everyone’s sprint and a SWAT team to mop up as much of the Unplanned Work as possible to avoid it jeopardising the planned work.

Over the subsequent years I’ve considered this a little futher. Partially as my knowledge of DevOps and Scrum have grown, but also because – let’s face it, no one wants to be in that SWAT team!

The first change I’d make to The Phoenix Project’s famous 4 types of work is to recognise that in reality all work is either Planned or Unplanned. Internal Projects are a type of Planned Work and Changes are an implementation phase of both. Lets say instead we have:

  • Planned Work
    • Business Projects
    • Internal Projects
  • Unplanned Work
Unplanned Work will always threaten to destroy Planned Work. Photo by Christina Morillo on Pexels.com

Next I’d argue that my previous approach of having a distinct team to shelter the project team is incorrect. It’s another phase of waterfall, splitting different phases of the Develop, Verify, Run into different teams creating silos which don’t talk to each other or share learning. As someone once said – if it’s you getting paged at 3am because the website has crashed you’ll quickly make sure you resolve it in office hours!

Teams must be either orientated around projects or focused on delivering platforms as described in Team Topologies. Those teams must ensure the entire lifecycle from design to operation. To do anything else is to isolate that team from the user and reduce feedback see DevOps 2nd Way).

These teams must also ruthlessly hunt down and eliminate the technical debt which leads to this unplanned work. Creating a buffer team to try to contain the work will only last until lack of feedback and continuously declining quality consume that buffer and overflow back to the development team.

Tech Debt can only be paid down by:

  • Increasing the frequency of deployments (thereby decreasing the delta).
  • Allocating between twenty and thirty percent of the team’s capactity to preventative maintenance and tech debt work.
  • Improving operability and monitoring in production.

Teams have to be utterly ruthless when they resolve issues in production to take action so that they can’t happen again. Or at least that they will be much easier to detect and resolve the next time. Unfortunately, many businesses do not invest the time necessary to maintain their own products. This leads to conflict between the teams and the business and ultimately fails both sides.

This is where it is so important to have your Product Owner on side. I won’t attempt to duplicate many excellent articles on the value of paying down tech debt and having that conversation. I’d only be repeating the words of others. What I would say is that providing meaningful metrics on code quality using tools like StyleCop, Fortify, and SonarQube help quanitify the risk to the business of continuing to operate in this way.

Negotiate the composition of your backlog with your Product Owner. Photo by Tirachard Kumtanom on Pexels.com

If you want to get your Planned Work back on track you need to hunt down and destroy the sources of Unplanned Work (this is not to say you shouldn’t respond to change when it comes along). It means that Unplanned Work is a symptom of technical debt, either in the form of bugs, lack of clarity, or poor operability.

If you want your team to be able to get on with improving your product, you need to ensure that they aren’t getting distracted by people struggling to use it – otherwise you won’t have anyone wanting to use it at all!