INTRODUCTION TO PMI-ACP - PMTUTOR · INTRODUCTION TO PMI-ACP . ... The Project Management Institute...

1 www.pmtutor.org Powered by POeT Solvers Limited

INTRODUCTION TO PMI-ACP


PMI-ACP CONTENT BREAKDOWN

The Project Management Institute provides an examination content outline regarding PMI-ACP on its website (www.pmi.org). This document describes what topics the exam covers and breaks down the content into domains, knowledge and skills (K & Ss), and tools and techniques (T & Ts). The breakdown is valuable in creating a logical framework to group the concepts, so it is easier to understand the principles and how the topics are related to each other.

http://www.pmi.org/



DOMAINS

The Agile Concepts are grouped into six (6) domains:

1. Value-Driven Delivery

This domain focuses on maximizing business value through prioritization, iterative delivery, and risk management.

2. Stakeholder Engagement This domain deals with understanding stakeholder needs, getting stakeholders involved, and keeping them informed.



3. Boosting Team Performance Practices

This domain links team-related topics, including forming teams, empowering them, building team commitment, and promoting collaboration.

4. Adaptive Planning

This domain deals with estimating, creating different levels of plans, getting feedback on progress, and updating plans.

5. Problem Detection and Resolution

This domain is concerned with encouraging whole-team tracking and resolution of risks.



6. Continuous Improvement

This domain deals with how to improve various aspects of the project – including its product, processes, and people – via retrospectives and experiments.

Each domain is associated with its unique tools and techniques as well as knowledge and skills.



KNOWLEDGE AND SKILLS

The Knowledge and Skills unit is broken down into three levels: LEVEL 1: There are 18 Knowledge and Skills in this level. These

are deemed the most important knowledge and skills concept to know. They are:

Active listening

Agile Manifesto values and principles

Assessing and incorporating community and stakeholder values

Brainstorming techniques

Building empowered teams

Coaching and mentoring within teams



Communications management

Feedback techniques for products

Incremental delivery

Knowledge sharing

Leadership

Prioritization

Problem Solving

Project and quality standards for agile projects

Stakeholder management

Team motivation

Time, budget, and cost estimation

Value-based decomposition and prioritization



LEVEL 2: There are 12 Knowledge and Skills in this level. They

are:

Agile Frameworks and terminology

Building high-performance teams

Business case development

Co-location and geographically dispersed teams

Continuous improvement processes

Elements of a project charter for an agile project

Facilitation methods

Participatory decision models

PMI’s Code of Ethics and Professional Conduct

Process analysis

Self-assessment

Value-based analysis


PMI-ACP CONTENT BREAKDOWN LEVEL 3: There are 13 Knowledge and Skills in this level. They

are: Agile contracting methods

Agile project accounting principles

Applying new agile practices

Compliance (organization)

Control limits for agile projects

Failure modes and alternatives

Globalization, culture, and team diversity

Agile games

Principles of systems thinking

Regulatory compliance

Variance and trend analysis

Variation in agile methods and approaches

Vendor management



TOOLS AND TECHNIQUES

These are activities one should be able to do and apply as it fits each domain. These will be introduced as each domain is discussed in detail.


AGILE FRAMEWORK


AGILE METHODS – WHY? Different types of projects require different methods. In our everyday lives, we customize our approach to different situations. This is because we want our different approaches to each unique situation to be effective. In essence, some projects call for an agile approach instead of the traditional project management approach especially projects occurring in fast-moving or time-constrained environments.


THE AGILE MANIFESTO The Agile manifesto reads as follows: Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interaction over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.


THE AGILE MANIFESTO The format of ‘A over B’, such as ‘Individuals and interactions

over processes and tools,’ addresses intention, focus, and effort. It acknowledges that A and B will likely both exist on projects, but more focus, emphasis, and intention should be applied to A. NOTE: Although the Agile Manifesto uses software development

terms, the concepts also apply to other types of knowledge worker* projects. *Knowledge workers are people with subject matter expertise who communicate

their knowledge and take part in analysis and/or development efforts. Knowledge workers are not only found in IT industry; they are also engineers, teachers, scientists, lawyers, doctors, etc.


