THE FOLLOWING PMI-ACP^® EXAM TOPICS ARE COVERED IN THIS CHAPTER:

 Domain VII: Continuous Improvement (Product, Process, People)

• Task 1: Tailor and adapt the project process by periodically reviewing and integrating team practices, organizational culture, and delivery goals in order to ensure team effectiveness within established organizational guidelines and norms.
• Task 2: Improve team processes by conducting frequent retrospectives and improvement experiments in order to continually enhance the effectiveness of the team, project, and organization.
• Task 3: Seek feedback on the product by incremental delivery and frequent demonstrations in order to improve the value of the product.
• Task 4: Create an environment of continued learning by providing opportunities for people to develop their skills in order to develop a more productive team of generalizing specialists.
• Task 5: Challenge existing process elements by performing a value stream analysis and removing waste in order to increase individual efficiency and team effectiveness.
• Task 6: Create systemic improvements by disseminating knowledge and practices across projects and organizational boundaries in order to avoid re-occurrence of identified problems and improve the effectiveness of the organization as a whole.

 In this chapter, you will work through the tasks found in Domain VII: Continuous Improvement (Product, Process, People). The tasks directly relate to understanding that Agile frameworks are not one size fits all and that tailoring your projects and utilizing best practices that complement your current project is an important skill to have and to understand. Obtaining feedback during a product review and having retrospectives as a team will increase your ability to work together to learn, grow, and increase value across the projects on which you are working.

Continuous improvements are a major tenet of Agile project management, so this domain takes everything that we have reviewed so far and focuses on improving your skill sets. This will, in turn, improve the products you create, the processes you use, and your team. Some of the information on tailoring can be found in the Agile Practice Guide (Project Management Institute, 2017), and it aligns with updates found in the PMBOK^® Guide, Sixth edition, released in September 2017. This overlap of best practices allows tailoring needs to pull from both Agile best practices and predictive best practices in a way that is most relevant for your project’s needs.

Tailoring

Not every single project is going to gain value from a specific Agile framework. For some, Scrum is too rigid and focused on software development; meanwhile you are working in a hardware installation environment. Maybe you come from a Waterfall background and your organization isn’t too keen to change anytime soon, and therefore you can only improve best practices in short bursts by pulling in one or two things that can help.

In fact, most tailoring will coincide with a Waterfall team’s expansion into different industries. The amount of certified PMP professionals in the world are well over seven hundred thousand to date: that means a lot of professional project managers practicing Waterfall and needing variety to keep up with the technology. There is now a need to have experience or knowledge in multiple models or frameworks to determine how your unique projects can benefit from a different approach.

The selection of the best practice to utilize on a unique project is called tailoring, and it will involve the project manager collaborating with the project team, sponsor, and organizational management in order to make sure that the chosen approach is the best one to meet the organizational needs and the business intent for the project.

The sixth edition of the PMBOK^® Guide references tailoring and Agile at the beginning of every chapter and knowledge area, and the Agile Practice Guide recently published by the Project Management Institute (in partnership with the Agile Alliance) shows that having the best of both worlds is possible as long as you select the best approach for the project on which you are working.

A lot of items trending now in the Waterfall space are visual management tools like Kanban boards and an expansion of the project manager’s responsibilities in business case development and determining whether a hybrid approach to the project may be needed. Updates may need to be made to how a project management office (PMO) might be run to accommodate a multitude of disciplines rather than trying to work with a one-size-fits-all approach to overseeing projects on the organizational level. The PMO may have to adapt and shift to changing needs or unique projects and may become the voice for best practices from the top down. This can help the organization get through the chaos much more quickly if done correctly.

Hybrid frameworks have also become a necessity when one framework isn’t scalable or even remotely applicable. Hybrids could include ScrumBan (Scrum and Kanban), Waterfall with aspects of Scrum, Scrum with aspects of XP, and others that have evolved due to the actual practice of new ways of performing similar tasks.

The following will be not an exhaustive list of tailoring or hybrid approaches, but it is comprehensive enough to understand where they came from and why they are important to review.

