Category Archives: Agile + Lean

Your first Sprint as a Product Owner

Scrum is getting more and more popular. And one role that doesn’t get too much attention is actually one of the hardest in my eyes. The Product Owner.

This blog is dedicated to help professionals grow their skills as Product Owners or start to become one. It is driven from experience of working more than 5 years as a Scrum Master together with Product Owners and being one myself fore more than 1 year. If you came here as reader of my old blog better change your bookmark since this will be the new address where I’ll provide you with content from now on. Together with my 2 partners in Oikosofy Vasco Duarte and Luis Goncalves we’re providing you with everything that you’ll need in your venture to become Agile, Lean and create products that matter and delight your customers.

Who is this for?

You’re brand new in the role of Product Owner or you’re planning to become one in the near future? Then this is for you. It also helps people new to Scrum to understand better what the role of the Product Owner includes and how what a Product Owner does in reality.

  • Product Owners
  • Scrum Masters
  • Leaders looking to use Scrum for their organisation
  • Anyone interested in getting insights to the role of Product Owners

ProductOwnerTeamStakeholders

Assumptions

For this rough recipe the following assumptions are used:

Sprint length: 2 weeks
Testing: mainly done manually
Team: collocated in one room
Stakeholders: All in the same location and country
Backlog: The product backlog is already in place and filled
Planning: A roadmap reflecting the current and upcoming sprints exists

In the next part I’ll describe some of the major Scrum activities as well as the specific Product Owner duties and activities. This is an exemplary list and kind of “by the book”. You’ll rarely find a Product Owner doing all these activities. But if you start doing it you should aim high, no?


Your very first Sprint as Product Owner

Day 1 – Sprint Planning

The Sprint always starts with the Sprint Planning. The Product Owner brings along the Stories that she has prepared beforehand and ordered in terms of criticality and business value to present it to the team and then together collaboratively create the Sprint Backlog. Depending on the preparation this can last from as short as 20-30 minutes to 2-3 hours (for a 2 week sprint).
The goal is to have a common understanding of the Sprint Goal, the scope of the sprint backlog defined, the Stories well understood by the team and Acceptance Criteria defined to be used at the end of the Sprint for the Sprint Review.

  • Set the sprint goal
  • Motivate and engage the team for a challenging yet doable Sprint

Day 2

  • working with Stakeholders to update Release planning and Roadmap
  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 3

  • working with Stakeholders to update Release planning and Roadmap
  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 4

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • working on the Product Backlog to prepare the PBR

Day 5

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • finishing the preparation for the PBR to fulfil the Definition of Ready

Day 6 – Product Backlog Refinement

In the Product Backlog Refinement the Product Owner and the team can clarify upcoming topics. These could be epics or features that haven’t been further analysed and need clarification. The Product Backlog Refinement is a good occasion to break Features down to Stories and add useful information to the Stories.

  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 7

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • clarifying open questions from the PBR in preparation of the Planning

Day 8

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • clarifying open questions from the PBR in preparation of the Planning
  • working on the Product Backlog in preparation for the Planning
  • negotiating priorities for the Product Backlog with stakeholders
  • updating Release Plan and Roadmap with stakeholders

Day 9

  • answering questions of the team
  • clarifying open questions from the PBR in preparation of the Planning
  • working on the Product Backlog in preparation for the Planning
  • negotiating priorities for the Product Backlog with stakeholders
  • updating Release Plan and Roadmap with stakeholders

Day 10 – Sprint Review

In the Sprint Review the Committed Sprint Backlog will be reviewed in the form of running tested software. The Product Owner and team will check if the agreed Definition of Done is fulfilled for each Story and will reject Stories that don’t fulfil it.
The Sprint Review is an open event that everyone can join and especially real end customers can and should take part in it if possible.
The Product Owner as spokesman for the customers will decide what’s finished and can be released to the public and what not.

  • Celebrate with the team
  • Thank the team and give them a small pause to do the Retrospective and recharge batteries

What next?

This is an exemplary schedule of a Product Owner.
A Product Owner should always aim to have exactly the availability that the team needs to answer questions or review work in progress. Every hour that can be saved for reworking Stories that weren’t finished as “intended” during the Sprint is a big saving compared to do it after the sprint.