THE FOUR AGILE MANIFESTO VALUES

1) INDIVIDUALS AND INTERACTIONS OVER PROCESSES

AND TOOLS: More focus is given to individuals and interactions because projects are undertaken by people, not tools, and problems get solved by people, not processes. Likewise, projects are accepted by people, scope is debated by people, and the definition of a successfully “done” project is negotiated by people. So, focusing early on developing the individuals involved in the project and emphasizing productive and effective interactions help set up a project for success. If you tend toward processes rather than people, the first value of “individuals and interactions over processes and tools” is a great reminder of where to focus your time, energy and passion.



2) WORKING SOFTWARE OVER COMPREHENSIVE

DOCUMENTATION: This value speaks to the need to deliver. Many software developers are detail-oriented and process-driven; although these characteristics are often highly beneficial, they can also mean the developers’ focus can easily be distracted from the real reason they are undertaking software projects – to write valuable software. So the Agile Manifesto’s emphasis on valuing working software over comprehensive documentation acts as a necessary and useful reminder of why these projects are commissioned in the first place – to build something useful. Documentation by itself, or at the expense of working software, is not useful.



3) CUSTOMER COLLABORATION OVER CONTRACT

NEGOTIATION: This value reminds us to be flexible and accommodating, rather than fixed and uncooperative. We could build the product exactly as originally specified, but if the customer changes their mind or priority, it would be better to be flexible and work toward the new goal, as opposed to the goal that was originally stated. Rather than beat up the client with a change management process that is really more of a change suppression process, we should recognize at the start that things are going to change, and we should work with the customer throughout the project toward a shared definition of “done”. This requires a more trusting relationship and more flexible contract models than we often see on projects, but it again moves the emphasis from nonvalue-adding activities (like arguing about scope) to productive work.



4) RESPONDING TO CHANGE OVER FOLLOWING A PLAN:

The importance of responding to change over following a plan is to acknowledge that the initial plans were made when we knew least about the project (at the beginning), and as the work progresses, it is thereby necessary to update the plan. Agile projects have highly visible queues of work and plans in the form of backlogs and task boards. The intent of this agile value is to broaden the number of people who can be readily engaged in the planning process, adjust plans, and discuss the impacts of changes.


THE AGILE MANIFESTO

The Agile Manifesto is not a set of rules telling us to do one thing instead of another rather it guides us to consider projects from a value-based perspective. Although we will need processes, tools, documentation, and plans on our projects; Agility is the capacity to execute projects while focusing our efforts on the items on the left side of these value statements, rather than those on the right.


THE TWELVE GUIDING PRINCIPLES BEHIND THE AGILE MANIFESTO

1) OUR HIGHEST PRIORITY IS TO SATISFY THE CUSTOMER THROUGH EARLY AND CONTINUOUS DELIVERY OF VALUABLE SOFTWARE.

There are three key points in this principle. The first is to satisfy the customer. The focus should be on the customer. The second point is early and continuous delivery. This is to enable those working on the project to learn of problems while there is still time to fix them rather than discover issues much later when so much more has been built on top of a faulty foundation. The last point is that what we are delivering is valuable software. The focus is on the end goal. For software projects, this is the software; for other types of projects, the end goal will be the product or service that the project was undertaken to deliver or enhance.



2) WELCOME CHANGING REQUIREMENTS, EVEN LATE IN DEVELOPMENT. AGILE PROCESSES HARNESS CHANGE FOR THE CUSTOMER’S COMPETITIVE ADVANTAGE.

Change management approach used in many traditional projects is problematic for software projects or for any type of project that experiences high rates of change. In contrast, agile project management accepts that changes will occur. Instead of creating a high-overhead mechanism for processing changes, agile methods use a lightweight, high-visibility approach for prioritizing the changes into the backlog of work to be done. Rather than suppressing changes, agile methods work to create a well-understood, high-visibility way of handling changes that keeps the project adaptive and flexible as long as possible.



3) DELIVER WORKING SOFTWARE FREQUENTLY, FROM A COUPLE OF WEEKS TO A COUPLE OF MONTHS, WITH A PREFERENCE TO THE SHORTER TIMESCALE.