Scaled Agile Framework Scaled Agile framework (SAFe) was designed as a response to some current challenges in Agile frameworks that included a limited number of team members in order for the process framework to work. That is unrealistic for many organizations, so SAFe created a way for alignment, collaboration, and delivery for large numbers of Agile teams ranging from 50 to 125 to several thousand members and was created from Agile development, systems thinking, and Lean product development.

Like Crystal methods, which use a scalable model, there are several SAFe configurations, as follows:

1. Essential SAFe: Basic Level
2. Large Solution SAFE: Enterprise-level and complex system (aerospace, defense, government)
3. Portfolio SAFe: Enterprise for multiple solution creation
4. Full SAFe: Large enterprise projects using hundreds to thousands of people

The elements of SAFe mirror many of the elements that you have reviewed in many other Agile frameworks, but they are appropriate for the tailoring of this framework, including metrics, road maps, shared services, vision, community of practice (CoP), a system team, milestones, and Lean UX (User eXperience).

The SAFe foundational elements reflect aspects of both Lean and Agile and are recommended experience for leadership. Some of the core values include built-in quality, transparency, program execution, and implementation road maps, as well as SAFe-specific principles and recommended consultants.

Large Scale Scrum Large Scale Scrum (LeSS) is a product development framework that extends some of the confines of Scrum and allows for scaling guidelines without losing the original purpose or flavor of Scrum. LeSS was created by Bas Vodde and Craig Larman based on experiments in large-scale environments as simpler ways of working on larger projects, without devaluing the Scrum framework. There are two levels of LeSS:

• LeSS Huge This level has additional scaling elements of development added to accommodate hundreds of developers all working on the same project. That’s a far cry from the original recommendation of no more than nine team members who are all colocated!
• LeSS Level This level began in the telecom and finance industry, and it can accommodate scaling up to eight teams.

• LeSS utilizes core competencies that include ways to combat the organizational complexity experienced by many industries when attempting to implement Scrum-specific projects.

  There are LeSS Roles, LeSS Management, and LeSS organizational structures. That sounds a lot like Scrum, except it is much larger!

Enterprise Scrum Created by Mike Beedle, Enterprise Scrum was designed to allow for faster, more efficient, and customer-driven innovation for higher profits and revenue. Enterprise Scrum allows for scalable models and empirical project management. The framework includes multiple levels of planning and improvement cycles as well as reviews for business value and for the increment. Value list items are refined, much like backlog refinement before the cycle continues. Value includes cultural value, which embraces Scrum values and business analysis. A value list is created similar to a product backlog, and each has a definition of ready (DOR) and a definition of done (DOD).

The team roles are similar to Scrum in the sense that there are three key roles—the business owner (instead of product owner), Scrum Master, and team—as are the reporting techniques. Scrum boards, burn down charts, and tracking metrics are the same.

Enterprise Unified Process Enterprise Unified Process (EUP) is a customizable framework that is iterative and incremental, architecture-centric, and risk focused. EUP can be compared interchangeably with the Rational Unified Process (RUP), which is a tailorable process that allows for development guidance and automated tools and services, which allow both the processes and tools to be utilized and adopted quickly.

Agile Unified Process Agile Unified Process (AgileUP) features accelerated cycles and less heavyweight processes than the Unified Process (UP) or (EUP) on the enterprise level. AgileUP contains seven key disciplines, which include modeling, implementation, testing, deployment, configuration management, project management, and environment- or situationally specific decision making.

Disciplined Agile Delivery Developed by Scott Ambler at IBM to incorporate using networks of cross-functional teams, Disciplined Agile Delivery (DAD) was designed to scale key best practices in order to fill the gaps left by other frameworks in enterprise solution environments. DAD utilizes the best of the best from Scrum, XP, Agile Modeling (AM), Enterprise Unified Process (EUP), Kanban, and other approaches. The model also embraces a people-first approach, is learning oriented, incorporates a full delivery cycle and process-driven goals, and is solution focused and enterprise aware.

