Agile Continuous improvement

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

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

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.


 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%)


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


 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


 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.


 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.


 What are the goals of the “Set the Stage” step in the retrospective process?


 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.


 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.


 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.


 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.

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.

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.

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?

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

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.

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.


 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.


 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

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

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

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.

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.

 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


 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?

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

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

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

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

Agile Continuous improvement

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Agile Continuous improvement

Similar a Agile Continuous improvement (20)

Último

Último (20)

Agile Continuous improvement

Notas del editor