This principle emphasizes the importance of releasing work to a test environment and getting feedback. Agile teams need feedback on what they have created thus far to see if they can proceed, or if a change of course is needed. Delivering within a short timeframe also has the benefit of keeping the business engaged and keeping dialogue about the project going. With frequent deliveries, the project team regularly has results to show the business and has opportunities to get feedback. Often at these demos, the team learns of new requirements or changes in business priorities that are valuable planning inputs.



4) BUSINESS PEOPLE AND DEVELOPERS MUST WORK TOGETHER DAILY THROUGHOUT THE PROJECT.

By working with business representatives daily, the development team learns

about the business in a way that is far beyond what a collection of requirements-gathering meetings can ever achieve. As a result, the development team is better able to suggest solutions and alternatives to business requests. The business

representatives also learn what types of solutions are expensive or slow to develop, and what features are cheap. They can then begin to fine-tune their requests in response.

When it isn’t possible to have daily interactions between the business representatives and the development team, agile methods try to get the two

groups working together regularly in some way, perhaps every two days or whatever type of frequent involvement will work. Some teams use a “proxy customer,” in which an experienced business analyst (BA) who is familiar with the

business interests serves as a substitute, but this is not an ideal option.



5) BUILD PROJECTS AROUND MOTIVATED INDIVIDUALS. GIVE THEM THE ENVIRONMENT AND SUPPORT THEY NEED, AND TRUST THEM TO GET THE JOB DONE.

Having motivated and smart people on the team can make the biggest difference in whether a project will be delivered successfully and efficiently.

While we may not always be able to pick our dream team, we can do our part to try to motivate our team members. Since the team is such an important factor on

the project, agile methods promote empowered teams. People work better when they are given the autonomy to organize and plan their own work. Agile methods advocate freeing the team from the micromanagement of completing tasks on a

Gnatt chart. Instead, the emphasis is on craftsmanship, peer collaboration, and teamwork, which result in higher rates of productivity.

As project managers, this does not mean that we abandon involvement with our team; instead, we recognize the team members as experts in what they do and provide the support they need to ensure they are successful.



6) THE MOST EFFICIENT AND EFFECTIVE METHOD OF CONVEYING INFORMATION TO AND WITHIN A DEVELOPMENT TEAM IS FACE-TO-FACE CONVERSATION.

Face-to-face communications allow us to quickly transfer a lot of information and also convey emotion and body language. With face-to-face conversations, questions can be immediately answered instead of “parked” with the hope that there will be a follow-up explanation or the answer will become clear later. Of course, this recommendation for face-to-face conversations cannot be applied to all communications, but it should be followed whenever possible.



7) WORKING SOFTWARE IS THE PRIMARY MEASURE OF PROGRESS.

By adopting “working software” as the primary measure of progress, we immediately promote working software as the project focus, and efforts to create documentation and designs become a supporting rather than primary activity. This emphasis on “working” software helps ensure the team gets acceptance of features, rather than marking items as “completed development” when they have not yet been accepted. The end goal of the project – a product that can be used by the business – remains the project focus.



8) AGILE PROCESSES PROMOTE SUSTAINABLE DEVELOPMENT. THE SPONSORS, DEVELOPERS, AND USERS SHOULD BE ABLE TO MAINTAIN A CONSTANT PACE INDEFINITELY.

Agile methods strive to maximize value over the long term. So instead of long, intense development periods, agile methods recognize the value of maintaining a

sustainable pace that allows team members to have a work-life balance. Not only is a sustainable pace better for the team, but it benefits the organization

as well. Long workdays lead to people resigning, and then the organization loses talent and domain knowledge. Hiring and integrating new members into a team is a slow and expensive process.

Therefore, working at a pace that can be maintained indefinitely creates a happier and more productive team.



9) CONTINUOUS ATTENTION TO TECHNICAL EXCELLENCE AND GOOD DESIGN ENHANCES AGILITY.

Technical excellence and good design allow the product or development team to understand and update the design easily. A project needs to balance its efforts of delivering high-value features with giving continuous attention to the design of the solutions. This balance allows a system to deliver long-term value without becoming difficult to maintain, change, or extend.



