Tag: Scrum

Your position as a “project manager”

Many project managers will be reluctant to introduce Scrum, at first. Scrum knows no project management role. That role is divided over the three only roles that Scrum knows: The Product Owner, the Scrum Master and the (*drops the bomb*: self-managing) Scrum team.

So if there is no place for a project manager, then what happens to me as a project manager? That completely depends on the organisation, the sizes of the project(s) and the size and workload on the team. It could well be that you become the Scrum Master, guiding the team and organisation to adopt (and adept) Scrum as good as possible and guiding the Product Owners to become and stay Product Owners. Perhaps you become the Product Owner, the organisation’s central point for feedback and feature requests – maintaining all those on a backlog for the team to pick up.

No place for (micro)management. Scrum centralises the individual and the team, they are leading when it comes to deciding what can and what can’t be picked up during this sprint. The team decides what they can and want to commit to. That said, the Product Owner decides which stories on the backlog are priority. The Product Owner makes sure that the stories are complete enough for the development team to pick them up (refinement) (note: the Scrum Master should facilitate and support this process). This is also why it is important that the Product Owner is present at the sprint planning meeting, if and when developers have any questions about a certain story, the Product Owner will be able to clarify and explain and the Product Owner will know if and why a certain story does not get picked up.

The shift to Scrum makes you, a facilitator, as a former project manager. That’s a fact, it doesn’t matter wether you become a Scrum Master or a Product Owner within your organisation. Becoming a facilitator is something that is natural to most project managers, as most project managers already apply basic principals that often function as starting points for the shift in role(s).

Facilitating instead of dictating gives the team power which ultimately leads to better results. The team feels responsible for their commitment and delivery, as they should. You’re not ‘lesser’ for becoming a facilitator. Managing and delivering products and projects has always been a teamgame, the project manager has always been a part of that team, not the leader of that team. Scrum just emphasises that.

 

 

A good retrospective

Retrospectives are awesome and should be fun – game your way through! I use a combination of a few strategies (games) to make my (our) retrospectives work. Developers tend to be closed personalities and are mostly not interested or aimed at processes (and the improvement of those). The problem is that they are your main input for what the retrospective stands for: improving your scrum processes.

No matter how good a Scrum team is, there is always opportunity to improve. Although a good Scrum team will be constantly looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doing and to find ways to improve. This occurs during the sprint retrospective.

The games that I’ve learned to use during my career that seemed most valuable and usable (there are a million ways and games out there, gather and use them – by trial and error).

The main goal is to set an environment for your team in which they feel safe, trusted and open to share. An environment where the individuals that make the team feel that their feelings are respected and most definitely an environment in which the team can deal with the issues at hand. Those issues can be process-wise, personal or perhaps even Product Owner, Scrum Master or Stake-Holder related. Any issue with Scrum in general should be spoken of, because they are (potential) roadblocks in an effective and good Scrum.

One-score
To start the meeting easy and gentle I ask all team members to individually score their feeling for this sprint. They write their score (1-10) down on a sticky note. Gather those and put them up on the whiteboard (in order). Don’t analyse the scores yet – just briefly notice if the scores defer much, or if they are rather close to each other. Make sure that your team understands that it’s important to be honest. 

What I tend to do (to make the results of this first exercise clearer) is split the whiteboard up into 4 columns (we’ll reuse those later). The column values are (in my case):

  • Super (9-10) 
  • Good (7-8)
  • Alright (5-6)
  • Negative (1-4)

Doing the above (stick the notes in the appropriate column) gives you a very clear ‘mapping’ of feelings. It helps your team members to get their thoughts and feelings in one line (before we start the other games). 

One-word retrospective
This one boils down to practically the same as the above. Ask your team members to write down how they feel about the last iteration (sprint) in one word. Gather the sticky notes and stick them in the appropriate columns. By now they should be filled up with two sticky notes per team member, one with a number and one with a word. 

 Some people set “real feelings” as boundary; the word written down has to be a real feeling (like, love, hate, cry, fear, etc). I try to leave it free. There’s a game called ‘Car Brands’ where a team literally writes down the car brand that best fits their feeling for a certain sprint (I love that one). 

I usually try to leave it up to the team (leaves more wiggle and negotiation room in the next games); they can write down any word (as long as they will be able to explain it later).

 As an alternative to this game you could have your team draw something (get them out of their chairs and make them draw something on the back of the board (just get the blood flowing a bit and make your team actively take part of the meeting) 

Asking Questions
A quick and relatively easy way to get a bit deeper into the problems (after the other exercises) is ask the team “the four key questions” (Norman Kerth). Those questions are as follows:

  • What did we do well, that if we don’t discuss we forget? (Super)
  • What did we learn? (Good)
  • What should we do differently next time? (Alright)
  • What still puzzles us? (Negative)

The goal with those four simple questions is to urge the team to look for things they would like to change.

This game is open, the Scrum Master writes down the responses of the team to each question (try to get as many answers as possible per question). Write them down and stick them in the appropriate lane answers to question 1 go into the ’Super’ lane, answers to question 2 go into the ‘good’ lane, answers to question 3 go into the ‘alright’ lane and answers to question 4 go into the ’negative’ lane (see any correlation there? ;o)

Evaluation
This is the part where we get to the actual core, the FUN part, the part where we (as a team) decide what is going to change and how! 

1 – Start by going over the scores that the team have given the previous sprint. Don’t go deep yet, just see if they match with the outcomes of the other two games – no need for more depth yet, we’ll get to that in a bit. I like to check two things:

    • Check if the scores that were given are close to each other, if they are.. well done! ;o You have a team that is well aligned and thinks the same! (be sure to celebrate that as a team!)
    • If the scores are further from each other: something’s off in your team, ask why they think the scores are so far apart (perhaps there was a personal matter, or someone is just not feeling the vibe for a week, but it could well be that there’s something deeper going on!)
  • Check if the scores align with the outcomes of the other games (having all scores in the ’Super’ lane, but having most of the other sticky notes in the other lanes means there’s something weird. Ask yourself and the team what might be the cause of that  (don’t go in depth) and (write down any outcomes, they’ll be helpful in the next steps).

2 – I like to do the above for the second game (one-word-retrospective) as well, it generally creates the same output – write it down, use it in the next step and in your report!

3 – Now comes the most important step. Ask questions about the answers (see those sticky notes) that were given to your four questions! There’s no set way, but I try to start on the ’Negative’ lane and work towards the ’Super’ lane, that way we can end with the super positive (awesome) stuff!

Go as deep as you can get (as deep as you feel comfortable with). It’s hard for any person to write down the real problem, what you get (what you see in the board) are the first-level problems. The underlying problem is much harder to get to, much harder. Ask questions to get deeper into the matter. Understand what the problem is, but more so what the cause for the problem is. Try to find solutions for each problem in an open discussion with your team. Let them make suggestions on how to improve the process (or people) to prevent us from having this problem the next time.

Be sure to write down what was discussed, that goes for the first two steps but most definitely for the last step. I like to make a picture of the final board (it helps me in writing my retrospective report, and i actually include it in my report – it looks nice!). I like to take older reports, to see if problems or issues have been there the same way in the last sprints, if we have improved them over the course of the last sprints or if we’ve completely solved them. It gives you a clear view on progress made, and it can show you if issues popped up because of solutions for earlier issues.

The above is my way of doing retrospectives, as stated before: there is no set way to be doing this. It all depends on your team, your organisation and the context.