Managing the Stakeholders is a difficult task. Especially balancing the time used for meetings with stakeholders versus working with the development team. If you can get this right, you’re set up for success. Many Product Owners that I’ve worked with were swamped with meetings trying to please all stakeholders and left the teams alone during the Sprint. This is an anti-pattern that should be avoided.

If you liked this post sign up for more.
This blog will be a source mainly for Product Owners and related topics.
In future posts I’ll dig deeper in what you saw under Assumptions. E.g. creating your first Product Backlog and how to do regular Roadmap updates and Release planning.
In case you don’t want to miss out on that, sign up.

Sven Schnee

The 5 Pillars of an Agile Change Initiative

Hi there,

 

there are many reasons for changing to Agile or Lean ways of working. Keeping up with the competitors, huge problems in quality or maybe even doing it right from the beginning?

One thing that good consultants will be able to tell you is: it’s not about the methodology that you choose. This can be a factor but won’t be key to success.

So what do you have to do, what is it you have to consider?

Pillars of Justice
Pillars of Justice – Hindrik Sijens – flickr

  1. Methodology
  2. All-level management support & understanding
  3. The right setup
  4. Honest Feedback culture
  5. Continuous Improvement

I call these the 5 pillars. But before we go into detail about them, I’ll first describe you what happens to many of the unsuccessful agile adoptions. They focus on methodology. And methodology only.

1. Methodology

Step 1 – Choosing

It normally all starts with certain pain points that need to be addressed.

  • Quality is not sufficient
  • Delivery speed is not high enough
  • Architecture is “broken” and the software no longer extensible
  • Projects take too long don’t get finished and cost too much
After that the next step often is to choose a “silver bullet” to solve the problem.
E.g. Scrum as the “new project management framework”. Which it is not. It’s an empirical process improvement framework in reality which is a completely different thing.
Now with the Silver Bullet in their hands next thing

Step 2 – Adjusting

Trying to fit the Methodology to the status quo.
Whatever feels uncomfortable will not be taken over in the new methodology, the parts that fit the current environment will be adapted.
In the Scrum environment that often leads to teams doing Daily Scrums but no Retrospectives.
And Testing + Reviews are done at the end of the sprint instead of continuously and automated. This is called Mini-Waterfalls.

Step 3 – Depression

Partial or complete failure. Putting blame on the Methodology as not fitting and not solving the problems.
Why is that a quite common scenario?
Is it because the wrong methodology was chosen?
Would XP be a better solution than Scrum?
Isn’t Kanban much better than Scrum in certain situations?

Systems thinking is needed

Whatever methodology you choose, if you don’t address the pain points that brought you to your change initiative it will be fruitless.
This typically requires systems thinking:
  • looking at the big picture
  • visualising what is going on for the whole and it’s parts
  • fixing structural problems
  • having people who can see the whole instead of the small little cogwheels
  • e.g. identifying the testing problem and changing the whole testing approach
Methodologies alone are useless.
You might have heard the saying”a fool with a tool is still a fool”, this is similar.

2. Management support & understanding

This point is somehow obvious, since for any initiative you’ll basically need management’s support to get started. They need to provide budget to get Agile Coaching on board or simple give your team enough time to start learning on how to do Scrum and test automation.

But this is by far not enough to succeed.

Start by coaching the Management

The senior and middle management can be the single point of failure for any change initiative.
That’s why the change initiative should make management the engine of change.
First of all all levels of management need to understand how the future state should look like and why things will work better. They need to be the ones driving the change and working with their people, the Coaches should aim to educate them so that they’re enabled to do it.
This is not fast and it is not easy. Understanding concepts like Agile and Lean takes time and hard work. Reading books, working with it, participating in communities.
Nonetheless it’s essential. Someone who doesn’t understand or know the How and Why will inevitably take decisions that will block or negate the whole initiative.

Management Support

Now that the management is on board they can ensure:
  • Impediments that affect the whole organisation are worked on by upper management
  • structural changes that affect personell hierarchies can be done
  • that strategical decisions resulting out of insights gained in the change initiative will be better informed and faster

3. The right setup