Agile Modeling Agile Modeling (AM) is a collection of values and principles that can be applied to software development and may be considered an add-on tailoring approach for Scrum and XP as well as DAD. The focus is on documentation throughout the life cycle but documented as late as possible and stored in one place to prevent versioning confusion. Its requirements are specific to customer tests. Much like Scrum and XP, Agile Modeling is tough to implement on larger teams. Any team with fewer than 30 people is about the maximum capacity for this framework.

Tailoring and the PMBOK^® Guide

Due to the necessity of different approaches for different project types, the Project Management Institute worked closely with the Agile Alliance to publish the Agile Practice Guide, mentioned at the beginning of this chapter. This collaboration resulted in updates to best practices in the Waterfall dynamic as well.

Each knowledge-area chapter like Scope, Time, Cost, and others has information on tailoring approaches and considerations for Agile. These considerations map to the Agile Practice Guide and allow discussions and training on other ways of performing the same tasks as needed.

Figure 10.1 shows an overview of all of the knowledge areas and how they map to Agile considerations. All of the information shown is from A Guide to the Project Management Body of Knowledge (PMBOK^® Guide), Sixth Edition (Project Management Institute, 2017).

It’s easy to see that tailoring considerations and Agile hybrids are becoming frontrunners in new and better ways of managing projects. In a way, it’s freeing to be able to cherry pick what will work with your unique projects.

My advice is twofold: both for and against tailoring. If you are planning to incorporate new processes or tools on your current projects, make sure that you and your team understand those processes and tools and work to keep improving the implementation of them and checking the results. Be vigilant about stakeholder communication, and provide explanations if they aren’t familiar with Agile or your chosen best practices. Practice servant leadership rather than project management, and communicate, collaborate, and congratulate.

Here’s just a tiny bit of advice about tailoring, especially if your team or organization is new to Agile. It is better to use a proven method of best practices than to try to create a hybrid approach right out of the gate.

Learn the techniques before throwing a methodology out as not working. Remember, there will be some initial chaos, and typically that is the precise point when it’s often determined that Agile isn’t working. Keep practicing! Based on the criticality of your projects and the weight of method, you may need to adjust your framework based on team size and project length.

Because I personally love being able to pick and choose the how and why of my projects, it all is very exciting to see. My PMP brain and my PMI-ACP brain can fire in all directions, and where I see gaps or challenges in one, I find the answer in the other. You have a lot of options now, and training, mentoring, and coaching is highly recommended, so use them all accordingly. Agile and tailoring are the new face of project management, and having skills in many areas is to your benefit for sure!

Lead Time and Cycle Time

Like many project management terms and jargon, there is some overlap depending on what frameworks you use. In this case, the terms cycle time and lead time may have some overlap in their usage. I bring this up because there are some differences between the two, but they can often be used interchangeably depending on your chosen framework or organizational lingo.

According to the Agile Alliance, which helped coauthor the PMI Agile Practice Guide, lead time originated in the Toyota Production System (TPS) and was a part of their Lean manufacturing processes. In this context, lead time is the amount of elapsed time between when your customer orders an increment to the time of completion and the order being received by the customer—basically, from start to finish of the project itself. This may be very relevant to those of you who are working in a Waterfall or hybrid/tailored environment, since the assumption is that something tangible will be produced.

In a software development or Agile environment, it may very well be an internal project designed to provide a new product or service, be first to market, develop a bug fix, or perform an internal upgrade. If that is the case, then lead time may reflect the time between when the team determines a requirement is needed, a user is story created, and the point at which that increment is being utilized by an end user.

Lead time isn’t actual effort either. Lead time is simply the time from start to finish. It could take the team five days from the request to the actual execution of the request. The actual execution could be considered effort, whereas the timeline is lead time.

In continuous improvement endeavors, reducing your lead time shows that improvements have been made.

Cycle time, on the other hand, can be defined from the development side as the starting point of execution on a feature and getting that feature into the done column and ready for deployment. If you choose to use both terms, one could generically view lead time as a customer timeline and cycle time as the team timeline.