10) SIMPLICITY – THE ART OF MAXIMIZING THE AMOUNT OF WORK NOT DONE – IS ESSENTIAL.

Because so many features that are built are never actually used, and because complex systems have an increased potential to be unreliable, agile methods

focus on simplicity. This means boiling down requirements to the essential elements only.

Complex projects take longer to complete, are exposed to a longer horizon of risk, and have more potential failure points and opportunities for cost overruns. Therefore, agile methods seek the ‘simplest thing that could possibly work’ and

recommend that this solution be built first. This approach is not intended to prevent further extension and elaboration of a

product – instead, it is simply saying, “Let’s build the basic version first”. This approach not only mitigates risk but also helps boost sponsor confidence.



11) THE BEST ARCHITECTURES, REQUIREMENTS, AND DESIGNS EMERGE FROM SELF-ORGANIZING TEAMS.

This principle is saying that to get the best out of people, we have to let them self-organize. People like self-organizing; it allows them to find an approach that works best for their methods, their relationships, and their environment. They

thoroughly understand and support the approach, because they help create it. As a result, they produce better work.

Self-organizing teams with the autonomy to make decisions have a higher level of ownership and pride in the architectures, requirements, and designs they create than in those that are forced on them or “suggested” from external

sources. So instead of trying to educate external resources about the evolving structure of

the project, agile methods leverage the capacity of the team to best diagnose and improve the architectures, requirements, and designs. After all, the team members are the most informed about the project and have the most vested in it.



12) AT REGULAR INTERVALS, THE TEAM REFLECTS ON HOW TO BECOME MORE EFFECTIVE, THEN TUNES AND ADJUSTS ITS BEHAVIOR ACCORDINGLY.

Instead of gathering lessons learned at the end of a project, we need to gather lessons learned while they are still applicable and actionable. This means we need to gather them during the project and – most importantly – make sure we do something about what we have learned to adjust how we complete work on the remainder of the project. Agile projects employ frequent reviews or “lookbacks,” called retrospectives, to reflect on how things are working on the project and to identify opportunities for improvements. These retrospectives are typically done at the end of each iteration. This means there are many retrospectives on each project. One advantage of doing retrospectives so frequently is that the details do not get forgotten.


AGILE METHODS There are over a dozen actively used agile methodologies. The common ones are Scrum, Extreme Programming (XP), Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), and the Crystal family of methods (i.e., Crystal Clear, Crystal Yellow, Crystal Orange, etc.). Other related methods include lean software development and Kanban development. The two most widely used agile methods are Scrum and XP. SCRUM The methodology documented in the “Scrum framework” is a set of team guidance practices, roles, events, artifacts, and rules to execute projects by. The theory behind Scrum is based on the three pillars of Transparency, Inspection, and Adaptation:


AGILE METHODS

TRANSPARENCY: This pillar involves giving visibility to those responsible for the outcome. E.g. creating a common definition of what “done” means, to ensure that all

stakeholders are in agreement.

INSPECTION: This pillar involves timely checks on how well a project is progressing

toward its goals, looking for problematic deviations or differences from the goals.

ADAPTATION: This pillar involves adjusting a process to minimize further issues if an

inspection shows a problem or undesirable trend.

These three pillars guide all aspects of Scrum projects, but there are also four planned

opportunities for Inspection and Adaptation within the Scrum framework:

Sprint retrospective

Daily Scrum meeting Sprint review meeting Sprint planning meeting


AGILE METHODS SCRUM TEAMS Scrum teams are made up of the development team, a product owner, and a ScrumMaster. DEVELOPMENT TEAM: The development team is the group of professionals who build the product increments in each iteration, or “sprint” as it is termed in the Scrum methodology. The team consists of people who can fulfill all the roles needed to complete the work (e.g., analysis, build, and test). PRODUCT OWNER: The product owner is responsible for maximizing the value of the product. This person’s sole responsibility is managing the product backlog, including its prioritization, accuracy, shared understanding, value, and visibility. SCRUMMASTER: The ScrumMaster is responsible for ensuring that Scrum is understood and used.


