Listen to this post:
This is part 7 of 7 posts on PMI-ACP Exam Prep (link to part 6). In this post, I focus on continuous improvement in the areas of product, process, and people, including process analysis and tailoring, product feedback methods, reviews, and retrospectives.
In traditional and waterfall methods of project management, the majority of the lessons learned are captured at the end of the project and this is usually too late or not useful at all. But as discussed on almost all previous posts in this series, agile projects focus on continuous improvement from early one and much more frequently through an iterative process.
Kaizen is a process for continuous improvement, which means “change for the better.” The Kaizen approach is the basis for agile’s way of doing continuous improvement. Kaizen focuses on encouraging the team to frequently initiate and implement small, incremental improvements. Kaizen follows the Plan-Do-Check-Act (PDCA) cycle, which closely mirrors agile’s Plan-Develope-Evaluate-Learn cycle.
Since agile is based on lean, we would expect agile to have its own Kaizen process, and it does – the team’s retrospectives. The difference is that the retrospectives happen at the end of each iteration and Kaizen is looking for daily improvements.
Agile’s continuous improvement efforts occur on multiple levels within the project. For example, in IT projects that use the XP methodology, the process begins at the code level where one person writes the code and the other reviews it, critiques it, and suggests improvements in real time. On a daily basis, the team shares its impediments in the daily stand-up meeting so the ScrumMaster could quickly remove them. And finally, each iteration ends with a review, in which the team demonstrates their work to the customer, and a retrospective, in which the team examine their process and decide on improvements to make in the next iteration.
Continuous Improvements – Process
Just as our plan evolves as we learn more about the project, the environment, and stakeholders, our approach to doing the work me also need to evolve. The main triggers for driving process changes on agile projects are the iteration retrospectives. To evaluate our process and identify areas for improvement, we can employ analytical tools such as systems thinking, process analysis, and value stream mapping. However, before we start making any changes to our process, we need to have a solid understanding of how process tailoring works and the best practices for implementing it.
“Process tailoring” refers to adapting our implementation of agile to better fit our project environment. Let’s look at the relationships between XP practices as an example to better explain this:
Removing or augmenting any of these elements without understanding the relationships among them can lead to problems. For example, ruthless testing allows for courageous refactoring, and having frequent user conversations allows the project to have light requirements. If you remove one practice without understanding its counterbalance, your project may be headed for trouble.
Note that some agile methodologies like Kanban emphasis on tailoring methods and process and recognize that each situation is different and other methodologies like Scrum are less keen on tailoring. Scrum suggests making changes to transform the enterprise into an agile environment that can better support Scrum approaches. Clearly, there are benefits and risks in both extremes.
Exam Tip 1: You should understand that process tailoring can be effective and productive, but the teams should be aware of the risks involved in this practice and mitigate these risks with following best practices:
- Get used to normal, out-of-the-box agile before attempting to change it.
- Carefully examine the motivations to drop, amend, or append a practice. Is the change a cop-out to avoid a more fundamental problem, or will it truly address a gap or add value in this project’s unique environment?
A hybrid agile model might be a combination of two agile methods, or an agile method and a traditional approach. Let’s look at a couple of hybrid models.
Agile-Agile Hybrid: Scrum-XP
This hybrid model is very popular. In fact, so popular that some people wouldn’t even consider it a hybrid model. The reason this combination works so well is that these two approaches are quite complementary since they each focus on different aspects of the project:
- XP provides great guidance but not much in the way of project governance guidance.
- Scrum provides a project governance model but not much in the way of how to do the work.
And so because of such little overlap between these two methodologies, this hybrid can offer well-informed, cohesive coverage for both managing the project and building this solution.
Sometimes certain portions of the projects are best suited to an agile approach in other parts to a traditional approach. Even if the plan for the execution of the project is linear rather than iterative, the team can benefit from certain components of agile – such as the daily stand-ups, retrospectives, and local decision making.
On agile projects, it might be best to use a traditional approach for certain portions, such as a procurement effort that has to follow a strict purchasing workflow.
When a team is considering changing their process, it can be helpful to understand the system-level environment for the project. This type of analysis is called systems thinking. One part of the systems-thinking approach is to classify projects in terms of their complexity in 2 areas: the project requirements and the technical approach.
Agile works best in the middle cell of this matrix because these “complex” products have some uncertainty around both requirements and technology, but not so much that they are chaotic or impossible to get our hands around. Agile methods can be used on simpler projects as well to reap the benefits of increased collaboration, communication, and visibility. But those kinds of projects can also run just fine using traditional approaches. Complex projects, on the other hand, become a struggle if the team tries to use traditional methods.
So when you think about modifying and tailoring your approach and process, it’s helpful to consider the project environment form this systems-level perspective. If there is no clear agreement on what you are supposed to be building and what approach and tools you should be using, then your project will be in the state of “chaos” and neither agile or any other approach can be successful.
Process analysis is closely related to process tailoring and systems thinking. Process analysis involves reviewing and diagnosing issues with a team’s agile methods.
The following is a list of anti-patterns, bad or unhelpful attributes, to watch out for in your methodologies:
- One size for all projects: It’s not possible to create one optimal methodology for all types of projects, all technologies, and all team sizes.
- Intolerant: A methodology can be like a straightjacket with little room to move around processes to follow. The size and shape of the straightjacket should not be tighter than necessary to give the team some wiggle room for choices.
- Heavy: There may be a misconception that the heavier a methodology, the safer it would be. In reality, it may divert the team’s attention and energy away from the real goal and delivering a product or service.
- Embellished: All methods tend to get embellished over time. You must gather all the stakeholders that are affected to review the process.
- Untried: Some methodologies are untried and are proposals created from nothing and are full-blown “shoulds.” Instead of creating new methodologies, it’s better to adjust and tune existing ones.
- Used once: A methodology that is used once is better than the one that is untried. As mentioned, the reality is that different projects need different approaches, and just because one approach worked under one set of circumstances doesn’t mean it will work under another.
Your approach works well if your projects meet these 3 success criteria:
- The project got shipped.
- The leadership remained intact.
- The team would work the same way again.
Methodology Success Patterns
You can see patterns of successful methodologies where:
- Interactive, face to face communication is the cheapest and fastest channel for exchanging information.
- Excess methodology weight is costly. Less documentation and more energy spent on delivering.
- Larger teams need heavier methodologies. As teams grow, however, osmotic communication and tacit knowledge become harder to maintain, so more knowledge needs to be committed to written documentation.
- Projects with greater criticality require a greater ceremony.
- Feedback and communication reduce the need for intermediate deliverables.
- Discipline, skills, and understanding counter process, formality, and documentation.
- Efficiency is expendable in non-bottleneck activities.
Value Stream Mapping
Value stream mapping is a flowchart method to illustrate, analyze and improve the steps required to deliver a product or service. A key part of the lean methodology, VSM reviews the flow of process steps and information from origin to delivery to the customer. It’s important to keep in mind that customers, whether external or internal, care about the value of the product or service to them, not the efforts it took to produce it, or the value that may flow to other customers. Value stream mapping maintains that focus. A typical process is to draw a current state VSM and then model a better way with a future state and/or ideal state VSM.
A great place to learn more on value stream mapping is here: https://www.lucidchart.com/pages/value-stream-mapping
There are a few terms you need to know for the exam:
- Total cycle time: In value stream mapping, the cycle time is referred to as “total cycle time” because we are breaking cycle time into 2 parts: value-added time and non-value added time. So the total cycle time is the sum of these 2 parts.
- Value-added time: This is the time during the cycle where value is being added to the process.
- Nonvalue-added time: This is the rest of the time in the cycle where we find delays, waste, and constraints that we want to remove.
- Process cycle efficiency: This is the total value-added time divided by the total cycle time. After making improvements, we would want to compare the before and after.
A project pre-mortem is a facilitated team exercise that aims to identify the possible failure points on a project before they happen so that we can avoid or minimize those risks. Pre-mortems are especially valuable on long-running projects that are likely to experience more changes than short projects, simply because they are exposed to a longer horizon of risk.
The participants in this failure analysis exercise include the dev team as well as the product owner. The dev team will be proposing risk avoidance or mitigation actions that the product owner will need to agree to add to the product backlog.
There are 4 steps to this exercise:
- Imagine the failure: The facilitator asks the participants to imagine that they are in the future after the project has failed completely, and they have been tasked to report reasons for this failure.
- Generate the reasons for the failure: It’s important that these ideas be generated independently to avoid the effects of cognitive and psychological bias.
- Consolidate the list: Once you consolidate the list of failures the team has come up with, you need to prioritize the list, usually by dot voting.
- Revisit the plan: Review your plan and see what you could do to mitigate or avoid the risks and issues identified. As the team comes up with mitigation ideas, new user stories may need to be created and the backlog updated.
Although pre-morterms are done near the start of the project, on a long project it’s a good idea to repeat them over the course of the project. This may require gathering the team every few months to review the list and plan to see if anything has changed.
Continuous Improvement – Product
Just as we continuously refine our processes, so do we continuously improve the evolving product through iterative and incremental development.
Agile reviews follow some basic ground rules or guidelines:
- Let the data speak for itself: We don’t try to prejudge the results of our experiments or filter out unlikely suggestions.
- Respect individuals: We value everyone’s view equally; we don’t judge suggestions based on the person’s role or seniority.
- Diverge then converge: By encouraging diverse suggestions we increase the likelihood of generating valuable insights and ideas. To generate these ideas we diverge (generate our ideas individually so that they are not influenced by our colleagues), and then we converge (we gather all ideas to review, agree on the most likely root causes of issues, and identify best suggestions for further experiments)
Product Feedback Loops and Learning Cycles
You may recall the figure above from my second post in this series. Each of these feedback loops – whether short and informal or langer and formal – reveal new information about the product or service we are building and the effectiveness of our knowledge and process. Agile teams need to continually try to confirm their understanding and correctness of their work like this. Product feedback loops ensure we are building the right thing in a robust and sustainable way.
Product feedback methods such as prototypes, simulations, and demonstrations of functionality are critical for success on agile projects. When we demonstrate functionality to the product owner, it serves two purposes:
- We learn about any differences between what we asked for and what we interpreted and built.
- We learn about any new or adjusted functionality that is required.
In other words, requirements evolve with prototypes, simulations, and demonstrations.
At the end of each iteration (or sprint), the team holds a review meeting with the stakeholders to demonstrate the new increment built in the iteration. If the product owner is satisfied that the increment has met the iteration goal, the item selected from the backlog for the iteration, then they will “approve” that iteration. If you are working with a vendor or have outsourced work for the iteration, you may have a clause in your contract that requires you to pay the vendor when each iteration is approved.
Continuous Improvement – People
Agile teams evaluate themselves and identify areas for improvement by examining the retrospective process and team self-assessment. But of these 2 topics, agile retrospectives are much more important for the exam.
An Agile retrospective is a meeting that’s held at the end of an iteration, after the iteration review.
Each member of the team members answers the following questions:
- What worked well for us?
- What did not work well for us?
- What actions can we take to improve our process going forward?
The Agile retrospective can be thought of as a “lessons learned” meeting. The team reflects on how everything went and then decides what changes they want to make in the next iteration. The retrospective is team-driven, and team members should decide together how the meetings will be run and how decisions will be made about improvements.
One the key benefits of the retrospective is that it offers immediate value to the current project, rather than just documenting good advice in the hopes that a project with a similar business domain or team dynamic will come along. There are of course other benefits too:
- Improved productivity
- Improved capability
- Improved quality
- Improved capacity
Step 1: Set the Stage
A retrospective session is most effective when everyone on the team is honest about what went well, and also what didn’t. There are as many team dynamics as there are teams, so sometimes getting started is awkward if people feel uncomfortable opening up. Sometimes the activity is a quick temperature gauge of the team. That can be as literal as drawing four weather patterns (thunderstorm, rain, cloudy, and sunshine) and asking teams to affix post-it notes to the weather pattern they think aptly describes how well the last sprint went. It can also be as simple as asking each team member to describe the last iteration in 3 words only. All of these exercises are designed to get the team warmed up for more specific discussions.
The aim of this step is to:
- Explain why we are doing the retrospective
- Get people talking so they are comfortable contributing throughout the retrospective
- Outline the approach and topics of the retrospective
- Establish ground rules
- Determine if people are comfortable enough to contribute to the retrospective
Step 2: Gather Data
For this step, it’s time to dig into some of the nitty-gritty details of the last sprint. Basically, we’re trying to capture as much information as possible by focusing on the sprints or iteration that just ended. One exercise used for this is to draw a boat with a large motor as well as a hefty anchor. Team members are asked to use post-it notes to write what they believe propelled the boat forward, and what kept it sunk in the last sprint.
Each idea is one post-it, and they are affixed to the corresponding part of the drawing as a way to visually conceptualize the successes and detractors. Teams then use this to discuss how to minimize the anchors and how to further propel the boat.
Step 3: Generating Insights
This step often flows very organically from Step 2, where pain points and successes are identified. The generating insights step is all about identifying patterns and duplicates in the process. Do three people on the team feel like they would have benefitted from more specific direction? That is a significant data point, as opposed to just one person feeling that way. Finding these commonalities helps to improve the process for everyone for the next sprint.
There are several team-based activities that you can use to generate insights, including:
- Brainstorming: the team focuses on generating a high volume of ideas that will be filtered afterward.
- 5 Whys: the participants analyze the underlying cause of a problem by asking “why?” 5 times.
- Fishbone Analysis: the team uses this diagram tool – often along with the 5 whys exercise to display the root cause of a problem.
- Prioritize with Dots: to determine their priorities, the team members use the dot voting technique described in my second post of this series.
Step 4: Decide What To Do
This is the most important step in the retrospective, albeit the one most often overlooked. A lot of teams have really great conversations but in the end, they never develop any action items in order to move forward. Frankly, it’s easier and less work to have the conversation, but not follow through. And if there is no follow-through, much of the value of the retrospective is lost.
Try to get the team to simply make a short list of things to keep in mind during their next sprint, in order to improve upon their work. Instead of trying to engage in a complete overhaul of their process, it’s better if teams move forward to the next iteration with just a few key focal points in order for them to work better.
Sprints, after all, are designed to be shorter term, ideally two weeks at most. Another retrospective will follow thereafter.
Step 5: Tying A Bow On The Retrospective
To summarize the retrospective, keep it light. After discussing each person’s takeaways, it helps the team to close on a high note.
For example, for each action item discussed in Step 4, you can ask teams of two to make a funny poster. They pick an image, agree on a title, and then write a humorous description. It’s a lighthearted way to encourage teamwork, while hammering home the action item they are agreeing to pursue for next time.
It is standard practice for agile teams to reflect on how well they are doing and look for things they can improve. There are tools that can help you in this area. I won’t be going through them but you can use the link below to learn more. For the purpose of the exam, you won’t need to know how the techniques work but do need to know the purpose of team assessments.
PMI’s Code of Ethics and Professional Conduct
Here is a link to PMI’s code of ethics and professional conduct. You should read this document before the exam. The exam may not have questions directly related to this area but situational questions that have an element of this section may be on the exam.