Did you ever try to explain a concept like cross functional teams to someone that has either no clue of software development or worked in silos for 10-15 years? In either case it’s difficult. That’s why management needs to understand first how it can and should work. Only then will they support structural changes. And only if they know or learn what systems thinking is and how to apply it will they be able to take the right actions.
The organisation should be built around the value flow. Using tools like Value Stream Mapping and Kaizen Management will be able to change the structures where needed.
Changing organisational structure is a painful and costly process, which leads us to the next pillar.

4. Honest feedback culture

When organisations are changed to improve value flow this often results in roles or whole departments to get redundant. Especially for all people that are affected by this change it’s utterly important to get positive feedback and another role or position in case they are doing a good job.
And then there are those that didn’t really do a good job. It’s also important to be honest and transparent with those people, especially if there is no other role that they could fulfil in the new setup.
Let me give you an example to understand this better.
In Scrum a full team consists of Product Owner, Scrum Master and Team Members.
There are no hierarchies between the people. Everyone is equal.
Before you could have had a setup like: Product Manager, Project Manager, Team Lead, Developers, Testers. Product and Project Managers were telling others what to do, Developers were looking down to testers.
All the hierarchies and reporting lines that existed in the previous team setup will be eradicated with the introduction of Scrum.
This is especially important for all the middle management like Team Leads and Department Leads. They will need to be mentors and Servant Leaders in the new setup which is not compatible with a Command and Control mindset. So better be open and honest with them and go separate ways early instead of having them corrupt the change initiative. Identify and support all the Servant Leaders because those will help tremendously.
Which leads us to the most difficult and basically the only thing that will help you to succeed.

5. Continuous Improvement

Another word for Continous Improvement is Kaizen. This results out of Toyota Production System which was the start for the Lean movement.

Kaizen on Wikipedia: “When used in the business sense and applied to the workplace, kaizen refers to activities that continually improve all functions and involve all employees from the CEO to the assembly line workers.”

That’s exactly the idea.
  • Resolve problems immediately
  • Actively work to remove impediments
  • Never accept the status quo always strive to improve
  • built quality into all steps of the value chain
  • Aim for the impossible to achieve greatness
Not having a continuous improvement cycle will kill all change initiatives sooner or later.
It’s like doing Scrum without having Retrospectives. This is taking away the insights and learning part and makes it almost impossible to improve.
Combining all the pillars together leads you to this:
As you can see everything is building on each other and still the pyramid is upside down to visualise that continuous improvement is the key to success but won’t really work if you don’t have the rest.

In my experience Step 1 is done right by most companies.
Unfortunately Step 2-5 are barely executed by all those companies trying to get better.

Key to success is having all 5 Pillars in place or at least worked on. Any such initiative takes 2-5 or more years depending on the size of the company. If you’re struggling with getting any of the pillars in place get in touch with me or any of the other coaches of Oikosofy. You’ll find us at www.oikosofy.com
A good start could be to attend the Scrum Master Toolbox webinar. This is done by my appreciated  partners Vasco Duarte and Luis Goncalves. (@duarte_vasco@lgoncalves1979)

If you liked this blog post please share it with your friends or colleagues who might be interested.
You can also follow me on Twitter @MrSnow76 to get updated when I publish new blog posts.

Thx for reading,
Sven Schnee aka MrSnow76

10 Myths about POs

Hi dear readers,

today I want to share some of my latest experiences with you.
Right now I’m not helping teams to improve but I am the PO for a team.
Normally I’m working as a Scrum Master together and for a team and the PO is “on the other side”.
So being on the other side opens your eyes for a completely new perspective.

So here are the Ten Myths about POs that I hear and feel every day, when working as a PO.

Ten Myths about Product Owners

1. POs are writing stories and detail out everything the team needs

Either as a Scrum Master or a PO you most likely have heard the following in a Retrospective or on another occasion:
  • Requirements are not detailed enough, we don’t know what to do
  • Acceptance criteria are not clear
  • Stories are poorly written
  • We don’t know what to do
So, here’s the hard truth. If you expect a specification in the form of a user story that will help you switch your brain off and just do checklist coding, Scrum and Agile is not for you.

2. POs are working on the backlog 90% of their time and use the rest for Scrum Meetings