AGILE METHODS

SCRUM EVENTS There are several different types of activities or events the Scrum methodology refers to: Sprints, Sprint planning meetings, Daily scrums, Sprint review meetings, and sprint retrospectives.

SPRINTS: A sprint is a time-limited iteration of one month or less to build a potentially releasable product. Each sprint is like a miniproject. During the sprint, no changes are made that would affect the sprint goal. SPRINT PLANNING MEETING: A sprint planning meeting is used to determine what will be delivered in that sprint and how the work will be achieved.


AGILE METHODS

SCRUM EVENTS CONTD DAILY SCRUM: The daily scrum is a 15-minute time-limited daily meeting. During this meeting, the development team synchronizes activities, communicates, and raises issues. It is held at the same place and time, and each development team member provides answers to the following three questions about the work he or she is doing during the sprint:

1. What has been achieved since the last meeting? 2. What will be done before the next meeting? 3. What obstacles are in the way?

The daily scrum is used to assess progress toward the sprint goal. The ScrumMaster makes sure these meetings happen and helps remove any identified obstacles.


AGILE METHODS

SCRUM EVENTS CONTD

SPRINT REVIEW: A sprint review is a meeting held at the end of the sprint to inspect the increment, or evolving product, that was built. SPRINT RETROSPECTIVE: At the end of the sprint, the team holds a sprint retrospective to reflect on the process and look for opportunities for improvement. The retrospective occurs after the sprint review and before the next sprint planning meeting.


AGILE METHODS SOME SCRUM LANGUAGE DEFINITIONS

PRODUCT BACKLOG: The product backlog is the ordered list of everything that might be needed for the product. It serves as the single source for requirements. This backlog is dynamic and evolves as the product evolves. It contains features to be built, functions, requirements, quality attributes (often referred to as non-functional requirements), enhancements, and fixes.

“Grooming” the product backlog is the process of adding more detail and order to the backlog and refining the estimates of the backlog items.

SPRINT BACKLOG: The sprint backlog is the set of items from the product backlog that were selected for a specific sprint. The sprint backlog is accompanied by a plan of how to achieve the sprint goal.

DEFINITION OF “DONE”: When a backlog item is described as done, everyone must be in agreement about what “done” means. Therefore, the team should collectively create the definition of done for the items before they begin work on them.


AGILE METHODS

EXTREME PROGRAMMING (XP) Extreme Programming is a software-development-centric agile method. While Scrum at the project management level focuses on prioritizing work and getting feedback, XP focuses on software development good practices. The core values of this methodology are simplicity, communication, feedback, courage, and respect, and these values manifest themselves in the practices undertaken throughout the XP life cycle.

SIMPLICITY: This value focuses on reducing complexity, extra features, and waste. COMMUNICATION: This value focuses on making sure all the team members know

what is expected of them and what other people are working on.

FEEDBACK: The team should get impressions of suitability early. COURAGE: It takes courage to allow our work to be entirely visible to others. In pair

programming, team members share code and often need to make bold simplifications

and changes to that code. RESPECT: Respect is essential on XP projects where people work together as a team

and everyone is accountable for the success or failure of the project.


AGILE METHODS

EXTREME PROGRAMMING (XP) contd In XP, lightweight requirements known as “user stories” are used in planning releases and iterations. Iterations are typically two weeks long, and developers work in pairs to write code during these iterations. “Architectural spikes” are iterations used to prove a technological approach, and “spikes” are periods of work undertaken to reduce risks. The spikes are blended into the release planning processes.


AGILE METHODS

XP PRACTICES

The XP method exercises a number of simple but powerful core practices.

Fig. 1: XP Core Practices

Whole team

Collective Code Ownership

Test-driven development

• Planning Games

• Small Releases

• Customer Tests

• Code Standards

• Sustainable Pace

• Metaphor

• Continuous Integration

• Refactoring

• Simple Design

• Pair Programming


AGILE METHODS