In terms of organizational return on investment, the focus is on lead time, as it represents the start and finish of the work, rather than the cycle time, which is more of a tracking mechanism for the team. In Figure 10.2, it is easy to see how they work together in a visual manner.

No matter how you track time on your projects, there are several variables that may be considered, including cycle time (development and testing time), work in progress (WIP), and throughput (average amount of time that it takes the team to complete the work within a specific time frame).

It is important to understand the percentage of efficiency on the iteration by comparing value time versus cycle time and to determine the efficiency of your process. One way to do this is to divide the value-added time by the cycle time for the process.

All results of process efficiency, value time and cycle time determination may be considered during a retrospective to effectively improve the value stream and the team’s effectiveness. According to the PMI-ACP exam content outline, it is important for the team to challenge existing process elements by performing a value stream analysis and removing waste in order to increase individual efficiency and team effectiveness.

There are several variables to consider when looking at team progress and effectiveness of work to produce something that is considered valuable while at the same time attempting to increase your pace and output while producing something of quality.

Process Improvement

Because performance tracking and process improvements on Agile projects may be very different from a typical Waterfall project, it’s important to define all of the variables that you may see on your Agile projects or on your exams. The following list will give you an idea of how they all contribute to the success of the project as well as how they can raise red flags for issues.

Throughput Whether you use throughput or velocity on your projects depends on the Agile framework you elect to use and what your stakeholders want as far as information on time frames. Many people see throughput and velocity as interchangeable terms, whether you use Lean or Scum/XP. It is often difficult to explain the ideas of story points and velocity to those who are newer stakeholders to Agile environments. Velocity is more for the team’s benefit when determining how much work they can take on in an iteration or sprint. Throughput is based more on duration estimates (the time work will take to complete), not calendar days per se but the number of backlog items that can be done in a given time period. This helps stakeholders who are used to duration estimates wrap their minds around the team’s completed work. User stories are still included, but typically the team will pull the highest-priority stories from the backlog and complete them. They will keep track of when they started and finished those stories and summarize them monthly. Much of the calculation has to do with average amounts of work being completed based on the historical information of the current project.

Takt Time Takt time is the German phrase for pace or rhythm. To determine the team’s pace or rhythm during an iteration is to determine the rate that the team needs to work to keep up with customer demands. Many times, this is seen in mass production manufacturing environments. If the customer wants a certain amount of mobile device batteries produced within a certain time frame, you can calculate how much time it takes per device by dividing the total amount of available time by the total amount of product demanded: time/demand. It’s also a good indicator if the demand is unreasonable and it needs to be adjusted per your process and for quality purposes.

Work in Progress By now, you probably have a good understanding of work in progress (WIP) and how important it is to limit WIP to avoid bottlenecks, unfinished work, or slow workflow. Much as it is difficult to truly multitask (that is, to do any one thing effectively when bouncing around from task to task), limiting WIP is a way to improve your process. It often takes a while for a team to find their groove and determine that there is a better way to doing things. A big part of a retrospective, however, is to look back and see what went well and what didn’t. It’s important to be aware of setting WIP limits as a way to improve your process flow continuously.

Cumulative Flow Diagrams (CFDs) Another way to determine how your projects are progressing is to incorporate cumulative flow diagrams (CFDs) to represent visually the reality on your iteration. At a very high level, these diagrams can help your team track performance and forecast out by tracking features that are in progress, completed, or on deck to be worked on. Total features over time are addressed allowing the team to get a glimpse into their progress and see additional features added over time. Just like any diagram or visual representation of work, a cumulative flow diagram can show areas where issues have occurred or may occur, and it allows the team to adapt and adjust as needed.

Theory of Constraints It is a foregone conclusion that project management is filled with constraints—scope, time, and cost being the big three offenders. The Theory of Constraints (TOC) is a management philosophy that looks at the speed bumps in a project and identifies the most influential constraint and then improves upon it until it no longer impacts the project in a negative way.

