The Prime Directive
•Download as PPTX, PDF•
8 likes•2,019 views
The document discusses various tools and frameworks for conducting retrospectives, including the Prime Directive, Safety Checks, Starfish diagrams, and Thinking Hats. It also touches on potential challenges with retrospectives, such as failures to complete agreed upon actions, difficulties prioritizing issues, and the dangers of introducing retrospectives into a new environment if not done properly. The overall topic is facilitating productive and effective retrospective meetings and identifying issues that could arise.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to The Prime Directive
Similar to The Prime Directive (20)
Recently uploaded
Recently uploaded (20)
The Prime Directive
- 3. The Prime Directive Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
- 4. The Safety Check (numbers) 1. I am going to nod and stay quiet. 2. I might talk about some things I want to fix. 3. I will share my opinions, but I’ll stay away from some controversial stuff. 4. I will talk frankly but sensitively. 5. I feel safe to say anything in front of this group.
- 5. The Safety Check (ESVW) Explorer: I want to discover as much as I can. Shopper: There are some things which I want to get from this session. Vacationer: I am happy to be here. Worker: I am willing to be here.
- 6. Check on last iteration Were the actions completed? If not, are they still important? If so, did they make a difference?
- 8. Starfish More of Less of Stop doingStart doing Keep doing
- 9. The Land Ahead The land we left behind Slowing us down What do you want to take with you? The land ahead
- 10. Six Thinking Hats - Edward de Bono
- 11. Futurespectives Start of the project Release 1 Legacy system turned off Legacy system turned back on again Working overtime and weekends PM negotiates scope cut Project release party! Everyone votes for C# as language
- 13. Prioritising Changing code causes too many bugs Code base hard to work with Too much technical debt The build is too slow Unit tests really helped me Taking time to refactor made my story easier Grouping Voting
- 14. Wrapping it up Liz to teach unit-level BDD PM to negotiate 25% less new stuff this iteration Concrete actions Owners
- 15. The Dangers of Retrospectives What do you think could go wrong when retrospectives are introduced into a company or a new project?
Editor's Notes
- This is the Prime Directive, written by Norman Kerth. It’s intended to move people away from a blame culture and post-mortem mindset, and towards a more positive, change-oriented approach. It can also help to increase safety. It isn’t actually true, because we’re all human and we don’t do the best job we could, so at some point it may be safe for the team to acknowledge that and move on anyway.
- Before I start a retrospective, especially with a new team or if there are management present, I run a safety check. It is *crucial* that the safety check is anonymous. I use the same pens, same post-its and get everyone to fold their paper the same way. I used to share the scores, but now I only share the flavour of the scores, letting people know if there are some people in the room who are unsafe for any reason. If the safety check comes out with a significant number of 1s and 2s, we will run a workshop on how to make it safe for people to share opinions, instead – maybe introducing some ideas around respectful conflict, etc.
- For teams with very low safety, this can sometimes help people to feel safe. That fourth box used to be called “prisoner”, but nobody’s being physically held in place; they’re usually there because they feel they’re expected to be there. In this safety check there are no bad sides, so people are sometimes more likely to vote honestly. If the safety still comes out low, it may be that removing the management (sensitively!) from the retro will help – you can run another safety check with them out of the room to see. I’ve even removed myself as the retrospective facilitator before!
- Most teams forget to do this! If no actions are being taken, and no change is happening, why are we even having a retrospective? If the changes aren’t happening, why not? Is there something else blocking them that we need to address first? Sometimes blockers need to be teased apart rather than smashed.
- This is a really easy one to run and most people facilitating a retro for the first time really like this.
- I like using this as a futurespective format, eg: for an Agile transformation, or at the beginning of a project. The land left behind will be the last project or the previous company where somebody worked. Maybe there are also things that people are afraid of finding on that lovely beach – scorpions in the sand!
- I’ve blogged in more detail about this here: http://lizkeogh.com/2009/01/22/six-thinking-hats/ - it also leads to the excellent Wikipedia page. The book is worth getting too.
- Future- and Retrospectives can both be run using a timeline. Sometimes looking back at a project can be quite cathartic. When looking back on a project, I sometimes get people to put smaller stickies or dots on the line to represent their “happiness” at any given point. We can easily see what points were going well and what points went badly then!
- To stop the most dominant voice taking charge, silent work can be really important – getting everyone to generate their ideas and then put them up together. This can result in a *lot* of ideas. We then group the ideas into similar themes, and vote on which theme we want to discuss – I usually give a team of 10 people about 3 votes each, and suggest that they should come up with 3 to 5 ideas. Usually there are a couple of big things that absolutely have to be covered.
- Actions may not just be about change. Sometimes they can be about anchoring things that are working well – for instance, making sure someone knows how much their help was appreciated, or spreading a practice that’s been done at a smaller scale. Sometimes people also come up with “project principles”; ongoing mindset changes that the team agrees to adopt. These can be posted up on the wall, and end up forming values for the project team. They should be revisited regularly.
- Some teams hate retrospectives. I’ve even heard, “We didn’t have any of these problems before!” Making problems visible and apparent can be threatening, and in a blame culture it will often result in uncomfortable and disrespectful conflict. Another problem is when a PM runs a retrospective for their own team. They are often responsible for the process, and have their own ideas about how to fix it. This can bias the way that the retrospective goes, and ends up stifling the team’s ideas, even with the most willing PM (or SM!) This is why I’m very keen to have a large number of people able to facilitate retros – so that we can have people with no agenda in that role. There are lots and lots of books and blog posts on retros out there. I recommend Pat Kua’s work – he has a book on http://leanpub.com as well as a blog on http://www.thekua.com/atwork . If you would like to do this more regularly, please do read around the subject and practice in a safe environment first!