XP PRACTICES CONTD WHOLE TEAM: The whole team practice is the idea that all the contributions to an XP project sit together in the same location, as members of a single team. The team includes a “customer” – a business representative who provides the requirements, priorities, and business direction for the project; developers and usually quality assurance (QA) and business analysis (BA) people; a coach who helps keep the team on track and guides the process; and a manager who facilitates external communications and coordinates the team’s activities. PLANNING GAMES: XP has two primary planning activities, or planning games – release planning and iteration planning. A release is a push of new functionality all the way to the production user. A project typically

has one or more releases, with no more than one or two releases happening in a single year. During release planning, the customer outlines the functionality required, and the developers estimate how difficult the functionality will be to build.


AGILE METHODS

XP PRACTICES CONTD Iterations are the short development cycles within a release that Scrum calls ‘sprints’. Iteration planning is done at the start of every iteration, or every two weeks. The customer explains what functionality they would like to see in the next two weeks, and then the

developers break this functionality into tasks and estimate the work.

SMALL RELEASES: Frequent, small releases to test environments are encouraged in XP, both at the iteration level to demonstrate progress and increase visibility for the customer, and at the release level to rapidly deploy working software to the target audience. CUSTOMER TESTS: The customer describes one or more tests to show that the software is working. The team then builds automated tests to prove to themselves and the customer that the software is working.


AGILE METHODS

XP PRACTICES CONTD COLLECTIVE CODE OWNERSHIP: This means multiple people work on all the code, which results in increased visibility and knowledge of the code base. Therefore, any pair of developers can improve or amend any code. CODE STANDARDS: XP teams follow a consistent coding standard so that all the code looks as if it has been written by a single, knowledgeable programmer. SUSTAINABLE PACE: XP recognizes that the highest level of productivity is achieved by a team operating at a sustainable pace. While periods of overtime might be necessary, repeated long hours of work are unsustainable and counterproductive. METAPHOR: XP uses metaphors and similes to explain designs and create a shared technical vision. These descriptions establish comparisons that all the stakeholders can understand to help explain how the system should work.


AGILE METHODS

XP PRACTICES CONTD CONTINUOUS INTEGRATION: Integration involves bringing the code together and making sure it all complies and works together. TEST-DRIVEN DEVELOPMENT: To ensure good test coverage so that problems can be highlighted early in development, XP teams often use the practice of test-driven development. With this approach, the team writes tests prior to developing the new code. The test-driven development process strives to shorten the test-feedback cycle as much as possible to get the benefits of early feedback. REFACTORING: Refactoring is the process of improving the design of existing code without altering the external behavior or adding new functionality. It focuses on removing duplicated code, lowering coupling (dependent connections between code modules), and increasing cohesion. SIMPLE DESIGN: By focusing on keeping the design simple but adequate, XP teams can develop code quickly and adapt it as necessary.


AGILE METHODS

XP PRACTICES CONTD PAIR PROGRAMMING: In XP, production code is written by two developers working as a pair to write and provide real-time reviews of the software as it emerges. This saves time because the pairs catch issues early. Working in pairs also helps spread knowledge about the system through the team. By taking a disciplined and rigorous approach to applying these practices, XP teams succeed in delivering high-quality software systems.

FEATURE-DRIVEN DEVELOPMENT (FDD) FDD is a simple-to-understand approach. A project team following the FDD method will first develop an overall model for the product, build a feature list, and plan the work. The team then moves through design and build iterations to develop the features.


AGILE METHODS

Fig. 2: Feature-Driven Development

FDD recommends a set of good practices, derived from software engineering. These practices include: Domain object modeling: In this practice, teams explore and explain the

domain (or business environment) of the problem to be solved. Developing by feature: This practice involves breaking functions down into

two-week or shorter chunks and calling them features. Individual class (code) ownership: With this practice, areas of code have

a single owner for consistency, performance, and conceptual integrity. Feature teams: These are small, dynamically formed teams that vet designs

and allow multiple design options to be evaluated before a design is chosen.

Develop

an overall

model

Build a

feature

list

Plan by

feature Build by

feature

Design by

feature


AGILE METHODS FDD PRACTICES CONTD Inspections: These are reviews that help ensure good-quality design and

code. Configuration management: This practice involves labeling code, tracking