Constraints are often called bottlenecks in production systems: Once the bottlenecks are removed, the flow improves. Much as Pareto charts look at the most impactful reasons defects occur in quality, the Theory of Constraints focuses first on identifying the constraint, then determining how one could exploit the constraint, followed by subordinating all other processes in order to exploit the constraint. If that doesn’t get it done, then more resources or capacity would have to be added to meet the need to attempt to elevate or remove the constraint.

Remember, TOC is a management philosophy, and your organization may have many ways in which constraints that impact the project are removed or worked around. One of the key aspects of an Agile team versus a Waterfall team is the Agile team’s cross-functionality and self-direction. This allows for the team to decide exactly what the constraint is and how to manage it more effectively and in a timely manner. Waterfall teams may have to go through formal change control, update their documentation, or even implement a risk response if the constraint it too impactful.

While you may not be using all or any of these performance measurements on your current projects, it is always a good idea to know how performance is tracked outside of an earned value analysis for time and cost. It’s very likely that you won’t be using earned value analysis on an Agile project and that the team will look for waste in the system or the process instead, as well as determining how you can improve the value stream.

Failure is only the opportunity to begin again more intelligently.

Henry Ford

Value Stream Mapping

One of the coolest things about Agile frameworks is that some failure is expected. It would impossible to work in an environment of iterative and incremental development without taking a few extra steps along the way that cause you to stray from true performance. It is also a no-finger-pointing environment in which the team works together on solutions and the efforts to implement them. If that doesn’t work, they try, try again.

Another aspect of Agile project management is the visual representation of performance in the team space. It’s highly unlikely that something will squeak past without being noticed by somebody, and once noticed, it will be discussed and repaired.

The best-laid plans often go sideways; the goal is to not stay put and make the same mistakes over and over. Instead, the goal is to work through the processes that are being used and find the culprit causing the problems and remove it. This is where value stream maps can be a valuable asset in continuous improvement measures.

Value stream maps are designed to show a process visually from start to finish and to identify value and non-value-added time.

Value stream mapping is used to identify process improvement opportunities and overall cycle time improvements, and when waste or non-value-added activities are discovered, the team works to remove those activities (if possible) and a new map is created. I say if possible because it isn’t always possible to march into a meeting and explain to the sponsor that their meetings are a total waste of time. That tends to result in an RPE, or a resume-producing event! Where the team can make improvements, they will, and where they can’t, they will work within those constraints to the best of their abilities. The steps for process improvements are a lot like the frameworks of Agile: easy to talk about and hard to do.

The most dangerous kind of waste is the waste we do not recognize.

Shigeo Shingo

A value stream map is a visual representation of the goal and the steps required to accomplish the goal. That may be the highest-value product or the highest-value process. Most of the maps I have seen are process oriented, but they affect the product or results. In manufacturing, identifying waste in the process flow includes delivery times, material flow, inventory, and so on, and the map will look at the current state of the process and then create an ideal state and a prediction for a future state. Thus, it involves the mapping of the current process steps using collected data about the process itself, the information flow, and the current cycle time. Much of wasted time involves waiting or lag time between deliveries or unnecessary movement of items, materials, or the team. The goal of the visual plotting out of the process is to identify what areas are causing the bottleneck in progress and which of those items may impact your timeline as the iteration progresses. Many times, the team will identify the pain points in the process and, if possible, work to include a kaizen, or continuous improvement effort.

If you are interested in a full-blown map for Lean manufacturing, you will see different icons that represent distinct aspects of the map and templates that you can use to create your own maps. For our purposes, it is a way to view value versus non-value.

In Figure 10.3, you will see the difference between value stream mapping and process mapping. They are different items, but both are valuable for the long and short-term planning efforts in which your team will be engaged. Value stream mapping focuses on multiple processes versus a singular process that needs improvement.

Continuous Product Improvement

The idea of continuous improvement in the context of project management typically involves a sharp focus on the product being made better. In a quality management arena, there are several ways that products are improved. Whether through pair programming in the eXtreme Programming environment, refactoring, inspections, reviews, or retrospectives, product improvement is a key aspect to many of the best practices found in Agile frameworks.

