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.

Transparency is key

We all know that rivalry between departments. We all know that culture: “I don’t know what those developers are doing all that times there in that dark corner”. This seems to be a shared way of thinking in a lot of organisations, within a lot of departments. I used the stereotype ‘developers’ because that group is the most common to be targeted with comments and remarks like that, it is however true that stereotyping this way is cross-department.

Scrum, and actually all agile-based workflows, state that transparency is a key element in making your implementation work.

I agree on that. Sharing your end-sprint delivery with all stakeholders – or even better: your whole organisation  – gives your team (and management) valuable feedback. It also ensures that the rest of your organisation knows what you’re actually doing, even if you choose to stay “in that dark corner”. It allows the other departments to understand more of what you’re doing, and with a little bit more effort even makes them a part of it.

Create an open page on your wiki or intranet and share your sprint progress (show them your board and/or your burndown chart). I prefer an even larger transparency approach; open up all your meetings for anyone to sit in and listen! Let others literally sit in on your daily standups or your planning meeting and even your retrospective. Better yet: make a delivery presentation part of your retrospective and invite all stakeholders (or your whole company).

The biggest fear of teams when discussing transparency is that the team is scared to be viewed upon with a microscope or magnifying glass, that every move they make, or every delivery they don’t make, will be critiqued and (openly) joked about. While this fear might seem realistic at first glance. The opposite was true for all transformations to transparent teams and departments that I have witnessed.

Applying transparency applies positive pressure to your team; they will feel a bigger obligation to actually deliver and not look like fools. Your team will either get positive responses for all the work they’ve done or negative responses for the relatively small amount of work they’ve done. It does give them, however, a chance to defend themselves or openly discuss the problems they have encountered during the sprint, which in turn leads to more understanding from your organisation for the daily work the developers do!

The pressure that your team feels might seem harsh, and it might seem to undermine productivity at first glance. That might actually be the case for the first couple of deliveries. It does give you a clear way of gathering feedback, viewing what you’re doing ‘wrong’, either in your communication or your workflow (note: I don’t believe you can do things wrong, I believe you can do things better). This gives you the opportunity to address these issues and become a better team, a more effective and efficient team, a more contributing team (for other departments or your organisation) and it helps you grow – as an individual team member).

As pointed out earlier; I’ve used the development team as a stereotype but the above goes for any kind of department (and not only for scrum teams). A marketing department also continuously delivers, and they are also proud of what they deliver on a weekly (or so) basis!

Transparency creates understanding, creates clarity and gives your team credit for what you’ve actually accomplished. It creates a bond, within your team, within your department and even within your organisation.

The pain of introducing Scrum

The pain of introducing Scrum – or any new workflow for that matter. Obviously we all love the end result: self sustaining teams, better results, faster results and so forth. Introducing (or actually fully adapting and eventually adopting) a new methodology, whether it’s Agile, Lean, Kanban, Scrum or any other, is a painstakingly slow process.

The team that is to adopt a new workflow, but also the whole company, are stuck in their way of handling things as they are. While they might love the promises that adopting a new methodology brings forth, they are not ready for the changes and process that are involved with the change in many of the cases.

Inform your team and your organisation that changing to a new methodology will take a lot of time and a lot of effort. Make them understand that things will not be running smoothly from the get go.

“A team reflects on how to become more effective”

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

Sources: Agile Manifesto & Twelfth Agile Principle

Scrum, and also other agile methodologies, are built on constant feedback loops. That feedback eventually, time after time, leads to (minor) changes in the way the new workflow is adopted and used.

It is the team that makes Scrum work in the end. It is the team that has to identify and eventually tackle problems and bottlenecks in the current setup. Facilitate and guide the team in the identification and solving of those issues, whether you’re a Scrum Master, a stakeholder or a company as a whole.

Make sure that everyone involved knows that only time and transparency make your implementation work. Make sure that everyone involved realizes that a new workflow takes time to settle in, and mostly that it is a progress, not a straight forward implementation. Any good adoption of a new workflow is one where the team, and the workflow itself, have the space and time to evolve.

Change often leads to conflict

Change often leads to conflict, or that’s at least what it looks like at first glance. Change triggers resistance, an automatic – instinctive – reaction that we’ve all got built in. “Why change? The old way used to work”. While that might be true, change is needed to improve.

So why do we all naturally respond that way if we know that change brings improvement? The answer to that question is simple; insecurity – being scared of what the future brings with it. The improvement doesn’t necessarily mean that it’s a positive improvement for us as an individual.

How do you go from conflict and insecurity to positivism? While conflict (over change) is not the most ideal way of feedback, it is still feedback. If you have the ability to read the conflict well, you can use it to your advantage. The people that are part of the conflict will vent their fears and their core issues with the change that you are trying to implement – if you read between the lines.

Ideally you try to make the team that you’re working on part of the change. You make them decision makers in the change process. You don’t, however, always control that, there might be additions to the team after you’ve implemented the change – or worse, when you’re in the process of change.

A mistake I made in a recent implementation of change (going from 0 workflow to a Scrum workflow) was that I didn’t give the newest additions to the team enough room to vent their ideas. They had joined the team halfway through the implementation and couldn’t accept the way the implementation was working out for the team.

What I did to turn that negativity around as a Scrum Master:
I planned an extra meeting (aside from the retrospective, given that the feedback was vented in different ways and had to be dealt with right now) in which the team could openly discuss the problems that one of the team members had vented. I had already come up with changes I’d like to implement and had already begun discussing them with individual team members before the bomb was dropped. I wanted the team to come up with solutions under my guidance, and they did.

I’ve noticed that, while for some teams less important, it is very important to make retrospectives (and in some cases more meetings are needed during your first sprints) a core part of your scrum implementation. Make sure your team has enough room to vent frustrations and problems and make sure you’re listening as a Scrum Master.

Turn the conflict around and make it a positive change for both the team and yourself. Use the opportunity it gives you to make things work out for everyone.