7. Retrospectives Flashcards
what is software process improvement
- looking at the big picture
- identifying areas that can be improved
what is software process improvement
software engineering processes encompass whole range of practices intended to support quality assurance
1. planning
2. version control
3. continuous integration
4. automated testing
5. code reviews
6. continual refactoring
process improvement frameworks
- iso9001
- six sigma
- capability maturity model (CMML)
- agile process improvement
capability maturity model level CMML
- initial
- software process is ad-hoc or even chaotic - repeatable
- basic project management processes are established to track cost, schedule, functionality - defined
- software process for management and engineering activities is documented, standardised, integrated into the standard process for team - managed
- detailed measures of software process and product quality collected - optimising
- continuous process improvement enabled by quantitative feedback
principles for agile process improvement
- measurement is domain-specific
- improvement is an ongoing process
- requires full team participation
- best effort assumption
- working harder won’t improve the process
- blaming is pointless and counterproductive - fix root causes, not symptoms
process-improvement process
- gather data about the process
- analyse
- identify actions
- prioritise and implement
repeat…
scrum retrospective elements
- timing
- occurs at the end of the sprint, after sprint review meeting with the customer - participants
- whole development team. scrum master acts as facilitator - duration
- at least 30 mins to allow proper data gathering - data source
- team members and project artifacts
general method to gather data from team members
- team members populate template board independently using sticky notes
- similar items are grouped together
- team votes on priority issues for discussion
- select action for improvement
template
stop, start, continue/more of
how to identify opportunities for improvement in performance
- team members provide detailed information fo the performance of the team
- project artifacts provide alternative source of information about project’s historical performance
process improvement standards and models
- characterisation standard used to relate metrics gathered to assess maturity of team’s quality assurance process
- management standards explain methods and activities to undertake to conduct SPI effort
elicitation techniques
- theme boards
- liked, learned, lacked, long for - 5 whys
- diagnosing problem root causes
choosing improvement actions based on
- priority
- feasibility
- return on investment
monitoring and measuring
- creates tickets for the next release
- ensure someone is responsible for each activity
- include previous decisions in future retrospective
- review the process review process
drawbacks of team retrospectives
retrospective meeting may only take place every 2-4 weeks
1. problem left to persist for 2 -4 weeks
2. problems noted during sprint may not be recalled in the retrospective
3. details and circumstances may be forgotten
what does continuous process improvement mean
adopt continuous approach to process improvement. diagnose, apply solution to problem as soon s they are identified.
1. problems can be quickly dealt with
2. may mean that team is not involve in diagnosis or implementation of solution
3. may be disruptive to overall software process
as a compromise, diagnose and recommend solution in real time. discuss with team during retrospective
retrospective meetings can become stale
important to
1. vary structure
2. reflect on retrospective itself
3. experiment with different frequencies
4. allow other team members to facilitate
What are Retrospectives?
In Agile development, a retrospective is a meeting held at the end of each iteration to discuss what was successful, what could be improved, and how to incorporate the improvements and retain the successes in future iterations. Retrospectives cover topics such as the process, people, organizations, relationships, and tools. Regularly conducted retrospective meetings, when appropriate follow up activities occur, are critical to self-organization and continual improvement of development and testing.
Advantages of Retrospectives?
Retrospectives can result in test-related improvement decisions focused on test effectiveness, test productivity, test case quality, and team satisfaction. They may also address the testability of the applications, user stories, features, or system interfaces. Root cause analysis of defects can drive testing and development improvements. In general, teams should implement only a few improvements per iteration. This allows for continuous improvement at a sustained pace.
Timings of Retrospectives?
The timing and organization of the retrospective depends on the particular Agile method followed. Business representatives and the team attend each retrospective as participants while the facilitator organizes and runs the meeting. In some cases, the teams may invite other participants to the meeting.
Testers role in Retrospectives?
Testers should play an important role in the retrospectives. Testers are part of the team and bring their unique perspective [ISTQB_FL_SYL], Section 1.5. Testing occurs in each sprint and vitally contributes to success. All team members, testers and non-testers, can provide input on both testing and non-testing activities.
Testers role in Retrospectives?
Testers should play an important role in the retrospectives. Testers are part of the team and bring their unique perspective [ISTQB_FL_SYL], Section 1.5. Testing occurs in each sprint and vitally contributes to success. All team members, testers and non-testers, can provide input on both testing and non-testing activities.
Why is trust an important aspect of Retrospectives?
Retrospectives must occur within a professional environment characterized by mutual trust. The attributes of a successful retrospective are the same as those for any other review as is discussed in the Foundation Level syllabus [ISTQB_FL_SYL], Section 3.2.
