Agile Retrospectives
•
7 likes•3,182 views
This presentation is about retrospectives. No exercises, but general idea's and topics
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile Retrospectives
Similar to Agile Retrospectives (20)
More from Yves Hanoulle
More from Yves Hanoulle (20)
Recently uploaded
Recently uploaded (20)
Agile Retrospectives
- 1. www.PairCoaching.net how to make your retrospectives the of your agile process Yves Hanoulle
- 2. Principles behind the Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- 3. What is a retrospective
- 4. It’s not a post mortem
- 5. We are not in CSI
- 6. More like a checkup
- 7. More like a checkup...
- 8. 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. At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgment used to embarrass.
- 10. prepare
- 11. Who?
- 12. Room
- 13. Set a goal
- 14. Set the Stage (Check in)
- 15. First 5 minutes
- 17. Seek to perceive more then to be perceived
- 18. Use teams especially when undertaken difficult or boring tasks
- 19. Speak always and only when I believe it will improve the general result/effort ration
- 20. Offer and accept only rational result-oriented behavior and communication
- 21. Do now what must be done eventually and can effectively be done now
- 22. Disengage from less productive situations
- 23. When I cannot commit to the team charter
- 24. When it is more important to engage elsewhere
- 25. Seek to move forward a particular goal, by biasing my behavior toward action.
- 26. Use the Core Protocols (or better) when applicable.
- 27. Neither harm – nor tolarete the harming of –anyone for this or her fidelity to the team charter
- 29. Absent people
- 30. Timebox
- 31. Stop Cards
- 32. Referee cards
- 33. Start on time...
- 34. Safety
- 35. ESVP
- 36. Gathering Data
- 38. Identify Themes
- 39. Ask for help
- 40. Rescue
- 41. Decide what to do
- 42. Actions
- 43. Who will be driving these actions?
- 44. SMART
- 45. Close
- 46. Smells
- 47. answers come from the leader instead of the participants.
- 48. Only a few people participating
- 49. Everyone is always happy...
- 50. Nobody talks about the elephant
- 52. People looking for silver bullet’s
- 53. Retrospectives in the team room
- 55. Too many changes
- 56. Blame Game
- 57. Instruments
- 58. Resources
- 59. Exercise Divide in groups of 3 people (of 3 different locations) Pick up a retrospective Story Design the retrospective (30 minutes)
- 60. Team 1 The very first retrospective of a new team
- 61. Team 2 A retrospective of a sprint where the team delivered only 60% of the features. This has been the situation for the last 6 sprints.
- 62. Team 3 This team is doing "scrum" for a year. They have never done a retrospective. You design their first retrospective
- 63. Team 4 This team had a great review, the customer invited the whole team to a restaurant with 2 stars in the michelin guide, this is the teams retrospective after that. The teams wonders if they actually need a retrospective at this moment.
- 64. Team 5 This team has been doing scrum for 3 years. The retrospectives have been dull the last 5 sprints. You need to bring back the energy of the team.
- 65. Team 6 The retrospectives of this team have been mainly ranting/complaining sessions about other people/teams in the company. Nothing has been comming out of these retrospectives . Some powerfull team members stay away from the last retrospectives.
- 66. Team 7 After a few painfull sprints, this team had a succesfull sprint
- 67. Team 8 This is the last retrospective with this team. Next week half of the team leaves.
- 68. 30 minutes
Editor's Notes
- A retrospective is not a post mortem.A post mortem is a lesssons learned held at the end of a project.Post –mortem means your project is dead and ther eis not much you can do about that.Yes we can learn something form it, but what is the point? The next project is delivered with another team.You can write beste practises down and the next team that will use them won’t know why that was decided. As much as I could want to be a CSI kinda guy, CSI is not about preventing the murder, it is about finding the killer.For one I prefer to be a docter that can actually save his patient.And next do we really want to look for a persons that killed the project? A retrospective is the heartbeat of your team/organization.You know what happens to creatures without a heartbeat.They die.Agile is about doing the right things right.We have two methodologies that help us with that.XP helps us to do the things right. efficient.Scrum helps us to do the right things. EffectiveFor both of these methodologies we need a kind of verification. That is what a retrospective is.
- This comes from the first book on retrospectives from Norman Kerth. This was not about agile retrospectives but more about Post-Mortems. Still Norman has great idea’s and is one of the must read books for anyone that wanst to facilitate Retrospectives.The other one is Agile retrospectives on which most idea’s from this talk come from.
- Before we can do a musically gig, we need first to design the stage. This part is about how to design a retrospective.You will find that preparation of a retrospective is half the work.
- First question to ask is, who will be in the retrospective.The team should be a in the retrospective. Who is the team? Developers, Testers, Product Owner, Scrum Master, Project manager, Proxy Customer, Operational people.Although it is a good idea to have the customer in a retrospective and have a completly open culture, your team or company might not be ready for this.Retrospectives are a good tool to create an open culture. But you have to build this up. Having customers in your first retrospectives before the team has learned to trust eachother is the best way to kill a team.The same is true for management. If you have management in your retrospectives, the team might be talking to them instead of talking to eachother.A retrospective is a team tool, not a management tool.Ones we have figured out who wil be in this retrospective (yes the people invited might change between retrospectives) the next question is who will lead this retrospective.Actually who wil be there and who will lead is a chicken and egg problem. They will influence eachother.With a new team, an agile coach or scrum master can lead the retrospective.Ones a team has seen how this is done, as fast as possible the team should take charge of the retrospective.I learned this one by mistake. As a scrum master I was leading the retrospectives of my team. As a scrum master I also wanted to say stuff, which is not possible in the facilitator role. I asked other facilitators of that company to lead the retrospective of my team. And I retrurned the favor.The hidden message we gave our teams was hat they could not be trusted to do a retrospective themselves. That is surely not the message I wanted to give my team. Surely because I already see a fe peopel hat were able to lead retrospectives at that moment and some others I’m sure I could learn to do it.Only when I created these slides I realized the solution for a problem I had been struggling with for a year. Yes I asked for help. But not to the wrong people. Asking my team for help would have been a very strong message to my team.My currently great solution would ask the team to lead the retrospective by a rotating role. Everyone will have it’s own style, this wil encourage the diversity of your retrospectives. And it will empower the team.Another thing that is important is that it is only an invitation. People don’t have to be there. Another law of OpenSpace applies here: whoever wil be there are the right people.If people are forced to be in the retrospective, they won’t contribute. And when they don’t contribute they might kill the team dynamic. If always the same people ignore the retrospective that is a sign. It might be a good reason to have a one on one conversation with them about this. Again make sure you don’t ive them the feeling your forced them to be there.
- Every meeting should have a goal. While having a general retrospective can be a good idea in the beginning of the project, at some point they tent to become boring, that’s the sign that you forgot to set a goal. People attend out of habit, that’s the way we do agile. Possible goals could be:- Find ways to improve our technical practises Find ways to improve our internal /extrenal communication- Discover what we were doing well- Understand reasons behind missed targets- Find ways to improve our responsiveness to customers- Rebuild damaged relations-“continouus process improvements” the general oneAlthough it is ok to have more then one retrospective with the same goal, make sure you change often enough.
- The place where the retrospective takes place has a lot of influence.The room in this picture is not a good place to hold a retrospective.People should feel safe enough to put post it’s on the wall.The people in the retrospectives should feel safe to have heated discussions.The team room is also not the best place to have most retrospectives, people migh stay behind their computers and use their computers.As with all other meetings, do a retrospective topless (without computers, Blackberry’s and iPhone’s.) Ask people upfront to close their computers and to either silence their phones or leave the room when they take a call. I silence my phone while saying this, as an example. In most cases my phone is already on silence, so I only chec if it is on silence.
- Once we have designed the stage, we are ready to go to the build or set the stage.
- The first thing to do in a retrospective is to make sure everyone talks the first 5 minutes. This is the reason why I asked everyone at this presentation to introduce yourself.IT people have the reputation to be quite shy people who don’t like to communicate. I don’t agree with that statement. I think most IT people like to communicate: but when we do, we prefer to use a certain teminology that non-it people don’t like/understand.A lot like doctors or lawyers do.It is amazing how much so called shy people say in a retrospective ones they have spoken in the first 5 minutes.
- Every team should have a team charter. In this charter we say what we hold eachother accountable to.During retrospectives we will look at the team charter and add and remove stuff.Before a team starts or at one of the first retrospectives a team should write their own charter.It is important that management lets the team create their own charter.This is not to say that management can’t have idea’s. But their voice count’s as much or as little as anyone else’s voice.I show this team charter as an example because most teams will focus on technical stuff on their charter, I want to make sure they also think about communication; Which is in my opinion the only think they can’t worry about before beginning.This is about creating a team culture. This can’t be avoided, every team has a culture.When PM/CEO/managers speed this up, they actually are saying we don’t care who you are. Only what you doI once had a manager claiming he wanted his resources (How I hate this word) to be replaceable like machine.Only he did not like that they had no involvement.Treat people like machine and they’ll behave like machines..
- I language is not the next product comming from Cupertino (Apple)I language is talking about your self instead of talking about other people.Never say you screwed up by breaking the build. Muchbetter isI had a problem when the build broke so often to test the sofware on time.This gives the same message to the people that broke the build, but now you have more chance that they have heard the message.
- Always speak with respect of the people who are absent.Or don’t talk about them. There is enough to discuss with the people present.
- This technique tries to find out how people feel about beig in the retrospective.Explorers want new ideas and insightsShoppers will look for all available information and are happy to go home with one useful new ideaVacationers aren’t interested in the work (glad to be out of the office )Prisoners feel they are forcedDeal with them differently.If you have mainly prisoners, then you should drop everything you have prepared and talk about that in the retrospective.
- Story of discussion with Els in the morningStory of discussion Michele I’ll check inI’m GLAD that I’m at Agile Tour Toronto I’m GLAD, AFRAID this talk is captured by Camera’sI’m SAD as I won’t see my family for 5 daysI’m GLAD to see so many people in this roomI’m AFRAID I might have JetLagI’m IN
- Once we have our stage up and running, the audience is here. In a retrospective this means, gather data.
- 4 kind of storming- All- Round robinThink first- Combine 2 and 3
- My car will not start. (the problem)Why? - The battery is dead. (first why)Why? - The alternator is not functioning. (second why)Why? - The alternator belt has broken. (third why)Why? - The alternator belt was well beyond its useful service life and has never been replaced. (fourth why)Why? - I have not been maintaining my car according to the recommended service schedule. (fifth why, a root cause)
- When you do retrospectiveIt is important to group the post it’s together.I personally I’m not good at this. I have a collegue who was great at thsi, therefore I have forced me for some time to become as good as she was. I did not work. Now I realized I should ask my audience to help me , and not always want to do this myself. And not make myself a bottleneck...
- Do this on- DecisionsInformation-Problem solving
- Fototoestel toevoegen (foto van op XP london)
- Mention http://www.dotmocracy.org/ ?
- Mention http://www.dotmocracy.org/ ?
- AppreciationsPuzzlesComplaints with recommendationsNew informationHopes & Wishes