changes, and managing the source code. Regular builds: Through regular builds, the team makes sure the new code

integrates with existing code. This practice also allows them to easily create a demo.

Visibility of progress and results: This practice tracks progress based on completed work.


AGILE METHODS

DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM) DSDM is centered on eight principles. They are:

1. Focus on the business need 2. Deliver on time 3. Collaborate 4. Never compromise quality 5. Build incrementally from firm foundations 6. Develop iteratively 7. Communicate continuously and clearly 8. Demonstrate control


AGILE METHODS

CRYSTAL

Crystal is a family of methodologies designed for projects ranging from those run by small

teams developing low-criticality systems (Crystal Clear) to those run by large teams building high-criticality systems (Crystal Magneta).

The Crystal methodologies embrace and promote many agile principles including:

Frequent delivery: Crystal methodologies build increments of a solution and check

these incremental builds for acceptance. Reflective improvement: This practice involves regularly checking for ways to

improve and then implementing the new methods.

Osmotic communication: This means team members are co-located to allow them to efficiently share information.

Personal safety: Crystal methods emphasize the need to create an environment

where people can safely raise issues or questions. Focus: This means team members know what to work on and have the time and

peace of mind to work on it.

Easy access to expert users: Through such access, the team can get up-to-date requirements and rapid feedback.

Technical environment: Crystal methods rely on automated tests, configuration

management, and frequent integration.


AGILE METHODS

LEAN SOFTWARE DEVELOPMENT Lean is a set of principles that have been taken from lean manufacturing approaches and applied to software development. These principles focus on seven core concepts.

Fig. 3: Lean Software Development

LEAN

Eliminate Waste

Empower the Team

Deliver Fast

Optimize the

Whole

Build Quality In

Defer Decisions

Amplify Learning


AGILE METHODS

LEAN SOFTWARE DEVELOPMENT CORE CONCEPTS Eliminate waste: For software systems, waste can take the form of partially done

work, delays, handoffs, unnecessary features, etc. Therefore, to increase the value we are getting from projects, we must develop ways to identify and then remove waste.

Empower the team: We should respect team member’s superior knowledge of the

technical steps required on the project and let them make local decisions to be productive and successful.

Deliver fast: We can maximize the project’s return on investment (ROI) by quickly

delivering valuable software and iterating through designs. Optimize the whole: We go beyond the pieces of the project and look for how it

aligns with the organization.

Build quality in: Lean development doesn’t try to “test-in” quality at the end; instead, we build quality into the product and continually assure quality throughout the development process, using techniques like refactoring, continuous integration, and

unit testing. Defer decisions: We balance early planning with making decisions and committing to

things as late as possible.

Amplify learning: This concept involves facilitating communication early and often, getting feedback as soon as possible, and building on what we learn.


AGILE METHODS

KANBAN DEVELOPMENT

Kanban development is derived from the lean production system used at Toyota. “Kanban” is a Japanese word meaning “signboard”. The signboard, or Kanban task board as it is also called, plays an important role in the Kanban development methodology. The Kanban development methodology limits work in progress (WIP) to help identify issues and minimize the waste and cost associated with changes during development. It uses a pull system to take work, within the WIP limits, through the stages of development.


AGILE METHODS

Kanban development operates on five core principles: Visualize the workflow: Having some way to visualize the workflow is very

important for organizing, optimizing, and tracking it. Limit WIP: Keeping the amount of work in progress low increases the

visibility of issues and bottlenecks and in turn facilitates continuous improvement.

Manage flow: By tracking the flow of work through a system, issues can be identified and changes can be measured for effectiveness.

Make process policies explicit: It is important to clearly explain how things work so the team can have open discussions about improvements in an objective, rather than an emotional or subjective way.

Improve collaboratively: Through scientific measurement and experimentation, the team should collectively own and improve the processes it uses.

Date post:	19-Aug-2018
Category:	Documents
Upload:	vunga
View:	243 times
Download:	0 times

INTRODUCTION TO PMI-ACP - PMTUTOR · INTRODUCTION TO PMI-ACP . ... The Project Management Institute...

Documents