The product owner is the one who knows exactly what she wants and will formulate that as precise and crystal clear prioritised list of Backlog items.
Once a product owner is not meeting with the Scrum team in a Planning or PBR session or answering their questions she’s sitting at her computer to write stories and keep the backlog in shape.
Bad news is, there is much more about creating  a product than only writing stories and dealing with questions of the teams.
  • stakeholders want their attention and they will constantly want to change priorities and do exactly the opposite of what they wanted 2 weeks before
  • having different stakeholders with separate agendas will put the PO in a mediator role between them to find compromises that everyone can live with in the form of priorities
  • customers need to be involved in the feedback loop and their feedback needs to be heard and transformed into something useful for the team

3. POs are available for the team all the time

So the theory is that a PO should always be there for the team to answer their questions. The team is the one delivering what the PO wants so it’s only fair that they have her for dealing with questions, whenever they need.

Well in practice I normally see the exact opposite:

  • PO being rarely available for the team and mostly in meetings
  • POs that have more than one team often 2-3 and by this most of the time in Scrum Meetings with little or no time in between them to do anything important like talking with the team or working on the backlog

4. POs know everything about their product

Since she is the owner of the product, she has to know exactly what she wants. And she’ll be able to express that without the need to ask any questions.
New functionalities can be explained by the PO in a way that stories are only a small reminder of what needs to be done and to check after the implementation that nothing was forgotten.

On the contrary.
Often the PO will be able to tell what user value is at the end of an idea, but the way there is the same adventure for him like it is for the team.
The PO can be lost if the team doesn’t help with:

  • doing spikes and prototypes to get rid of uncertainty
  • requirements analysis, discussing the HOW of the story
  • wireframes, quick design sessions, whatever helps to get a good understanding about how to get the idea to life

5. POs are evil guys that stress teams to the max for delivery

Well, sorry this one is true.

6. POs and Scrum Masters are enemies by nature

Since the PO always will ask for a higher velocity the Scrum Master will always have to protect the team and tell them to go where the sun doesn’t shine.

What I’ve seen in reality is that both of the above don’t have to become reality, if the Scrum Master does a good job of coaching the PO. Having good practices to find out the highest business value and the right priorities will actually lower the stress on the team and make the PO’s and Scrum Master’s life easier.
But then there are these myths about bad scrum masters. But that’s a different story.

7. POs know how to be visionaries and guiding teams

Before a new product development is started there will be a ceremony. It’s called the vision gathering.
The PO will hold a speech in front of all the company alluring them with a sweet voice and painting wonderful pictures in their minds about the glorious future.
Well, how many real visionaries did you see so far around you?
This is by far the one thing I’m waiting to see in a PO.

8. POs are not needed, the team can do that completely alone

More and more teams in my surroundings don’t have dedicated POs.
Well a team CAN do without a PO, this is without a doubt. It’s like having a car without a driver. If the driver jumps out the car will move on for some time. With cruise control it will even keep the speed, but just wait for the first bend in the road.

Whenever I see a team without a PO I ask them to get one. Either from inside the team, from the customer, wherever it makes sense. Doing this on the side can work somehow for a small amount of time but not taking the role serious is a severe mistake that will strike back heavily.

9. POs are Masters in Agile Release Planning

Every PO knows how to do a Release Plan. They are used to techniques like Story Mapping, defining Minimum Operable Feature Sets and constantly updating the roadmap to help the team keep the big picture.

Most of the POs I’ve seen so far are able to get the idea of Stories. Talking about Epics and Features and creating a continuously update release plan confuses most of them.
If they are not young and open to new ideas but have “old ways” of working still memorised trying to put everything in a giant backlog and getting numbers on all the parts of the checklist will be the preferred way to go.

10. POs are Managing a Risk List and update it constantly

Each feature has a risk indicator showing how hard it is to implement and how likely the effort that was estimated will meet the initial numbers. Since there are no longer Project Mangers in Agile environments the PO will also keep a list of non product related risks together with mitigation strategies. Cost of Delay will show how much a delay per day or week of a feature will cost.

If you ever had a PO doing that, please put me in contact with them. I’d like to get to know them 🙂

To be a PO is a really hard job and involves much more than writing stories and order some post-its on a wall. So tomorrow if you go to work ask yourself how you can help to create a great product.
It is and always will be a joint effort. Get your hands dirty and support the product owners.
They are not evil