agile continuous improvement

D E L I V E R E D B Y:WA F I M O H TA S E BS O F T WA R E D E V E L O P M E N T M A N A G E RP 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

PMI-ACP® Course Exam Preparation

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


1. Set Stage

2. Gather Data

3. Generate Insights

4. Decide what to do

5. Close the Retrospective

3. Deliver completed user stories for evaluation

2. Build and test selected user stories

1. Plan the iteration, incorporating

improvements and experiments identified in

the retrospective

Retr

ospe

ctive

Itera

tion

These steps operate in an ongoing cycle that is synchronized with the iterations


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 OFFINQUIRY RATHER THAN ADVOCACYDIALOGUE RATHER THAN DEBATECONVERSATION RATHER THAN ARGUMENTUNDERSTANDING 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.

Simple

Low Complexity

Low Complexity

Chaos

Complex

Close to certainty

Far from certainty

Technology

Clos

e to

ag

reem

ent

Far f

rom

ag

reem

ent

Requ

irem

ent

Agile works well here

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 Process Improvement: 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

Agile Cycle

Plan, Do, Check, Act Cycle


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.

The team is then involved in analyzing the chart to identify which areas could use improvement.

Thinking

Collaborating

ReleasingPlanning

Developing

0

50

100


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 methodologyB. Tailoring it will be a good way to ease into the initial adoption processC. We should tailor it first, then consider adopting itD. 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; AppreciationsB. Plus/Minus; Helped, Hindered, Hoped; Return on Time Invested; ApplauseC. Plus/Delta; Helped, Hindered, Hoped; Return on Investment; AppreciationsD. 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 methodsB. A preference for face-to-face communications, not too much process weight, recommendations for larger teams to use lighter methodsC. A preference for face-to-face communications, significant process weight, recommendations for larger teams to use heavier methodsD. 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 interestB. Central to many of the practices undertakenC. Undertaken if there is time left at the end of an iterationD. 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 limitsB. Story points; daily stand-up meetings; demos, reviews, and retrospectivesC. Pair programming; daily stand-up meetings; demos, reviews, and retrospectivesD. 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. RedundantB. DuplicatedC. OptionalD. 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 retrospectiveB. Decide what to do, gather data, set the stage, generate insights, close the retrospectiveC. 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, embellishedB. One-size-fits-all, disciplined, heavy, embellished C. One-size-fits-all, intolerant, heavy, embellishedD. 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 practicesB. Experienced practitioners want to address an issueC. The team needs new processes to keep them engagedD. 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 practicesB. Gain insights for salary performance reviewsC. Identify personal traits for human resources counselingD. 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 againB. 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 earlyB. Investigate the claims yourself, try out the practice on local projects, inspect and review the findings earlyC. Investigate the claims yourself, try out the practice in small doses, inspect and review the findings earlyD. 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 projectB. Throughout the project C. When projects go wellD. When projects go poorly

14. Information exchanges in agile methods are designed to:A. Facilitate knowledge sharingB. Leverage electronic knowledge-sharing toolsC. Maximize resource utilizationD. Generate stable specifications