Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (17)
Ähnlich wie Feedback And Retrospectives In Agile Projects
Ähnlich wie Feedback And Retrospectives In Agile Projects (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Feedback And Retrospectives In Agile Projects
- 1. Feedback and Retrospectives in Agile Projects XP2010 1-4 June, Trondheim Rolf H. Knutsen (rhk@knowit.no) Haakon F. Spilde (hfs@knowit.no)
- 3. Howwework
- 5. Why are we measuring the use of retrospectives? We aim to be agile Feedback is crucial when being agile!
- 6. How do we measure the use of retrospectives? Wiki Ourprojects fill out a ”project barometer” Studys withhelp from resarchers Project funded by theNorwegianResarchCouncil In-depthstudyofsomeofourprojects SINTEF IKT - BørgeHaugset, Torgeir Dingsøyr and Geir Kjetil Hanssen
- 8. Project barometer/ studies Since 2007 – more than 150% increase in projectsperformingretrospectives Still room for improvement Our teams are positive to retrospectives Still theyarereluctant to performthem
- 10. ”Issues are not followed up”
- 11. ”Retrospectives doesn’t work in our team”
- 12. ”We don’t need retrospectives”
- 13. ”We don’t have time for retrospectives”
- 14. ”We ignore retrospectives since it’s no fun”
- 16. How can we motivate teams to perform retrospectives? Establish a common ground – feedback is needed. Establish how feedback shall be performed Follow the plan!
- 17. Retrospectives according to Scrum- our recommendations Perform retrospectives after every sprint Vary how the retrospective is done Keep the list of improvements short Build retrospective knowledge in the organization
Hinweis der Redaktion
- <hvordan vi jobber>
- Why are we measuring the use of retrospectives? We want to optimize our (future) projects We aim to be agile. Feedback is crucial when being agile Measuring the use of retrospective will help us improve, but it will also indicate if we need to take action
- How do we measure the use of retrospectives? We use wiki Since 2007 we have had our projects fill out a form we call a ”project barometer” We ask all our projects about once a year to add a new entry, so we can track changes over time both internally in one project and for the company as a whole Help from researchers SINTEF, as part of a project funded by the Norwegian research council (BørgeHaugset, Torgeir Dingsøyr, Geir Kjetil Hanssen) They did an in-depth study on two of our projects, asking the following questions: How are the retrospectives run? What are the common issues that arises? Are they useful? Improvement preposition
- Oppsummering fra barometer og forskerrapporten
- From 2007 until 2009, 150% increase in projects performing retrospectives, still many projects doing seldom or neverPeople like retrospectives, still they are reluctant to perform themParadox – introduce next slide
- We have asked why teams and projects are so reluctant to perform retrospectives? Most team members admit that it’s a good idea. So why don’t we just do it? Here are some of the argumets we have met in our work with retrospectives in different teams.Not part of the routine We don’t have a routine of running retrospectives at the end of every sprint. When retrospectives ARE held they raise tons of issues resulting in never ending meeting, and long lists of improvements.... Lists that are too long to being followed up.Issues are not followed up Perhaps the list of improvements from retrospectives are often too ambitious and therefore not possible to follow up? We run retrospectives, but the issues that are brought up are never resolved. The same issues keep re-apearing at every retrospective. Or maybe too many external issues outside the influence of the project. Nothing there is to do about the issues... The issues are just not followed up: No assigned responsible – no one is doing anything Issues are not put as issues on the backlog.Retrospectives doesn’t work in our team Most people in our team don’t contribute in the retrospectives. Only one or a few persons talk (PM/scrummaster) The team is distributed.We don’t need retrospectives We have a small transparent project, so we know what all are feeling about things. We have an open communication in the project and issues are handled continously. Everything is working fine in our project.We don’t have time for retrospectives The project is in a state of firefighting The project is close to a release dateWe ignore retrospectives since it’s no fun Have not met anyone saying this... But suspect that some think this way...!It’s about feedback! The team feel that there is enough feedback provided to the process through other channels – daily scrum, project meetings, sprint demo, review meetings, ad hoc discussions etc. Using a separate part of the scrum board for feedback is one technique that has been used. Running an extensive 4 hour retrospective at every sprint seems unnecessary, and as a waste of time. -> We don’t recommend this!******************************- hvis ikke regelmessig, blir mer tull - hyppighet fører også til et kortere møte - nedprioriteres i forhold til andre viktig møter - ’ond sirkel’, lange møter mye å ta tak i - lite prosjekt, forvaltning, durer og går av seg selv - alt fungerer, vi har det så fint - brannslokking / kaos, prosjektet går mot slutten – annet fokus Daglige standup og ukentlige prosjektmøter dekker en del av behovet.- En "ordentlig" retrospective etter hver sprint føles dermed for tidkrevende og nedprioriteres.
- Establish a common ground – feedback is needed. Make sure the members of the team/project agree that some sort of feedback to the process is needed. (Even the original waterfall process (by Winston Royce) had feedback!) When discussions are started at this end – close to everyone agree that feedback is necessary (we have yet too meet anyone objecting...)Establish how feedback shall be performed Is there any managament decisions on which process to follow and thereby perform retrospectives? If not – with the team decide how to perform feedback. For example doing retrospectives ala Scrum...Follow the plan! Follow the plan for how retrospectives are to be performed.************************Keep it short!Not doing the same for every retroDifferenttheme.Different ”games”Focusonlyon positives.Etc (mer eksempler...)Differentfacilitator.Externalfacilitator in retro.ExternalmotivationintoorganizationKnow IT: Diana LarssenPick FEW areas for improvement and MAKE SURE theyarefollowed up! Maybeevenonly 1Pickimprovementsyou CAN AFFECT and thatthe TEAM ARE MOTÌVATED TO DO. - Fornying. Tema. Kun fokusere positivt etc... Bruk eksterneVarier gjennomføringsmodellEksterne foredrag/kurs
- Perform retrospectives after every sprint Do not skip ANY retrospective – even if there is a fire burning. Especially not then! () Keep the retrospective short and to the point. This is easy when retrospectives are held after every sprint. Even if there is little or nothing to say in a retrospective – gather the team for two minute and make sure nobody has input.Vary how the retrospective is done Vary the facilitator. Can be a different person in the team, or a person from outside the team. We have used external facilitators with great success. Refreshes. (SM becomes a regular member of the meeting.) Even better to use persons outside the organization – if that is possible. Vary the theme – focus on a specific area. Spend a retrospective focusing only on positives. Throw out anchors when the meeting is started. Use “games” when running the retrospectives. Silly games are good! And vary the games that are used.Keep the list of improvements short One of the worst things that can happen is to have a long list of improvements that are not handled…! Pick maybe only ONE (simple) issue if you have problems following up issues. Make sure the team picks the improvement (and not the SM). The team must be motivated to implement the improvement. If possible: Put the improvements on the backlog. Make sure the improvements are visible to all.Build retrospective knowledge in the organization Build focus around retrospectives in the organization. Get external help. (Know IT – Diana Larsen. Boosted the focus on retrospectives in Know IT.) Establish a knowledge group focusing on retrospectives, and thereby spread the knowledge about retrospectives and increase motivation for performing retospectives.
- Feedback is important in any type of project / team! (For Scrum – Retrospectives)Teams are positive to retrospectives, but need help to get started establishing good routines.Our experience with focusing on retrospectives has given positive results in our organization.*****************************Retros important, but not easy to make teams to doThey need help, even though they like it and see the value of itOther ways of feedback than using retrospective. E.g. Kanban handling congestions. What’s important is FEEDBACK!