Earlier in the chapter, you reviewed some of the tailoring aspects of frameworks and how a one-size-fits-all approach isn’t always the right answer. Many times, it is necessary to pull best practices from different methodologies and frameworks to create the better best practices needed for your industry. In short, Agile isn’t just for software development anymore.

Instead, Agile frameworks come in a variety of combinations with other methods, or they are inclusive of Waterfall tools and techniques. Agile is becoming mainstream, as is the need for organizations to remain competitive in a global environment and produce the best products and services they can both internally and externally.

The necessity for understanding multiple ways to improve not only our processes but our products is driving organizations to find better solutions. Much of what drives continuous improvements are the efforts of the team and their management who are in the trenches, if you will. They are in the best position to identify needed improvements and to share those improvements transparently in a way that can be captured for later projects.

Improvements are difficult without growth, though, and the people who do the work and know the product or service therefore need to improve proactively as well through training, education, certifications, and coaching.

Much of the reason the number of PMI-ACP certified professionals is growing exponentially is a shift in the needs of project management. Current processes may need to be expanded and improved upon, and having the skills to do so are highly marketable and, moreover, highly necessary for continuous improvements and organizational growth. Proactive instead of reactive is the rising trend. There are several ways to do both and move forward with improved products and processes.

Don’t be afraid to give up the good to go for the great.

John D. Rockefeller

Summary

This chapter began with information on the different types of options one has for tailoring or adapting their current processes in a way that suits their industry or organization. Agile is not a one-size-fits-all approach, which is why tailoring is becoming a trend in the project management space. It is up to your organization and your teams to determine what best practices you can use and which ones simply will not work effectively.

In the next section, I discussed cycle time and value streams. Both are ways to see your process and whether it is working, or if there are areas of improvement that can be made. Speeding up the cycle time without losing quality allows for continuous improvement efforts toward the increment or result being built.

Then I reviewed value stream mapping and how the team can plot out visually all of the steps in the process and identify areas affecting their cycle time and productivity. By identifying unnecessary steps in a visual way, the team can identify necessary adaptations to the process and thereby improve upon it.

In the next section, I reviewed some of the aspects of continuous product improvement with a selected focus on the team dynamic. You have reviewed testing and other aspects of producing quality increments in other chapters. As this guide winds to a close, a focus on the team dynamic is worth mentioning. Training, coaching, and transparent communication is crucial to Agile team success.

Finally, I reviewed intraspectives, premortems, and retrospectives as specific meetings focused on continuous improvements across the entire project—from the product to the process to how the team works together—all designed to be an iterative way to maintain focus on the goal and better ways to attain it.

Exam Essentials

Understand how tailoring your process can help improve your projects. Understand why it is important to know that one size doesn’t fit all; and why, with the variety of project types globally, it is important to identify the need for a tailored approach when applicable.

Understand the concept of cycle time. It’s important to understand cycle time in order to be able to spot areas for improvement and utilize better best practices to improve your value stream.

Be able to explain value stream maps. Value stream maps are visual representations of the flow of your process from the beginning to the end. This allows for the team to comprehend clearly the current state of the process flow, attempt to improve the future state, and develop a plan to implement the improvements.

Be aware of continuous product improvements. Agile frameworks are designed for continuous improvements with very specific meetings and better best practices being implemented right away. Aside from integrated testing and quality management, which I discussed in other chapters, it was important to wrap up the last chapter with a core focus on the team’s role in continuous improvements.

Be aware of intraspectives, premortems, and retrospectives. Agile team interactions are by design excellent ways to look inward and determine the reasons an iteration isn’t progressing the way it should. Intraspectives can be called at any moment when the team performance needs an immediate facelift. Premortems are designed to look into the future and discuss what could go wrong and to strike preemptively to remove future trouble. Finally, retrospectives are a way for the team to look at the performance of the last iteration and make a plan for the next iteration.