Figure X3- Military Messaging Example Table Tailoring Options to Improve Fit Table Attributes of Successful Agile Teams Table Agile Team Roles Table Scrum Events and Artifacts Table A The members of the core writing team who developed this practice guide included volunteers from both organizations, drawing on subject matter expertise from a broad range of current practitioners and leaders from a diverse range of backgrounds, beliefs, and cultures.
This practice guide provides practical guidance geared toward project leaders and team members adapting to an agile approach in planning and executing projects. While our core writing team recognizes there is staunch support to use predictive approaches and conversely, passion around shifting to an agile mindset, values, and principles, this practice guide covers a practical approach to project agility.
This practice guide represents a bridge to understanding the pathway from a predictive approach to an agile approach. In fact, there are similar activities between the two, such as planning, that are handled differently but occur in both environments.
Our core writing team used an agile mindset to collaborate and manage the development of this first edition of the practice guide. As technology and culture changes, future updates and refinements to the practice guide will reflect current approaches. Our core team adopted a more informal, relaxed writing style for this practice guide than is typical for PMI standards.
The guide incorporates new elements, such as tips, sidebars, and case studies to better illustrate key points and concepts. Our team intends for these changes to make this practice guide more readable and user-friendly.
Manufacturing, education, healthcare and other industries are becoming agile to varying degrees and this use beyond software is within the scope of this practice guide. Teachers in middle schools, high schools, and universities around the world are beginning to use agile to create a culture of learning. Agile techniques are used to provide focus on prioritizing competing priorities.
Project teams have used agile techniques and approaches in various forms for at least several decades. The Agile Manifesto [1]1 expressed definitive values and principles of agile as the use of agile gained substantial momentum see Section 2.
Today, project leaders and teams find themselves in an environment disrupted by exponential advances in technology and demands from customers for more immediate delivery of value. Agile techniques and approaches effectively manage disruptive technologies. In addition, the first principle of agile places customer satisfaction as the highest priority and is key in delivering products and services that delight customers see Section 2.
Rapid and transparent customer feedback loops are readily available with the widespread use of social media. Therefore, in order to stay competitive and relevant, organizations can no longer be internally focused but rather need to focus outwardly to the customer experience. Disruptive technologies are rapidly changing the playing field by decreasing the barriers to entry. More mature organizations are increasingly prone to being highly complex and potentially slow to innovate, and lag behind in delivering new solutions to their customers.
This speed of change will continue to drive large organizations to adopt an agile mindset in order to stay competitive and keep their existing market share. Companies across the globe are leveraging the model for quick and cheap access to computing resources and to gain entry into traditional markets.
Cloud computing requires a reduced upfront payment, but is paid over time via a subscription service, based upon a pay-as-you-go or pay-what- you-use model.
Updated applications, infrastructure, and platforms are released into the cloud in an iterative and incremental fashion, keeping pace with improvements to technology and evolving customer demand.
The Agile Practice Guide is project-focused and addresses project life cycle selection, implementing agile, and organizational considerations for agile projects. Organizational change management OCM is essential for implementing or transforming practices but, since OCM is a discipline within itself, it is outside the scope of this practice guide. Additional items that are in scope and out of scope for this practice guide are listed in Table Note that software is included in this practice guide even though the use of agile is growing in many other industries beyond software.
This practice guide provides useful guidance for successful projects that deliver business value to meet customer expectations and needs. This practice guide is organized as follows: Section 2 An Introduction to Agile—This section includes the Agile Manifesto mindset, values, and principles.
It also covers the concepts of definable and high-uncertainty work, and the correlation between lean, the Kanban Method, and agile approaches. Section 3 Life Cycle Selection—This section introduces the various life cycles discussed in this practice guide. This section also addresses suitability filters, tailoring guidelines, and common combinations of approaches.
Section 4 Implementing Agile: Creating an Agile Environment—This section discusses critical factors to consider when creating an agile environment such as servant leadership and team composition.
Section 5 Implementing Agile: Delivering in an Agile Environment—This section includes information on how to organize teams and common practices teams can use for delivering value on a regular basis. It provides examples of empirical measurements for teams and for reporting status. Section 6 Organizational Considerations for Project Agility—This section explores organizational factors that impact the use of agile approaches, such as culture, readiness, business practices, and the role of a PMO.
Section 7 A Call to Action—The call to action requests input for continuous improvement of this practice guide. The annexes, appendixes, references, bibliography, and glossary provide additional useful information and definitions: Annexes. Contain mandatory information that is too lengthy for inclusion in the main body of the practice guide. Contain nonmandatory information that supplements the main body of this practice guide. Identify where to locate standards and other publications that are cited in this practice guide.
Lists additional publications by section that provide detailed information on topics covered in this practice guide.
Presents a list of terms and their definitions that are used in this practice guide. Definable work projects are characterized by clear procedures that have proved successful on similar projects in the past. The production of a car, electrical appliance, or home after the design is complete are examples of definable work. The production domain and processes involved are usually well understood and there are typically low levels of execution uncertainty and risk. New design, problem solving, and not-done-before work is exploratory.
It requires subject matter experts to collaborate and solve problems to create a solution. Examples of people encountering high-uncertainty work include software systems engineers, product designers, doctors, teachers, lawyers, and many problem-solving engineers. As more definable work is automated, project teams are undertaking more high-uncertainty work projects that require the techniques described in this practice guide.
High-uncertainty projects have high rates of change, complexity, and risk. These characteristics can present problems for traditional predictive approaches that aim to determine the bulk of the requirements upfront and control changes through a change request process. Instead, agile approaches were created to explore feasibility in short cycles and quickly adapt based on evaluation and feedback. Twelve clarifying principles flowed from these values as shown in Figure Although originating in the software industry, these principles have since spread to many other industries.
This embodiment of mindset, values, and principles defines what constitutes an agile approach. The various agile approaches in use today share common roots with the agile mindset, value, and principles.
This relationship is shown in Figure As shown in Figure , the model, inspired by Ahmed Sidky, articulates agile as a mindset defined by the Agile Manifesto values, guided by the Agile Manifesto principles, and enabled by various practices. Agile approaches and agile methods are umbrella terms that cover a variety of frameworks and methods. Figure places agile in context and visualizes it as a blanket term, referring to any kind of approach, technique, framework, method, or practice that fulfills the values and principles of the Agile Manifesto.
Figure also shows agile and the Kanban Method as subsets of lean. Any or all of these terms could apply depending on the situation. In general, there are two strategies to fulfill agile values and principles. The first is to adopt a formal agile approach, intentionally designed and proven to achieve desired results. Then take time to learn and understand the agile approaches before changing or tailoring them.
Premature and haphazard tailoring can minimize the effects of the approach and thus limit benefits. See Appendix X2 for Tailoring Considerations. The second strategy is to implement changes to project practices in a manner that fits the project context to achieve progress on a core value or principle. Use timeboxes to create features, or specific techniques to iteratively refine features. Consider dividing up one large project into several releases, if that works for the specific project context.
Implement changes that will help the project succeed— the changes do not need to be part of the organization's formal practices. In other words, lean thinking is a superset, sharing attributes with agile and Kanban.
This shared heritage is very similar and focuses on delivering value, respect for people, minimizing waste, being transparent, adapting to change, and continuously improving.
Project teams sometimes find it useful to blend various methods—whatever works for the organization or team is what should be done regardless of its origin. The objective is the best outcome regardless of the approach used. The Kanban Method is inspired by the original lean-manufacturing system and used specifically for knowledge work.
It emerged in the mids as an alternative to the agile methods that were prevalent at the time. Project teams can begin applying the Kanban Method with relative ease and progress toward other agile approaches if that is what they deem necessary or appropriate.
CASE There is and probably always will be a lot of discussion around the Kanban Method and whether it belongs to the lean or agile movement. It was conceived in and around lean manufacturing, but is widely used in agile settings. These uncertainties can contribute to high rates of change and project complexity. These characteristics are illustrated in Figure As project uncertainty increases, so too does the risk of rework and the need to use a different approach.
To mitigate the impact of these risks, teams select life cycles that allow them to tackle projects with high amounts of uncertainty via small increments of work. Teams can verify their work when they use small increments and can change what they do next. When teams deliver small increments, they are better able to understand the true customer requirements faster and more accurately than with a static written specification.
However, as the uncertainty in the project increases, the likelihood of changes, wasted work, and rework also increases, which is costly and time consuming. Some teams have evolved project life cycles to use iterative and incremental approaches. Many teams discover that when they explore the requirements iteratively and deliver more often incrementally, the teams adapt to changes more easily. These iterative and incremental approaches reduce waste and rework because the teams gain feedback.
These approaches use: Very short feedback loops, Frequent adaptation of process, Reprioritization, Regularly updated plans, and Frequent delivery. TIP What do simple, complicated, and complex projects mean? Consider large projects, such as the Boston Big Dig construction project.
On the surface, the project seemed fairly straightforward: move the elevated highway underground. There was high agreement on the requirements see the Y axis in Figure There was low uncertainty on how the project would proceed until the project started.
And, as is the case for many large projects, the project encountered surprises along the way. When a team works on a project where there is little opportunity for interim deliverables or little opportunity for prototyping, the team most likely will use a predictive life cycle to manage it.
The team can adapt to what it discovers, but will not be able to use agile approaches to manage the iterative discovery of requirements or incremental deliverables for feedback. The Big Dig project was not simple by any means.
However, many projects that start out in the lower left part of the Stacey Complexity Model have no real means of moving to other approaches. Assess the project, both in the requirements and the means of delivery, to determine the best approach for the life cycle of the project.
These iterative, incremental, and agile approaches work well for projects that involve new or novel tools, techniques, materials, or application domains. Refer to Section 3 on Life Cycle Selection. They also work well for projects that: Require research and development; Have high rates of change; Have unclear or unknown requirements, uncertainty, or risk; or Have a final goal that is hard to describe.
By building a small increment and then testing and reviewing it, the team can explore uncertainty at a low cost in a short time, reduce risk, and maximize business value delivery.
This uncertainty may be centered on suitability and requirements is the right product being built? All three of these characteristics— product specification, production capability, and process suitability—typically have elements of high uncertainty. However, iterative and incremental approaches have their limits of applicability. When both technology uncertainty and requirements uncertainty are very high the top right of Figure , the project moves beyond complex to chaotic.
In order for the project to become reliably possible, it needs one of the variables uncertainty or disagreement to be contained. Project teams need awareness of the characteristics and options available to select the approach most likely to be successful for the situation.
This practice guide refers to four types of life cycles, defined as follows: Predictive life cycle. A more traditional approach, with the bulk of planning occurring upfront, then executing in a single pass; a sequential process.
Iterative life cycle. An approach that allows feedback for unfinished work to improve and modify that work. Incremental life cycle. An approach that provides finished deliverables that the customer may be able to use immediately. Agile life cycle.
An approach that is both iterative and incremental to refine work items and deliver frequently. There is no single term that is universally used to describe non-agile approaches. Initially, the practice guide used the term plan-driven to describe the emphasis on an upfront plan and then execution of that plan. Some people prefer the terms waterfall or serial to describe this life cycle.
That is natural, but we still need a way to talk about both ends of the spectrum. If agile is at one end, we call the other end predictive. It is important to note that all projects have these characteristics—no project is completely devoid of considerations around requirements, delivery, change, and goals.
A project's inherent characteristics determine which life cycle is the best fit for that project. Another way to understand how project life cycles vary is by using a continuum ranging from predictive cycles on one end, to agile cycles on the other end, with more iterative or incremental cycles in the middle. This view emphasizes the shifting of project characteristics from one end to the other.
Another way to visualize the continuum is with a two-dimensional square, as shown in Figure No life cycle can be perfect for all projects. Instead, each project finds a spot on the continuum that provides an optimum balance of characteristics for its context. Specifically, Predictive life cycles. Take advantage of things that are known and proven. This reduced uncertainty and complexity allows teams to segment work into a sequence of predictable groupings.
Iterative life cycles. Allow feedback on partially completed or unfinished work to improve and modify that work. Incremental life cycles. Provide finished deliverables that the customer may be able to use immediately.
Agile life cycles. Leverage both the aspects of iterative and incremental characteristics. When teams use agile approaches, they iterate over the product to create finished deliverables.
Because the team can release earlier, the project may provide an earlier return on investment because the team delivers the highest value work first. What differentiates a life cycle is not whether planning is done, but rather how much planning is done and when. At the predictive end of the continuum, the plan drives the work. As much planning as is possible is performed upfront.
Requirements are identified in as much detail as possible. The team estimates when they can deliver which deliverables and performs comprehensive procurement activities. In iterative approaches, prototypes and proofs are also planned, but the outputs are intended to modify the plans created in the beginning.
Earlier reviews of unfinished work help inform future project work. Meanwhile, incremental initiatives plan to deliver successive subsets of the overall project. Teams may plan several successive deliveries in advance or only one at a time.
The deliveries inform the future project work. Agile projects also plan. The key difference is that the team plans and replans as more information becomes available from review of frequent deliveries. Regardless of the project life cycle, the project requires planning. As a result, project activities often execute in a serial manner, as shown in Figure In order to achieve this approach, the team requires detailed plans to know what to deliver and how.
These projects succeed when other potential changes are restricted e. Team leaders aim to minimize change for the predictive project.
When the team creates detailed requirements and plans at the beginning of the project, they can articulate the constraints. As the team progresses through the detailed plan, they monitor and control changes that might affect the scope, schedule, or budget. By emphasizing a departmentally efficient, serialized sequence of work, predictive projects do not typically deliver business value until the end of the project.
If the predictive project encounters changes or disagreements with the requirements, or if the technological solution is no longer straightforward, the predictive project will incur unanticipated costs. Each new prototype yields new stakeholder feedback and team insights.
Then, the team incorporates the new information by repeating one or more project activities in the next cycle. Teams may use timeboxing on a given iteration for a few weeks, gather insights, and then rework the activity based on those insights. In that way, iterations help identify and reduce uncertainty in the project.
Iterative life cycles may take longer because they are optimized for learning rather than speed of delivery. Figure illustrates some elements of an iterative project life cycle for a single product delivery. A prototype encourages feedback and a better understanding of the requirements that can be incorporated into each deliverable. Many businesses and initiatives cannot afford to wait for everything to be completed; in these cases, customers are willing to receive a subset of the overall solution.
This frequent delivery of smaller deliverables is called an incremental life cycle see Figure TIP Are you unsure of how a new business service might work in practice? Create a proof of concept with evaluation criteria to explore desired outcomes.
Use iterative approaches when you suspect the requirements will change based on customer feedback. Incremental life cycles optimize work for delivering value to sponsors or customers more often than a single, final product. Teams plan initial deliverables before beginning their work, and they begin working on that first delivery as soon as possible.
Some agile projects deliver value within days of project initiation. Others could take longer, ranging from 1 week to several weeks. As the project continues, the team may deviate from the original vision.
The team can manage the deviations, because the team delivers value sooner. The degree of change and variation is less important than ensuring customers get value sooner than at the end of the project. Completeness and delivery are subjective. The team may need feedback on a prototype and may then choose to deliver a minimum viable product MVP to a subset of customers. Agile teams, as a key differentiator, deliver business value often. As the product adds a broader set of features and a broader range of consumers, we say it is delivered incrementally.
Providing a customer a single feature or a finished piece of work is an example of the incremental approach. For example, builders may want to show a finished room or floor of a building before they continue with the remainder of the building. In that case, they may complete a floor with fixtures, paint, and everything else intended for the finished floor before proceeding to the next floor.
The customer is able to see and approve of the style, color, and other details, allowing adjustments to be made before further investments of time and money are made. The iterative and incremental approaches provide feedback to better plan the next part of the project. However, in agile projects, incremental delivery uncovers hidden or misunderstood requirements.
Figure illustrates two possible ways to achieve incremental delivery so the project aligns with customer needs and can be adapted as necessary. In iteration-based agile, the team works in iterations timeboxes of equal duration to deliver completed features. The team works on the most important feature, collaborating as a team to finish it.
Then the team works on the next most important feature and finishes it. The team may decide to work on a few features at a time, but the team does not address all of the work for the iteration at once i. In flow-based agile, the team pulls features from the backlog based on its capacity to start work rather than on an iteration-based schedule.
The team defines its workflow with columns on a task board and manages the work in progress for each column. Each feature may take a different amount of time to finish. Teams keep work-in-progress sizes small to better identify issues early and reduce rework should changes be required. Without iterations to define planning and review points, the team and business stakeholders determine the most appropriate schedule for planning, product reviews, and retrospectives.
Agile life cycles are those that fulfill the principles of the Agile Manifesto. In particular, customer satisfaction increases with early and continuous delivery of valuable products. Moreover, an incremental deliverable that is functional and provides value is the primary measure of progress. Agile life cycles combine both iterative and incremental approaches in order to adapt to high degrees of change and deliver project value more often.
These models assess project and organizational factors associated with adoption and suitability and then provide scores indicating alignment or potential risk areas. Appendix X3 provides a synthesis of popular assessment models for use as an agile suitability filter.
Food and Drug Administration FDA approval process tagged onto the end of its development process and its entire life cycle looked like Figure While project teams undertook drug trials in an agile fashion, they had to present the drugs to an external group to perform the FDA approval process. A consultant helped to integrate the FDA approval process portion into the agile development process to create a more streamlined hybrid approach.
The short version of the story is that because FDA approval is required to be completed at the end of the development process or repeated after any change this includes even after the most minor change , the process had to remain at the end as a separate phase. Integration using the iterative process was unsuccessful.
Projects often combine elements of different life cycles in order to achieve certain goals. Figure depicts the basic, pure approaches to project types that combine to form a hybrid model. The early processes utilize an agile development life cycle, which is then followed by a predictive rollout phase.
This approach can be used when there is uncertainty, complexity, and risk in the development portion of the project that would benefit from an agile approach, followed by a defined, repeatable rollout phase that is appropriate to undertake in a predictive way, perhaps by a different team. An example of this approach is the development of a new high-tech product followed by rollout and training to thousands of users. In Figure , a combination of both predictive and agile approaches are used in the same project.
Using both predictive and agile approaches is a common scenario. It would be misleading to call the approach agile since it clearly does not fully embody the agile mindset, values, and principles.
However, it would also be inaccurate to call it predictive since it is a hybrid approach. In this case, a portion of the project with uncertainty, complexity, or opportunity for scope creep is being tackled in an agile way, but the remainder of the project is being managed using predictive approaches.
An example of this approach would be an engineering firm that is building a facility with a new component. While the majority of the project may be routine and predictable, like many other facility projects the organization has undertaken before, this project incorporates a new roofing material. The contractor may plan for some small- scale installation trials on the ground first to determine the best installation method and to uncover issues early while there is plenty of time to solve them and incrementally improve processes through experimentation and adaptation.
This approach might be used when a particular element is non-negotiable or not executable using an agile approach. Examples include integrating an external component developed by a different vendor that cannot or will not partner in a collaborative or incremental way. A single integration is required after the component is delivered. A government department had a credit insurance application development project. The multi-year project was to replace its aging underwriting system with a new, more responsive user interface and system integrations.
The bulk of the project was undertaken using an agile approach with continual business input. The steps were very clearly explained with little opportunity for confusion or interim result confirmation by the business and were coded up by a separate team working its way through the calculation steps.
The two teams collaborated on the input variables required for the calculation and how to consume and display the output values, but beyond that, the calculation team worked in a largely predictive manner. When the calculation team's portion was complete, the outputs from the premium rate calculations were displayed on the screens and in the reports.
Then the business users provided feedback on the appearance and use of the information. The two teams ran concurrently, but had little need for interaction. Having them physically close to each other made it easier to check in on development progress, but largely they were separate subprojects.
For example, a campus construction project may have multiple buildings to improve and build. An incremental approach would focus resources on completing some buildings earlier than others, accelerating the return on investment. Each individual delivery may be sufficiently well known to benefit from a predictive life cycle for that building alone.
The goal of project management is to produce business value in the best possible way given the current environment. If so, increments will help. Is it necessary to manage risk as ideas are explored? If so, iterations or agile will help. When the organization cannot deliver intermediate value, agile approaches may not be useful. That is okay—agile for the sake of agile is not the goal. The point is to select a life cycle or a combination of life cycles that work for the project, the risks, and the culture.
Agile is about customer-based delivery on a frequent basis. That delivery creates feedback for the team. The team uses that feedback to plan and replan the next chunk of work. Agile techniques look and feel very different to those who are accustomed to and have been successful in a predictive environment.
The larger the organization and the more moving parts, the longer it will take to transition. For that reason, it makes sense to plan a gradual transition. A gradual transition involves adding more iterative techniques to improve learning and alignment among teams and stakeholders.
Later, consider adding more incremental techniques to accelerate value and return on investment to sponsors. This combination of various approaches is considered a hybrid approach. Try these new techniques on a less risky project with a medium-to low-degree of uncertainty.
Then, when the organization is successful with a hybrid approach, try more complex projects that require more of those techniques to be added. This is a way to tailor the progressive hybrid transition to the organization's situation and specific risks and the team's readiness to adapt and embrace the changes.
Agile frameworks are not customized for the team. The team may need to tailor practices to deliver value on a regular basis. Often, teams practice their own special blend of agile, even if they use a particular framework as a starting point.
Scrum provides guidance on the use of a product backlog, a product owner, scrum master, and a cross-functional development team, including sprint planning, daily scrum, sprint review, and sprint retrospective sessions. A kanban board helps the team to further improve its effectiveness by visualizing the flow of work, making impediments easily visible, and allowing flow to be managed by adjusting work in process limits.
In addition, XP-inspired engineering practices such as use of story cards, continuous integration, refactoring, automated testing, and test-driven development further increase the effectiveness of the agile team. In summary, the blend of practices from these various sources produces a synergistic result of higher performance than each individual component in isolation. Table identifies some project factors and tailoring options to consider.
Tailoring Options to Improve Fit Project Factor Tailoring Options Demand pattern: steady or sporadic Many teams find that using a cadence in the form of a regular timebox helps them demo, retrospect, and take in new work. Teams can use flow- based agile with a cadence to get the best of both worlds. Rate of process improvement required by the Retrospect more often and select improvements. The quality of the product increments is poor Consider using the various test-driven development practices.
This mistake-proofing discipline makes it difficult for defects to remain undetected. More than one team is needed to build a product To scale from one to several agile teams, with minimal disruption, first learn about agile program management or formal scaling frameworks. Then, craft an approach that fits the project context. The project team members are inexperienced in Consider starting by training team members in the use of agile approaches the fundamentals of the agile mindset and principles.
If the team decides to use a specific approach such as Scrum or Kanban, provide a workshop on that approach so the team members can learn how to use it. For additional guidance on factors that influence tailoring see Appendix X2 on Attributes that Influence Tailoring.
The answers to the following questions will help to develop an implementation strategy: How can the project team act in an agile manner? What can the team deliver quickly and obtain early feedback to benefit the next delivery cycle?
How can the team act in a transparent manner? What work can be avoided in order to focus on high-priority items? How can a servant-leadership approach benefit the achievement of the team's goals? Servant leadership is the practice of leading through service to the team, by focusing on understanding and addressing the needs and development of team members in order to enable the highest possible team performance.
The role of a servant leader is to facilitate the team's discovery and definition of agile. Servant leaders practice and radiate agile. The entire team optimizes at the project level, not the person level. Once the purpose is established, encourage the team to create an environment where everyone can succeed. Ask each team member to contribute across the project work. When a cross-functional team delivers finished value often and reflects on the product and process, the teams are agile.
It does not matter what the team calls its process. The following characteristics of servant leadership enable project leaders to become more agile and facilitate the team's success: Promoting self-awareness; Listening; Serving those on the team; Helping people grow; Coaching vs.
Servant leadership is not unique to agile. But once having practiced it, servant leaders can usually see how well servant leadership integrates into the agile mindset and value. When leaders develop their servant leadership or facilitative skills, they are more likely to become agile. As a result, servant leaders can help their teams collaborate to deliver value faster.
Successful agile teams embrace the growth mindset, where people believe they can learn new skills. When the team and the servant leaders believe they can all learn, everyone becomes more capable. These relationships help the leaders navigate the organization to support the team. This kind of support helps to remove impediments and facilitates the team to streamline its processes. Because servant leaders understand agile and practice a specific approach to agile, they can assist in fulfilling the team's needs.
Facilitators encourage the team's participation, understanding, and shared responsibility for the team's output.
Business value is a major part of our guide. You will encounter this concept throughout the book. Human resources are included in our principles because without proper people management in the organization, progress and business value are lacking. Lastly, we included exemplary organizational priorities that every modern professional should know about. The following project manager activities are described in detail in our book as part of the responsibilities of responsible professionals.
Document management is about eliminating unnecessary documentation and creating effective, easy, concise, and useful information for teams.
In doing so, BVOP. In today's world, product-oriented organizations are a major part of the business worldwide, and dynamic and innovative products are now a major part of our lives and our work. Range management is focused not on stitching the range. Project planning, however, remains a classic project manager activity. However, for interesting details, read the book. We have added new practices that can significantly reduce risks and save huge costs for organizations.
BVOP offers relative time estimation practices and recommends all current Agile practices on the topic. Waste management is another major and important topic throughout BVOP's teaching. We have added Waste management to the activities and responsibilities of the modern project manager. Eliminating waste is a real business value-added venture. The project manager should make decisions instead of passively monitoring the project.
That is why we have added this topic to our book. In the implementation of the projects, we have included interesting and surprising details that every modern project manager should pay attention to. A project manager as a role that is close to the teams can have a direct influence on their attitude.
Tens of thousands of organizations around the world create products and work on projects. Our team intends for these changes to make this practice guide more readable and user-friendly. This practice guide goes beyond addressing the use of agile in the computer software development industry, because agile has expanded into non-software development environments.
Manufacturing, education, healthcare and other industries are becoming agile to varying degrees and this use beyond software is within the scope of this practice guide.
Get the book. Get this book with discount. Alex W. Putz Massachusetts.
0コメント