The retrospective process is a key part of continuous improvement in agile projects. It consists of 5 steps - set the stage, gather data, generate insights, decide what to do, and close the retrospective. The goals of setting the stage are to create a comfortable atmosphere for reflection and focus the team on improvement. Retrospectives help teams apply lessons learned to current and future projects through frequent and deliberate improvement activities.
Advantages of Hiring UIUX Design Service Providers for Your Business
Agile Continuous improvement
1. PMI-ACP® Course Exam Preparation
D E L I V E R E D B Y:
W A F I M O H TA S E B
S O F T WA R E D E V E LO P M E N T M A N AG E R
P M P, P M I - A C P, P M I - S P, C E R T I F I E D S C R U M M A S T E R
2. Continuous Improvement
Most traditional projects capture the majority of their lessons learned at the end of the project.
The intent behind capturing these lessons is to allow the organization to apply them to future
projects with a similar business or technical domain, or to projects that have similar team
dynamics.
This approach, frankly, is too little, too late. We need to apply the benefits of learning as we go—
on our current project, and as soon as possible.
Agile projects schedule continuous improvement activities into the plan as part of the
methodology. The agile approach to lessons learned is deliberate and frequent, and it helps
ensure that the team regularly considers adaptation and improvement to the point where it
becomes habitual and part of their normal way of working.
We will look at the T&T and K&S that are part of this “Learn” step:
Retrospectives
Knowledge Sharing
Process Tailoring
Principles of Systems Thinking (Complex, Adaptive, Chaos)
Process Analysis
Continuous Improvement Processes
Self Assessment
3. Continuous Improvement - Retrospectives
Retrospectives, which are common to all agile methods, are the primary learning, reflection, and
readjustment events on agile projects.
A retrospective is a special meeting that takes place after each iteration, in which the team
members gather to inspect and improve their methods and teamwork.
Retrospectives offer a number of benefits for teams, including the following types of
improvements:
Improved productivity: By applying lessons learned and reducing rework, the team can get more productive work done.
Improved capability: Retrospectives provide a venue for spreading rare knowledge, and as the number of people who have
the rare knowledge increases, so does the number of people who can perform tasks associated with the knowledge.
Improved quality: We can improve quality on our projects by finding the circumstances that led to defects and removing the
causes.
Improved capacity: Retrospectives focus on finding process efficiency improvements, which can improve the team's capacity
to do work.
4. Continuous Improvement - Retrospectives
The retrospective process goes through the following five steps:
The typical time is 2 hours
Set Stage (5%)
Gather Data (30-50%)
Generate Insights (20-30%)
Decide what to do (15-20%)
Close the Retrospective (10-15%)
5. Continuous Improvement - Retrospectives
These steps operate
in an ongoing cycle 1. Set Stage
3. Deliver completed user
that is synchronized stories for evaluation
with the iterations
2. Gather Data
Retrospective
Iteration
2. Build and test selected
3. Generate Insights user stories
4. Decide what to do
1. Plan the iteration,
incorporating
improvements and
5. Close the experiments identified in
Retrospective the retrospective
6. Continuous Improvement - Retrospectives
Step 1: Set the Stage:
At the start of the retrospective, we need to set the stage to help people focus on the task at
hand of reflecting on how things went.
In setting the stage, we aim to create an atmosphere where people feel comfortable speaking
about things that may not have gone so well on the project.
Activities to help set the stage include:
Check-in
Focus on/ Focus off
ESVP
Working agreements
7. Continuous Improvement - Retrospectives
Check-in: We use this exercise to help people put aside their concerns and focus on the
retrospective. In a round-robin format, we ask people to summarize in one or two words what
they hope to get from the retrospective, the main thing on their mind, or how they are feeling
about the retrospective.
Focus On / Focus Off: We use this activity to establish a mindset for productive communication.
FOCUS ON / FOCUS OFF
INQUIRY RATHER THAN ADVOCACY
DIALOGUE RATHER THAN DEBATE
CONVERSATION RATHER THAN ARGUMENT
UNDERSTANDING RATHER THAN DEFENDING
In the focus on/focus off exercise, we refer participants to the whiteboard and ask them to
discuss what the terms (i.e., inquiry, dialogue, conversation, understanding, advocacy, debate,
argument, and defending) mean to them, inviting them to provide examples. Then we ask people
if they are willing to stay in the left "Focus On" column. If there is disagreement, we should speak
to the problems of moving into the right-hand column and try for consensus again.
8. Continuous Improvement - Retrospectives
ESVP: This is a group exercise in which participants anonymously associate themselves with one
of the following identities and record their choice on a slip of paper:
Explorers: Explorers are eager to discover new ideas and insights, and they want to learn everything they can.
Shoppers: Shoppers will look over all available information and will happily go home with one useful new idea.
Vacationers: Vacationers aren't interested in the work of the retrospective, but they are happy to be away from their regular
job.
Prisoners: People who classify themselves as prisoners feel like they are being forced to attend the retrospective and would
rather be doing something else.
The anonymous results are collected and tallied for the group to see, after the results have been
tallied, we should noticeably tear up and discard the slips of paper so no one worries about their
answers being traced back to them via handwriting analysis. Then we ask the participants how
they feel about the scores and what those scores mean for the retrospective.
Working Agreements: For this activity, we have the participants form small groups and give them
different topics to work on. We ask the small groups to define and explain the working
agreements they would like to see in place for the retrospective. Then with the entire group, we
spend time clarifying and refining ideas, building a single master list to work from.
9. Continuous Improvement - Retrospectives
What are the goals of the “Set the Stage” step in the retrospective process?
10. Continuous Improvement - Retrospectives
Step 2: Gather Data:
In the gathering data phase, we create a shared picture of what happened during the
iteration (or release or project, depending on the focus of the retrospective).
Without a common vision for what occurred, the team will simply be speculating on what
changes or improvements to make and may actually be addressing different issues or
concerns without realizing it.
There are several team-based activates that can be used to gather data:
Timeline.
Triple nickels.
Color code dots.
Mad, sad, glad.
Locate strengths.
Satisfaction histogram.
Team radar.
Like to like.
When we are finished with this step in the process, we should have a comprehensive
collection of observations, facts, and findings, all of which have a shared understanding by the
team.
11. Continuous Improvement - Retrospectives
Step 3: Generate Insights:
This stage gives the team time to evaluate the data that was gathered in the previous step and
derive meaningful insights from it.
The goal of the generating insights stage is to help team members understand the implications
of their findings and discussions.
There are several team-based activates that can be used to gather data:
Brainstorming.
Five whys.
Fishbone.
Prioritize with dots.
Identify themes.
12. Continuous Improvement - Retrospectives
Step 4: Decide What to Do:
The activities involved in the "decide what to do" step move the team from thinking about
the iteration they just completed into thinking about the next iteration, including what they
will change and how they will behave differently.
In this step, the team identifies the highest-priority action items, creates detailed plans for
experiments, and sets measurable goals to achieve the desired results.
There are several activities that can be used to help the team decide on an action plan:
Short subjects.
SMART goals.
Retrospective planning game.
Circle of questions.
13. Continuous Improvement - Retrospectives
Step 5: Close the Retrospective:
The final step is closing the retrospective. We provide the team members opportunities to
reflect on what happened during the retrospective and to express appreciation to each other
Activities that summarize what the team decided to keep and what to change, what we are
thankful for, and where we can make the best use of our time going forward, help round out
the retrospective and reinforce its value to the project.
There are several team-based activities that can be used in this final stage:
Plus/Delta.
Helped, Hindered, Hypothesis.
Return on Time Invested (ROTI).
Appreciations.
So those are the five steps of the retrospective process. In summary, these important agile
workshops enable the team to take the impediments and problems reported at daily stand-up
meetings, along with items identified after reflection and observation, and do something to
improve the situation while the lessons and actions are still relevant to the project.
14. Continuous Improvement – Knowledge Sharing
Knowledge sharing happens at many levels, in both obvious and subtle ways. Product
demonstrations are an example of an obvious method. The main purpose of such demonstrations
is not to show off the product, since the team knows very well what works and does not work;
instead, demos are done because they are high-ceremony ways to share knowledge through the
following kind of dialogue:
Team to customer: Here is what we think you asked for and what we have been able to build. Please tell us
if we are on the right track.
Customer to team: I like these bits, and this is okay, but you got this piece wrong. Oh, and that reminds
me—we really need something over here to do X.
An example of a less obvious way to share information is team co-location. This practice is not
done to save space or ease management overhead; instead, it is done to leverage the sharing of
tacit (unwritten) knowledge that occurs in face-to-face environments and through osmotic
communication.
Retrospectives are also knowledge transfer vehicles.
15. Continuous Improvement – Knowledge Sharing
We understand that knowledge sharing is a good thing, why is it sometimes difficult to achieve
and sustain?
“Individuals are most commonly rewarded for what they know, not what they share." This reward system actually
discourages knowledge sharing. To promote the idea of sharing knowledge, the organizational culture should instead
encourage and reward the discovery, innovation, and transfer of information.
Measuring Up to Encourage Desired Behavior:
"You get what you measure, in fact you get only what you measure, nothing else. So you tend to lose the things that you can't
measure, like knowledge sharing, insight, collaboration and creativity”
How we can overcome this issue? We measure up .
Measure up means, that we measuring something at one level above the normal span of control
(The team level rather than the individual level) to encourage teamwork, collaboration, and
global, rather than local optimization.
Tracking velocity is an example of measuring up. We could quite easily trace velocity to individual
team members and determine who is the most productive, but this approach would likely
encourage negative behaviors and a lack of cooperation. So instead we measure velocity at a
team level; as a result, team members are motivated to help each other.
16. Continuous Improvement – Process Tailoring
When we tailor processes on agile projects, we amend the methodology to better fit the project
environment we are using it in.
Some methodologies are quite tailoring-friendly, some are not.
There are benefits and risks with both extremes. When considering the question of whether
process tailoring is appropriate, we should first recognize that all projects are different. They
solve different problems, face different challenges, utilize different people, and operate in
different organizations with different cultures and norms.
We have two point of views here:
Create process-per-project approach—in other words, creating processes that are situationally specific for the job at hand.
Maintain an adherence to agile values and practices. Supports of this approach says that methodologies may transform the
agile approach beyond recognition and then, when projects fail, those failures will be blamed on agile.
Process tailoring can be effective and productive, but that we should be aware of the risks
involved in this practice. The following are the key ways to mitigate these risks:
Get used to normal, out-of-the-box agile before attempting to change it. The methods were created based on the collective
wisdom of many experienced practitioners, so don't be too hasty to change them.
Carefully examine the motivation to drop, amend, or append a practice. Is the change a lazy cop-out to avoid a more
fundamental problem, or will it truly address a gap or be a value-add unique to the environment?
17. Continuous Improvement – Principles of System
Thinking
Software projects are characterized by the level of complexity around requirements, as well as
the complexity of the technology used on the projects.
agreement
Far from
Chaos
Requirement
Agile works
Low
Complex well here
Complexity
agreement
Low
Close to
Simple
Complexity
Close to Far from
Technology
certainty certainty
18. Continuous Improvement – Principles of System
Thinking
We see projects range from simple (lower left) up to those categorized as anarchy or chaos
(upper right).
An agile approach works really well for projects in the middle ground. These projects are complex
and have uncertainty around both requirements and the technical approach.
Agile methods can of course be used for simple projects, too, in which the organization and the
team will get the benefits of increased collaboration, communication, and visibility, but simple
projects can be run just fine with traditional approaches as well. In contrast, complex projects
begin to struggle when they are merged with traditional methods.
If there is no clear agreement on what we are supposed to be building or what approach and
tools we are using to build it, then our project is in a state of chaos. In this case, neither agile nor
any other approach can assure success.
We have to keep in mind this system-level understanding of the environment in which agile
projects are operating when we think about modifying the methods.
19. Continuous Improvement – Process Analysis
Process analysis is closely related to process tailoring and the principles of systems thinking.
When we perform process analysis, we are reviewing and diagnosing issues with agile methods
or, more likely, our home-grown add-ons and replacements to agile methods. This analysis may
then lead to a decision to tailor the process.
Anti-Patterns (bad things to watch out about methodologies):
One size for all projects: it not possible to create the optimal methodology for all types of projects, al technologies, and all
team sizes.
Intolerant: A methodology is like a straightjacket in that it is a set of conventions and policies people agree to adhere to and
use. The size and shape of the straightjacket should be chosen by the team and should not be made any tighter than
necessary, so people have a little wiggle room in their actions.
Heavy: There is a common but incorrect belief that the heavier a methodology is in artifacts and practices, the safer it is.
However, adding weight to a methodology is not likely to improve the team's chance of delivering the project successfully.
Instead, it diverts the team's time from the real goal of the project.
Embellished: All methods tend to get embellished. We add in things that we think we "ought to" or "should" be doing, but we
need to look out for these words as signals for potentially expensive, error-prone additions. Get the people directly affected
by the process to review the methodology, and watch their faces closely for indications of what they know they won't do but
are afraid to admit they won't do; these items are the embellishments.
20. Continuous Improvement – Process Analysis
Anti-Patterns-Cont.
Untried: Many methodologies are untried. They are proposals created from nothing and are full- blown "shoulds" in action.
For example, how often have you heard statements like, "Well, this really looks like it should work"? Instead of creating
complex theoretical methodologies, it is better to reuse, adjust, tune, and create just what is needed. See what actually
works on projects and use that, not something untried that we believe "should work.“
Used once: A methodology that is used once is a little better than one that is untried, but it is still no recipe for success. The
reality is that different projects likely need different approaches, and just because an approach worked under one set of
circumstances does not guarantee it will work under another.
Process Success Criteria:
The project got shipped: The product went out the door.
The leadership remained intact: They didn't get fired for what they were doing (or not doing).
The people on the project would work the same way again: They found the approach to be effective and enjoyable.
21. Continuous Improvement – Process Analysis
Seven Principles that tells us if the methodology tend to success criteria:
Interactive, face-to-face communication is the cheapest and fastest channel for exchanging
information.
Excess methodology weight is costly
Larger teams need heavier methodologies
Greater ceremony is appropriate for projects with greater criticality
Increasing feedback and communication reduces the need for intermediate deliverables
Discipline, skills, and understanding counter process, formality, and documentation
Efficiency is expendable in non-bottleneck activities
22. Continuous Improvement – Continuous
Improvement Processes
Continuous improvement is the ongoing process of enhancing the project approach and the
product.
This process is never completed; instead, it continues throughout the project in much the same
way as stakeholder communications do.
Continuous improvement is something we will always do.
It is more like a journey than a destination, since it is always ongoing and is part of the iterative
life cycle that drives agile methods.
Continuous Improvement works on two levels:
Continuous Process Improvement
Continuous Product Improvement
23. Continuous Improvement – Continuous Improvement
Processes
Continuous Process Improvement:
Agile Cycle
The agile cycle employs a continuous cycle of Plan,
Develop, Evaluate, and Learn.
This cycle is very similar to Deming’s “Plan, Do,
Check, Act” cycle for problem solving and continuous
improvement.
The "Develop" phase in the agile life cycle is like
Deming's "Do" phase. "Evaluate" is equivalent to the
"Check" phase. In the "Learn" phase, we apply the
lessons from the project, in much the same way as
the "Act" phase in Deming's cycle. And the "Plan, Do,
Check, Act" cycle is again mirrored in agile methods
with demos, reviews, and retrospectives.
Plan, Do, Check, Act Cycle
Plan
Act Do
Check
24. Continuous Improvement – Continuous
Improvement Processes
Continuous Product Improvement:
Just as the team practices and processes are being refined iteratively and continuously, so too is the evolving product.
Iterative and incremental development is a form of continuous improvement, with customer feedback steering us toward the
final solution.
When the team builds small increments and get feedback, the product evolves toward the true business requirements. And
sometimes the true business requirements may be quite different from the originally stated requirements, as the process of
creation illuminates better options.
By this cycle of developing in small increments, reviewing, discussing how to improve, and then doing some more
development and maybe enhancing a few things, the product or service is incrementally built through a process of
continuous improvement.
25. Continuous Improvement – Self Assessment
Assessments of how to improve are not reserved just for the process and product; they are also
done on the people side of the project, which is arguably the area that offers the greatest
payback.
“James Shore” offers a self-assessment quiz and scoring model that is focused on XP practices,
teams can use this model to gauge their performance.
The quiz and scoring graph measures how teams perform within the following categories:
Thinking
Collaborating
Releasing
Planning
Developing
The quiz is completed by answering questions within each category and scoring the answers on a
0-100 scale.
26. Continuous Improvement – Self Assessment
Once all the questions have been asked
and scored, the results are plotted on a
radar (spider) diagram. Thinking
100
The team is then involved in analyzing the 80
chart to identify which areas could use 60
40
improvement. Developing
20
Collaborating
0
Planning Releasing
27. Continuous Improvement – Self Assessment
Another model for assessing high-performing teams is offered by “Jean Tabaka”, this model
investigate the following areas:
Self-organization: Is the team self-organizing, rather than functioning in a command-and-control, top-down
organization?
Empowered to make decisions: Is the team empowered to discuss, evaluate, and make decisions, rather than
being dictated to by an outside authority?
Belief in vision and success: Do team members understand the project vision and goals, and do they truly believe
that, as a team, they can solve any problem to achieve those goals?
Committed team: Are team members committed to succeed as a team, rather than being committed to individual
success at any cost?
Trust each other: Does the team have the confidence to continually work on improving their ability to act without
fear, anger, or bullying?
Participatory decision making: Is the team engaged in participatory decision making, rather than bending to
authoritarian decision making or succumbing to decisions from others?
Consensus-driven: Are team decisions consensus-driven, rather than leader-driven? Do team members share their
opinions freely and participate in the final decision?
Constructive disagreement: Is the team able to negotiate through a variety of alternatives and impacts surrounding
a decision, and craft the one that provides the best outcome?
28. Practice Exam
1. Your sponsor is asking about tailoring the company's newly adopted agile methodology. Your advice should be:
A. Tailoring it will be a good way to learn the methodology
B. Tailoring it will be a good way to ease into the initial adoption process
C. We should tailor it first, then consider adopting it
D. We should try it first, then consider tailoring it
2. When conducting a retrospective, recognized "close the retrospective" activities include:
A. Plus/Delta; Helped, Hindered, Hypothesis; Return on Time Invested; Appreciations
B. Plus/Minus; Helped, Hindered, Hoped; Return on Time Invested; Applause
C. Plus/Delta; Helped, Hindered, Hoped; Return on Investment; Appreciations
D. Plus/Minus; Helped, Hindered, Hypothesis; Return on Time Delivered; Appreciations
3. You have been asked to review a different project team's recently enhanced methodology to assess its effectiveness and desirable
characteristics. 'The types of characteristics that you should be looking for include evidence of:
A. A preference for face-to-face communications, significant process weight, recommendations for larger teams to use lighter methods
B. A preference for face-to-face communications, not too much process weight, recommendations for larger teams to use lighter methods
C. A preference for face-to-face communications, significant process weight, recommendations for larger teams to use heavier methods
D. A preference for face-to-face communications, not too much process weight, recommendations for larger teams to use heavier methods
4. The concept of knowledge sharing on an agile project is best characterized as:
A. Encouraged where possible and where the team shows an interest
B. Central to many of the practices undertaken
C. Undertaken if there is time left at the end of an iteration
D. Undertaken principally through stand-up meetings
29. Practice Exam
5. Continuous improvement is a core component of which of the following set of agile practices?
A. Pair programming; daily stand-up meetings; WIP limits
B. Story points; daily stand-up meetings; demos, reviews, and retrospectives
C. Pair programming; daily stand-up meetings; demos, reviews, and retrospectives
D. Story points; daily stand-up meetings; WIP limits
6. When considering process tailoring, it is useful to keep in mind that the network of XP practices is:
A. Redundant
B. Duplicated
C. Optional
D. Balanced
7. The recommended stages of executing a retrospective, in sequence, are:
A. Decide what to do, set the stage, gather data, generate insights, close the retrospective
B. Decide what to do, gather data, set the stage, generate insights, close the retrospective
C. Set the stage, decide what to do, gather data, generate insights, close the retrospective
D. Set the stage, gather data, generate insights, decide what to do, close the retrospective
8. You are engaging in some process analysis and have been advised to watch out for the standard anti-patterns of poor methodology practice.
The types of things you should be on the lookout for are processes that display signs of being:
A. One-of-a-kind, disciplined, heavy, embellished
B. One-size-fits-all, disciplined, heavy, embellished
C. One-size-fits-all, intolerant, heavy, embellished
D. One-of-a-kind, intolerant, embellished
30. Practice Exam
9. Process tailoring is best undertaken on agile projects when:
A. There are difficulties in implementing agile practices
B. Experienced practitioners want to address an issue
C. The team needs new processes to keep them engaged
D. A boost in team velocity is needed to meet the schedule
10. Your project management office (PMO) has suggested your project could benefit from some self- assessment work at the next retrospective.
Which of the following benefits would they most likely be looking to achieve from a self-assessment?
A. Improve personal and team practices
B. Gain insights for salary performance reviews
C. Identify personal traits for human resources counseling
D. Assess compatibilities for pair programming assignments
11. When undertaking process analysis, what are the success criteria that characterize a useful methodology?
A. The project got stopped, sponsorship remained intact, the team would work the same way again
B. The project got shipped, leadership remained intact, the team would work the same way again
C. The project got shipped, sponsorship remained intact, the team would work the same way again
D. The project got shipped, sponsorship remained intact, the team engaged in continuous improvement
12. When adopting a new agile practice, the general recommendations are to:
A. Develop the new approach yourself, try out the practice on local projects, inspect and review the findings early
B. Investigate the claims yourself, try out the practice on local projects, inspect and review the findings early
C. Investigate the claims yourself, try out the practice in small doses, inspect and review the findings early
D. Develop the new approach yourself, try out the practice in small doses, inspect and review the findings early
31. Practice Exam
13. As a manager of an agile team, when should you collect lessons learned?
A. At the end of the project
B. Throughout the project
C. When projects go well
D. When projects go poorly
14. Information exchanges in agile methods are designed to:
A. Facilitate knowledge sharing
B. Leverage electronic knowledge-sharing tools
C. Maximize resource utilization
D. Generate stable specifications
Notas do Editor
The immediate application of lessons learned is especially critical for quickly changing projects and for projects with high degrees of uncertainty and risk, where staying the course could be fatal to the project if circumstances change.
Since retrospectives happen during the project, the lessons and improvements that result from them are applicable and relevant to upcoming work; after all, the upcoming work will have the same business domain, technical domain, and team dynamics as the iteration being assessed
In setting the stage, we aim to:Explain why we are doing the retrospectiveGet people talking so they are comfortable contributing throughout the retrospectiveOutline the approach and topics of the retrospectiveEstablish ground rulesCheck safety levels; in other words, determine if people feel comfortable enough to contribute to the review
Plus/Delta In this exercise, we capture and validate the team's ideas for what we should do more of (things that are going well) and what we should change (things that are not going well) on a whiteboard or flip chart.Helped, Hindered, Hypothesis This exercise helps generate feedback on the retrospective process itself and produces ideas for improvement. To run this session, we first prepare three flip charts, one titled "Helped," one titled "Hindered," and the last with the title of "Hypothesis:' We explain to the team that we are looking to improve the retrospective process and would like feedback on what they think helped, what was a hindrance, and any ideas for improvement (hypotheses) for retrospectives going forward. Participants then write ideas on sticky notes and post the notes on the appropriate flip chart.Return on Time Invested (ROTI) This is another exercise to generate feedback on the retrospective process. This exercise focuses on whether people believe their time was well spent.Appreciations During this exercise, team members have a chance to express appreciation to other team members for their help, contributions, problem-solving efforts, etc.
KimizDalkir identifies that
Talk about Multiple Layers of Continuous Improvement on Agile ProjectsContinuous improvement is also layered like an onion. In software development projects, for example, continuous improvement happens at the code level with pair programming. One person is writing code, and the other is reviewing, critiquing, and suggesting improvements. Daily stand-up meetings discuss work done and any issues or impediments on the project. These issues then become the "to-do" items for the Scrum_Master or project manager, who is responsible for removing impediments and improving the process. At a broader level, the iteration demo, review, and retrospective cycles that occur at a biweekly or monthly cadence purposely examine the process and look for improvements to make in the next iteration.