Monthly Archives: September 2014

Bring your team to the next level

Todays blog post is about improving a team. Or specifically on how can one improve their team. I’ve created this little idea of a workshop together with a friend and good colleague @MMinigshofer

What is a team?

The definition of a Team on wikipedia is the following:

“A team comprises a group of people … linked in a common purpose. Human teams are especially appropriate for conducting tasks that are high in complexity and have many interdependent subtasks.”

But more than that a team consists of people.
And to be successful as a group sooner or later people learn that a group can only be as strong as its weakest member.

Therefore to improve a team the members first need to know one another.

Step 1: Learn more about your teammates

Game number 1 is about learning how your team members “tick”.

The game that you can play to do this is called Moving Motivators. It has been invented by Jurgen Appelo and he kindly made it available for free download.
So what is it all about? You can read it in detail in Jurgen’s blog but in short it will reveal to your team members what motivates you as an individual.
By just doing step 1 of moving motivators and laying down the 10 cards in priority order and explaining to the rest of the team why and what the things are that motivate you the team will gain a much deeper understanding about each other.
Read more and in detail about it in Jurgen’s newest Book: Management 3.0 Workout
I’d suggest to use this game as a warm-up before coming to the real challenge.

Step 2: Finding the weak spots of your team

Everyone wishes to have a team that can do more together as if everyone would be working alone.
This is why in the second game we’ll have a look at the team itself.

The Whole is greater than the sum of it’s parts

So how do we find out?
In his books The five dysfunctions of a team and Overcoming the five dysfunctions of a team Patrick Lencioni describes the basic principles and values behind teams.

And in the workbook he delivers 15 questions that you can go through with a team and answer them with the value per question that you can see in the picture to the right.

Now answering all the questions will yield to something like this:
On the right you see the individual answers summed up for the whole team.

For each answer the sum or average per question can be calculated for later.

With the table to the right all answers of each question can be collected together and combined.

What we want to get is an understanding of how the team is doing in each of 5 levels.
So for Level 1 we count together the sum of all points for questions 4, 6 and 12 and then divide it through the number of team members (in our example 5 people)

This leaves us with a number somewhere between 3 and 9.
Read on to find out what the numbers mean and how we can make sense out of that.

Step 3: Improving the Team

The values that we just collected and calculated are just numbers for the moment.
But we are now able to make sense out of it.
Lencioni gives this guidance:
A score of 8 or 9 indicates that the dysfunction is probably not a problem for your team.
A score of 6 or 7 indicates that the dysfunction could be a problem.
A score of 3 to 5 indicates that the dysfunction needs to be addressed.
The five dysfunctions if you wonder are in priority order:
  1. Absence of Trust
  2. Fear of conflict
  3. Lack of Commitment
  4. Avoidance of Accountability
  5. Inattention to Results
Depending on the points gathered through the questions one should work on the lowest scoring level but beginning with level 1 up until level 5.
Where there is not trust all problems with commitment, accountability and inattention to results cannot be solved.
Try it out with your team, it will give you new insights and might help you to improve.
If it did, let me know how it worked out and leave a comment.
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