According to the PMI-ACP® Exam Content Outline, Domain I Agile Principles and Mindset consists of nine tasks:

1. Act as an advocate for Agile principles with customers and the team to ensure a shared Agile mindset
2. Create a common understanding of the values and principles of Agile through practising Agile practices and using Agile
terminology effectively.
3. Educate the organization and influence project and organizational processes, behaviors and people to support the change
to Agile project management.
4. Maintain highly visible information radiators about the progress of the projects to enhance transparency and trust.
5. Make it safe to experiment and make mistakes so that everyone can benefit from empirical learning.
6. Carry out experiments as needed to enhance creativity and discover efficient solutions.
7. Collaborate with one another to enhance knowledge sharing as well as removing knowledge silos and bottlenecks.
8. Establish a safe and respectful working environment to encourage emergent leadership throughself-organization and
empowerment.
9. Support and encourage team members to perform their best by being a servant leader.

Domain I Agile Principles and Mindset

Below is a collection of the key knowledge addressed in Domain I Agile Principles and Mindset and the nine tasks related to
the domain:

 Agile Manifesto and 12 Agile Manifesto Principles

o Individuals and interactions over Processes and tools
o Working software over Comprehensive documentation
o Customer collaboration over Contract negotiation
o Responding to change over Following a plan

 Agile Project Management Fundamentals

o Users Involvement
o Team Empowerment
o Fixed Time Box
o Requirements at a High Level
o Incremental Project Releases
o Frequent Delivery
o Finish Tasks One by One
o Pareto Principle
o Testing – Early and Frequent
o Teamwork

 Agile Methodologies
o The following are the common Agile methodologies in practice these days, these are listed in
order of importance for the PMI-ACP® Exam. An understanding of the process and terminologies
of these Agile methodologies will help ensure Agile practices to be carried out effectively.
o Scrum
o XP (eXtreme Programming)
o Kanban
o LSD (Lean Software Development)
o Crystal Family
o FDD (Feature Driven Development)
o ASD (Adaptive Software Development)
o DSDM (Dynamic Systems Development Method) Atern
 Information Radiators
o Information radiators are highly visible charts and figures displaying project progress and status,
e.g. Kanban boards, burn-down charts. These shows the real progress and performance of the
project and team which enhances transparency and trust among team members and other
stakeholders.

 Agile Experimentations
o Agile projects make use of empirical process control for project decisions, ongoing observation
and experimentation are carried out during project execution to help and influence planning
o Introduce spike (including architecture spike) to carry out a technical investigation to reduce risks
by failing fast

 Sharing of Knowledge
o Ideally, Agile teams are best to be co-located (working within the same room with seats facing
each other) to enhance pro-active support, free discussion, open collaboration and osmotic
communication
o Face-to-face communication is always encouraged
o Practice pair programming if feasible
o Make use of daily stand-up, review and retrospectives
o Make use of Agile tooling to enhance sharing of knowledge:
 Kanban boards
 white boards
 bulletin boards
 burn-down/burn-up charts
 wikis website
 instant messaging – Skype, web conferencing, etc.
 online planning poker
o Since documentations are not encouraged, co-located teams can share tacit knowledge more
readily

 Self-organization and Empowerment

 Self-organizing teams are the foundation for Agile project management
 Self organization includes: team formation, work allocation (members are encouraged to take up works
beyond their expertise), self management, self correction and determining how to work is considered
“done”
 Agile team is given the power to self-direct and self-organize by making and implementing decisions,
including: work priority, time frames, etc. as they believe “the best person to make the decision is the one
whose hands are actually doing the work”
 In Agile projects, the project manager/Coach/ScrumMaster practice servant leadership to remove
roadblocks and obstacles and to enable the team to perform best.
Agile Manifesto

 Background of Agile Manifesto

 In February 2001, 17 software developers who have already been practicing incremental software
development methodologies met at the Snowbird, Utah, to discuss the future of software development.
They later formed the Agile Alliance.
 The Manifesto for Agile Software Development (Agile Manifesto) was published to define core principles
and approaches common to their software development methodologies to develop softwares / products
more efficiently
 Some of these authors form the Agile Alliance afterwards to further promote Agile software development.
 The Agile Manifesto was written at a high level aiming to define “what” to do in Agile projects (the specific
“how” to implement the principles is left to different Agile methods which can be adopted based on project
characteristics and needs).
 While many Agile practitioners disagree on the implementation details, they all follow the Agile Manifesto
principles.
 The most popular Agile implementations are Scrum, Lean, XP, etc.

The Agile Manifesto

Below is the Agile Manifesto (Values) in its entirety:

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 interactions 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 essences of the Agile Manifesto are further explained below:

Individual and interactions over Processes and tools
 People and their opinion are fundamental to project success
 Feedback from end users / customers is highly encouraged
 The project team cooperate with the end users / customers to achieve project success
 Processes and tools in the traditional project management are considered as supportive rather than limiting factors
 Teamwork is highly valued

Working software over Comprehensive documentation

 The team should focus on the shippable deliverables (to deliver actual values)
 Documentation is kept to a bare necessity (barely sufficient documentation)
 [for software projects] “nothing speaks louder than code” – and the code should be self-documenting
 for the customers, a working software is more valuable than a set of documentation
 gets minimally marketable features (MMF) delivered at very short duration

Customer collaboration over Contract negotiation

 Efforts should be put into fulfilling the requirements of the customers rather than negotiating the terms of the
contract (Agile practitioners and customers are “on the same side of the table”)
 Relationship between customers and the team is highly valued
 The ultimate goal of the project may be realized by “trial and error”
 A contract (e.g. contract statement of work (SOW), project charter or requirements document) is needed but it is not
the most important document for the project
 e.g. Acceptance Test Driven Development – all increments are demonstrated to the customer for verification and
acceptance before the team moves forward to next iteration

Responding to change over Following a plan

 Changes are welcome and should be well prepared for
 No rigid or detailed planning which may impede flexibility
 Implement change-friendly project management methodologies to ensure timeliness in carrying out the changes
 in traditional project management, “gold plating” and “scope creep” are considered detrimental, but can be
accommodated in Agile projects with mutual consent

The Agile Manifesto has made it clear that it recognizes the values of traditional project management
methodology like tools, processes, documentation and plan, but to a degree that would not limit the ability to
respond to changes.
12 Agile Manifesto Principles

A supporting document of 12 principles to the Agile Manifesto is also published to provide more in-depth
explanations of the Agile concepts.

Provide Value to Customer

1. Customer Satisfaction: Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
 early delivery of products to customer for testing and feedback
 continuous delivery to let customer know the progress
 deliver values to the customers by fulfilling the top priority requirements first

2. Welcome Changes: Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage.
 simplify the change control process, no formal documentation and approval required
 allow fast response to latest changes in external environment to enhance competitive advantage to
emerging opportunities

3. Frequent Delivery: Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
 can release the product to the market faster
 provide immediate values to the customers by delivering working features
 the project team activities can be better structured with the fixed delivery timeframe to focus on delivery of
value

Facilitate Teamwork

4. Collocated Team: Business people and developers must work together daily throughout the project.
 Collocation of team members can foster osmotic communication (with vehicles other than verbal, e.g.
gesture, what not being said, etc.)
 get instant feedback to questions, others at the location can join in the discussion if deem related
 the whole team can remain focused and work towards a common goal

5. Motivated Individuals: Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
 team members are able to choose the jobs they are most interested in through self-organization (not
through external management influence)
 the team is empowered to make day-to-day decisions
 every member is motivated to achieve success
 vs traditional project management -> micro-management, top-down approach

6. Face-to-face Conversation: The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
 get direct feedback by going to the source of problem or confusion
 often via oral communication at the workplace for the benefit of osmotic communication
 tools like video conferencing can facilitate virtual team conversation
Deliver Great Products

7. Working Software: Working software is the primary measure of progress.

 the working software enhance customer satisfaction

 measurements of the working software are necessary to maintain and improve the quality
 the software will be judged on whether it can support the overall project goals
 traditional project management focuses on plans and documentation

8. Constant Pace: Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.

 helps to promote work-life balance among the team members to promote happiness by avoiding burnout
or exhaustion
 a happy team is also a motivated and productive team
 the team can respond to changes quickly
 traditional project management would accelerate near deadline

9. Continuous Attention: Continuous attention to technical excellence and good design enhances agility.

 agility is the ability to modify, improve and upgrade in a short time

 codes need to be refactored from time to time to enhance agility so that changes to the products can be
easily introduced
 time spent on achieving quality code and finishing requirements should be well balanced

10. Simplicity: Simplicity – the art of maximizing the amount of work not done – is essential.

 focus on what are essential to create value to the project and customer
 discard any distractors that do not act values (components, process, etc.)
 the simpler the product, the easier to maintain it, the less risks are there to control

Quest for Better

11. Self-Organization: The best architectures, requirements, and designs emerge from self-organizing teams.

 the team knows best how to carry out the work, not the project manager nor human resources department
 higher level of ownership of the product and will be dedicated to project success
 the team becomes experts in how to improve the process and project as they understand the project details
 most significant difference from traditional waterfall project management

12. Regular Reflection: At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

o need to gather the lessons learned frequently during the project and put back into the next
iteration
o “retrospective meeting” as the primary tool – what works and what doesn’t and suggestion /
solutions
o changes can be implemented immediately
o traditional project management carries out reflection only at the end of the project/phrase
Agile Fundamentals

[PMI-ACP® study notes] Unlike the traditional “waterfall” project management philosophy, Agile project
management philosophy is geared to providing flexibility in response to the ever changing environment and
requirements. Industries like software development and information technology are among the first to embrace
Agile. This article outlines what makes Agile distinct from traditional project management approaches and how to
implement Agile principles in projects. Knowing these would prepare you well for the PMI-ACP® journey.

Ten Agile Fundamental Principles

Below are ten fundamental principles common to all Agile frameworks or methods. These are the essences which
make Agile different from waterfall project management.

1. Users Involvement
2. Team Empowerment
3. Fixed Time Box
4. Requirements At a High Level
5. Incremental Project Releases
6. Frequent Delivery
7. Finish Tasks One by One
8. Pareto Principle
9. Testing – Early and Frequent
10. Teamwork

1. Users Involvement
 In Agile projects, users are actively involved in the project throughout itself development cycle. Inputs and
feedback from the users are sought frequently to better understand the requirements of the users as the
project evolves and circumstances change. This is among the most important principles of Agile.

The following are the advantages of users involvement:

 Reduces the reliance of detailed requirements documentation at the initiating stage of the project and thus
eliminating the hassles of having to update the requirements documentation in details when circumstances
change
 Allows the flexibility in adding / changing requirements fast and easily
 Better understanding of users requirements as the project grows and evolves with continual user input
 Detailed project status reports are not required as the team and users work collaboratively, the
development progress is transparent to all parties. Users will be able to understand how the end product
will look like and whether all their needs are fulfilled as the project progresses
 Users can help the Agile team to understand priorities of tasks and requirements
 Users become part of the project team and they are more likely to embrace the project outcome
 The Agile team and users work towards the same goal and share the responsibilities to make the project a
success

Make this happen

 Make sure users are involved before the project starts
 [if possible] Pick a representative from the users that is a good communicator and flexible
  Co-location of project team and users for closer interaction or make use of collaboration tools / video
conferencing
 If there is not a user representative (e.g. the users are your future customers), pick a member from your
team to pretend to be the user as a whole

2. Team Empowerment

Three characteristics of empowered teams are:

 Self-sufficient – when forming the team, include all the team members necessary to perform all the
required tasks and make decisions in a timely manner without any need to consult people outside. The
users or the user representatives are integral part of the team.
 Collaborative – every member of the team works collaboratively to achieve the project goal as they are all
entrusted with the authority to make decisions on the project. The success or failure of the project lies in
whether everyone has contributed their best.
 Responsible – since the team is entrusted with taking care of the project, the team as a whole feel
responsible for the scope of the project as well as the ultimate success of the final product, not individuals
(e.g. functional managers or the CEO) outside of the team. Every member will perform their best to achieve
overall success.

Make this happen

 Involve everyone in decision making right from the beginning
 Facilitate discussions among all team members to ensure everyone is always heard
 Determine whether team decision or individual decision is needed case by case
 Deal with team member conflicts or office politics proactively
 Form a trusting relationship with all team members by not micro-managing their tasks

3. Fixed Time Box

 Unlike traditional project management processes in which the project managers would try to collect all
the requirements from the very beginning and formulate a all-encompassing project schedule based on
the available resources and the interdependencies of the project tasks, Agile does not make the
assumption that requirements are clearly know at the start of the project. Agile embraces changes in
requirements as a fact in the project life and believes that having a working software for the end users /
customers to play with would help them to better understand their needs.
 Therefore, Agile project teams work within a fixed time box. Tasks are assigned priorities with an
estimated number of man-days. At the beginning of each “time box”, the team choose from among the
list of top priority tasks a number of tasks to be finished by the end of the time box and work accordingly
to give a working product at the end.
 In normal projects, once an element of the “Triple Constraints” (i.e. time, cost and scope, aka “iron
triangle”) is changed, the other two elements must also be changed in order to maintain the quality of
the outcome. In Agile projects, only the “scope” from the triple constraints would be adjusted while the
time and cost would be kept constant.

Make this happen

 Embrace changes (new requests, changed requirements, changed priority, etc.) and incorporate them
with a change control process
  Assess new requests / requirements based on their priority in relation to the list of collected
requirements and adjust the scope for each time box
 Fix the launch date of the deliverables so as to keep the team focusing on achieving the goal

4. Requirements At a High Level

Requirements for Agile projects are collected according to the following two ways:

At a high level
 Requirements are collected at a high level, just enough to give an idea of the required product for budget
estimation purposes.
 Requirements are documented in the form of User Stories (showing how the users interact with the
product) rather than detailed specifications.

On a just-in-time basis
 Since requirements may change along the progress of the project, requirements are gathered only when
necessary for carrying out the tasks right away.
 Not to collect requirements for tasks several weeks away or more

Requirements are usually captured using visual methods (e.g. diagrams and storyboards) for better understanding
across the team. Storyboards shows how the users interact with the product with hand sketches, wireframes or
annotated screenshots.

Make this happen

 Expect and prepare for changes in requirements.
 Only collect barely enough details for the requirements (can be in the form of documentation or
storyboards) to estimate budget and carry out the work.
 Hold workshops to gather the whole team together to understand the requirements as a team effort.
 Record requirements in the form of deliverables (e.g. design the website is NOT a deliverable; interface
design for the website is) and put each deliverable on a separate card so that the priorities can be easily
changed when more requirements are added along the road.

5. Incremental Project Releases

“Incremental releases” means building on a previous release of the product / outcome. With incremental
releases, not all the requirements of the users are to be met in a single release, only the top priority requirements
as determined by the team and users. But with releases upon releases, all the requirements will be met
ultimately.

 The project runs through many iterations (cycles or sprint) of

1. getting requirements
2. development works
3. testing
4. releasing the product to users / market
 The benefit of this approach is flexibility and ability to respond to actual needs instantly. Feedback can be
sourced from actual users / market which can help adjust the direction of the project for new features /
changes.
 Also, the works and contributions of the project team can be appreciated by people outside the team as
the many releases act like a progress report which in terms can boost the morale of the team. The
 organization can also benefits from the new features introduced instantly. Should there be any early
termination of the project, there is aways something useful left.

Make this happen

 Establish the “core functions” (top priority requirements) to be included of the first and subsequent
releases through discussion between the team collectively
 Make use of the MoSCoW analysis (Must have, Should have, Could have, Won’t have)
 Try to keep the number of core functions low (keep it simple rule) to enable delivery of next incremental
release in a short timeframe (usually a week or two)
 Focus only on achieving the identified core functions in each iteration and finish all of them before the
beginning the next iteration

6. Frequent Delivery
Make plans to enable the time between each incremental release to be short enough so that you can:

 realize value through early value delivery to reduce risks and attain stakeholder satisfaction (e.g. to gain
organizational support)
 keep the momentum going by always focusing on the next shippable product
 get timely feedback from users / customers which will be gathered to adjust the project direction
 let users know the progress by a workable product release
 create competitive advantage as new features can be introduced real quick

Frequent delivery is especially suited for web-hosted services as there is little overhead for re-installation,
upgrade or manage. The delivery schedule would range from a week to around 30 days for most Agile
projects.

Make this happen

 Get feedback from users / customers (or through analytics) for timely input to help re-prioritizing the
features to be included in the next release
 Plan a fixed release cycle so that the team has a common goal to work towards the deadline
 Let the whole company know the release plan so that they can work together to make the project a
success (e.g. Marketing for press releases, Support for training materials)
 7. Finish Tasks One by One

For the Agile tasks:

 Plan the reasonable amount of tasks for each iteration so that all tasks can be finished in each iteration.
 The tasks should meet the requirements of the “Definition of Done” which is established by the team.
 This enables frequent delivery of complete (ready for customer use) features.
 Completed tasks can act as a sign of progress check which keeps the team focused.

Make this happen

 Involve the users for testing
 Ask for sign-off of completed features from the customers
 Establish a standard procedure (e.g. develop – test – approve) for each iteration so that no steps are left
out

8. Pareto Principle

 The Pareto Principle is also known as the 80/20 rule. It is a statistical principle that holds true for many
things have a similar 80/20 distribution.
 In Agile development projects, the Pareto Principle applies to the fact that 80% of all development effort
should be spent on the top 20% of the features that the customer actually ends up needing.
 Need to identify the top 20% of features that customers actually need and use most frequently.

Make this happen

 Educate end users and project stakeholders on the Pareto Principle.
 Prioritize the development efforts based on the Pareto Principle and try to identify the most beneficial
and useful features.
 Work with the whole team for more accurate choice of features.
 Check the project scope with customers and stakeholders regularly to identify any changes in
requirements.

9. Testing – Early and Frequent

 As each product release in an Agile project needs to be complete, each iteration needs to include a
robust testing process to ensure the finished tasks are complete.
 The testing process is integral to the development cycle, there is no a distinct testing phase.
 Everyone in the Agile team is responsible for the testing of the product.
 Tests should be run time and again to ensure new feature would not break the functionality of existing
features.
 The Agile tester should refer to the “Definition of Done” to guide the requirements of testing.

Make this happen

 Include automated tests for more robust and efficient testing.
 Include testing as a normal development routine.
 Involve the whole team to perform the testing.
 Integration tests are very important.
 10. Teamwork
 Change is normal in Agile development, documentation is usually kept at a minimal.
 All the Agile team member should work together in a team so that any changes can be communicated
with everyone.

Make this happen

 Collocation is one of the best tactic to ensure great teamwork.
 Use of a feature board / task board as a focus point / information radiator for the team.

Agile Methodologies
Remembering roles as well as core concepts for the following Agile methodologies are required to pass the PMI-
ACP® exam:

 XP (eXtreme Programming)
 Scrum
 LSD (Lean Software Development)
 Crystal Family
 ASD (Adaptive Software Development)
 DSDM (Dynamic Systems Development Method) Atern
 FDD (Feature Driven Development)
 Kanban

XP (eXtreme Programming)
XP (eXtreme Programming) is currently one of the most popular Agile methods. XP is a disciplined approach to
delivering high-quality software quickly and continuously at very short intervals (typically every 1-3 week).
XP promotes responsiveness to changes, higher customer involvement, rapid feedback loops, continuous testing,
continuous planning and close teamwork. The name suggests that the beneficial elements of traditional
programming practices are taken to the extreme.

XP is based on 4 values and 12 supporting practices. The 4 values are: simplicity, communication, feedback,
and courage. The 12 supporting practices are: Planning Game, Small Releases, Customer Acceptance Tests, Simple
Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code
Ownership, Coding Standards, Metaphor and Sustainable Pace.

Scrum
Scrum is considered a lightweight management framework suitable for managing iterative and incremental
projects (including product development projects other than software). Scrum has grown rapidly in the past few
years and is fast becoming one of the most popular Agile methods, especially among the software industry. Scrum
is renowned for its simplicity, proven success, productivity, and its flexibility to be used as a framework for various
engineering practices promoted by other Agile methodologies, i.e. Scrum Masters are allowed to select the most
suitable Agile practices to be brought under the Scrum framework. Scrum adopts an empirical approach by
accepting problems cannot be fully understood at the beginning and must be continuously attended to along the
project.
LSD (Lean Software Development)
Lean Software Development is an iterative methodology developed from the processes and practices in
Lean Enterprise movement (for the production industry). Lean Software Development focuses the team on
delivering value to the customers by focusing on the “Value Stream“. Core Lean principles include: Eliminating
Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team,
Building Integrity In, and Seeing the Whole. The value stream approach emphasizes on the speed and efficiency of
development workflow, and relies on rapid and reliable feedback between programmers and customers. Lean
methods try to eliminate waste by prioritizing and working on “truly” valuable features of a system and delivering
values rapidly in small batches.

Crystal Family
The Crystal methodology is one of the most lightweight, adaptable approaches to software development.
Crystal is a family of methodologies including Crystal Clear, Crystal Yellow, Crystal Orange, etc. The different
methodologies in the Crystal family are differentiated by factors like team size, system criticality and project
priorities. The Crystal family allows a tailored set of policies, practices and processes for individual projects in order
to suit the characteristics of the projects. Crystal methodologies emphases on the interaction between people and
processes.

ASD (Adaptive Software Development)

ASD embraces the principle of continuous adaptation of the processes to the project. It consists of repeating
series of speculate, collaborate and learn cycles. Characteristics of ASD includes: mission focused, feature based,
iterative, timeboxed, risk driven and change tolerant.

DSDM (Dynamic Systems Development Method) Atern

DSDM was first released in 1994 to provide guidance on Rapid Application Development (RAD) and was
primarily focused on software development. DSDM has evolved over the years to become a generic approach for
Agile project management and solution delivery by providing a comprehensive foundation for planning, managing,
executing, and scaling agile and iterative software development projects. DSDM is based on 9 key principles that
primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery,
integrated testing, and stakeholder collaboration. By utilizing DSDM, costs, quality and time are fixed. DSDM
singles out “fitness for business purpose” as the primary criteria for delivery and acceptance of a product. It makes
use of the MoSCoW prioritization principles to deliver values which is based on the principle that “80% of features
can be deployed in 20% of the time”.

FDD (Feature Driven Development)

FDD is a feature-driven methodologies that consists of short iterations (two weeks). It makes use of a
“design by feature, build by feature” approach where features through a client perspective. FDD adapts the project
development process around feature delivery by making use of the following 8 practices: Domain Object Modeling,
Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management,
Regular Builds, Visibility of Progress and Results.

Kanban
Kanban is a scheduling system used in Lean and JIT (Just-in-time) production. When applied to software
development, kanban is a “pull-based” planning and execution method. For software development teams, “cards”
representing tasks to be done are kept on a Kanban Board which is organized into columns and rows. The columns
represent the status, i.e. from initial planning, work-in-process through customer acceptance. The status can be
tailored to find the project context. The rows contain the tasks to be performed. Since Kanban focuses on
maximizing throughput, a limit would be set on the maximum tasks in the Work-in-Process (WIP) column to avoid
bottlenecks. Queues or inventories of work in any state are seen as waste. The WIP limit allows the team to focus
on optimizing the flow of work items through the work processes, thereby achieving process optimization at a
sustainable pace.
Extreme Programming (XP)
[PMI-ACP® Exam Study Notes] Extreme Programming (XP) is one of the most popular Agile model for
software development good practices (Unlike Scrum which focuses of project management on prioritizing tasks
and getting feedback). Extreme Programming is based on five core values taken to the extreme: simplicity,
communication, feedback, courage and respect. This post is about the guidance practices, roles and responsibilities,
events, etc. of XP.

Extreme Programming (XP) Agile Model

Extreme Programming (XP) is based on five core values:

 Simplicity – reduce wastes and extra features, find the simplest way to achieve the goals
 Communication – make sure everyone involved get clear communication
 Feedback – get feedback early and frequently, prefer failing fast
 Courage – have confidence to make changes and share progresses (e.g. thru pair programming, unit tests
and automated builds)
 Respect – respect other teammates, everyone is accountable for success of the project

XP Roles (Whole Team)

Team members can cross-functional, taking up more than 1 roles. Team members are expected to be co-
located.
 Development team – including developers, quality assurance professionals and business analysts
 Customer – business representative to guid priorities and direction, provide the requirements and describe
customer tests for testing the products
 XP Coach – (optional) to facilitate communication and coordination and guide the processes

XP Events

 Requirements are described in the form of User Stories

 Iterations – iterations are usually 2-week long, developers work in pairs to work together during the
iterations
o Spikes – work carried out the reduce risks
 Architectural Spikes – a particular type of spike to prove technological approach
o Planning Games – the customer provides the requirements while the developer estimate the
difficulty and resources required, the customer will select a prioritized set of requirements for
the upcoming releases
 Release Planning – 1-2 times per year, for defining high-level tasks and estimates and
system metaphor
 Iteration Planning – every 2 weeks, customer explain the functional requirements
o Daily Stand up – daily meeting to get updated on the progress among teammates
o Acceptance Tests – tests are written before code and continuously used to check for correctness
in system functions
o Customer Approval
o Small Releases with Integration Tests
XP Practices
 Whole Team – co-located in a place, including the customer
 Planning Games – planning meetings for releases and iterations
 Small Releases – frequent deployment with automated testing and continuous integration for competitive
advantages
 Customer Tests – customer define tests for expectation alignment
 Collective Code Ownership – everyone has access to the code for visibility and bug detection
 Code Standards – ensure a coherent coding approach
 Sustainable Pace – avoid overtime and burnout to maintain sustainability in the long term, often making
40-hour work weeks, not to take up more story points than what can be completed in the previous
iteration
 Metaphor – making use of tangible metaphor to ensure alignment of goals
 Continuous Integration – programmers check in the code to the code repository several times daily,
integration tests are automatically carried out each time to ensure code quality
 Test-drive Development – write tests before new codes
 Refactoring – improve the existing code quality without amending the functionalities (to pay back
technical debts)
 Simple Design – the simplest design is the most efficient and less risky, do things once and only once
 Pair Programming – two programmers working side by side, one to write, the other to review

Basic XP Activities for Software Development Process

1. Listening
o to the customer to understand the requirements
o to other development team members for collaboration
2. Designing the code based on the requirements input
3. Coding
4. Testing for quality control and assurance
Scrum
[PMI-ACP® Exam Study Notes] Scrum is one of the most popular Agile model. It is easy to understand but
difficult to master. Scrum is based on three pillars: transparency, inspection and adaptation.

Scrum Agile Model

Scrum development includes three major phases: pre-game, game, and post-game.
Scrum is based on three pillars:
 Transparency – visibility of project progress and outcome for all involved, a common definition of
“Done” is created to ensure alignment of expectations
 Inspection – inspections are done at timely intervals to look out for deviations or differences
 Adaptation – should a problem be found during inspections, project processes will be adjusted to
avoid / minimize such problems from occurring in future

Scrum Roles (Teams)

 Development team – the ones who actually build the product during the iterations / sprints
o self-organizing, empowered, cross-functional
o optimal size: 7 +/- 2 (i.e. 5 – 9 team members)
 Product Owner – tasked with the responsibility to maximize the values delivered
o manage the product backlog (including prioritizing the requirements, etc.)
o lead the sprint review
 ScrumMaster – help to implement Scrum in the project
o act as a servant leader to facilitate the team and project
Scrum Events
 Sprint – the Scrum term for “iteration” (a timeboxed period for project development work), often less
than a month (2-week or 1-month), to build potentially releasable products. Activities of a sprint include
the following:
o Sprint Planning Meeting – a timeboxed meeting to determine what can be and will be delivered
by end of the sprint based on consensus among the product owner and the team
o Daily Scrum – a 15-minute timeboxed daily meeting to look into the following three questions:
1. What has been achieved since last meeting?
2. What will be done?
3. What obstacles are encountered / expected?
o Development Work
o Sprint Review – (about the product) a meeting held at the end of each sprint to demonstrate
what has been done and agree to what need to be done next, the product backlog will also be
adjusted based on the progress; to be led by the Product Owner
o Sprint Retrospective – (about the process, people, tools, relationship) a meeting to reflect on the
process and look for improvements. The sprint retrospectives occur after the sprint reviews.
 Key characteristics of a healthy daily stand-up meeting:
o peer pressure – the team is dependent upon each other so expectations of peers drives progress;
o fine-grained coordination – the team should understand the necessity for focus and working
dependently;
o fine focus – the team should understand the need for brevity in the stand-up meeting so the
team can be productive;
o daily commitment – the team should understand the value of daily commitments to each other
and uphold those commitments;
o identification of obstacles – the team collectively should be aware of each other’s obstacles so
that the team collectively can try to resolve them.

 Scrum Events are time-boxed:

 o Sprint Planning – 8 hours
o Daily Scrum – 15 minutes
o Sprint Review – 4 hours
o Sprint Retrospective – 3 hours

Scrum Artifacts
 Product backlog – an prioritized list of requirements of the project (often in the form functions, features,
fixes and quality attributes [i.e. non-functional requirements], etc.). To be updated by the Product Owner.
Higher priority requirements are more detailed in descriptions and estimates.
 Grooming – add more details to and possibly re-order the backlog by both the team and the product
owner
 Sprint backlog – product backlog items selected for a particular sprint with an elaborated plan on how to
achieve the sprint goal. To be updated by the Development Team only.
 Definition of Done – describe the agreed definition of when the work is considered done by all

Lean Software Development & Kanban

[PMI-ACP® Exam Study Notes] Lean Software Development has its principles adopted from the Lean
Manufacturing Approaches. Lean is not an Agile method in the strictest sense but its values are in close alignment
with Agile. This post is about the guidance principles and practices, etc. of Lean Software Development and
Kanban.

Lean Software Development Agile Model

Lean Software Development is based on sever core values:
 Eliminate Waste – remove any work, processes, etc. that do not deliver values
 Empower the Team (Respect People) – respect the team to make their own decisions without micro-
management
 Deliver Fast – deliver values fast to maximize return on investment (ROI)
 Optimize the Whole – optimize the project parts as a whole and align to the organizational goals
 Build Quality In – quality must be in-built into the whole process through automated unit testings,
continuous integration, refactoring, etc.
 Defer Decisions – make commitments as late as possible for a better informed decision as the availability
of information is more
 Amplify Learning (Build Knowledge) – gather feedback and communicate often to keep learning about
requirements, environments, etc.

Key Lean Techniques

 Value Stream Mapping – to investigate processes to reduce wastes
 Work In Progress (WIP) – work not yet done, requires overhead on managing these works and their
relationship with others, considered wastes if too many as some work must be put on waiting
 Seven Forms of Wastes for Lean Software Development
o Defects – defective parts or documents
o Extra Features – “nice-to-haves”
o Extra Processes – processes that do not add value
o Task Switching – multitasking for different processes / projects
o Partially Done Work – any WIP that is not “done” according to definition of done
o Waiting – waiting for review, approval, etc.
o Motion – move the information / deliverable to another place (e.g. distributed teams)
Kanban
 Kanban means “signboard” in Japanese.
 Can be physical cards / post-it or software-based
 Kanban is a pull system where developers take out tasks from the product / iteration backlog and work all
the way to reach “Done”.
 Kanban limits Work In Progress (WIP) to identify issues with the development and reduces wastes,
different WIP limits can be applied to different columns of the Kanban board.
 Kanban boards are simple information radiator ideal for all the people involved in the project (vs Gantt
charts which are too complicated).
 If a developer finds out that the task time estimate is too high or low, they should amend it as soon as
possible (since they are further into the project and would understand the requirements much better
than at the beginning).

5 Core Kanban Principles

 Visualize the Workflow – the Kanban board make the project progress visible for optimizing and tracking
 Limit WIP – make bottlenecks visible so as to facilitate continuous improvements
 Manage Flow – optimize the flow for maximum efficiency
 Make Process Policies Explicit – since the rules for the Kanban pull system is cleared stated, objective
discussions are made feasible for improvements
 Improve Collaboratively – since objective data / metrics can be collected through the Kanban board,
testing and improvements can be made collectively

FDD, DSDM, Crystal Family

Feature-Driven Development (FDD) Agile Model

 Feature-Driven Development (FDD) is a simple but powerful Agile model for product or software
development involving the following steps:

1. Develop an overall model

2. Build a feature list
3. Plan by feature
4. Design by feature
5. Build by feature

Good practices of FDD

 Domain Object Modeling – explore and explain the domain of the project / problem
 Developing by Feature – breaking down requirements into small features (for 2-week iterations)
 Individual Class (Code) Ownership – individuals own parts of the code for consistency and integrity
(opposed to the collective code ownership of XP)
 Feature Teams – form “teams within team” to create multiple design options and select the best to
proceed
 Inspections – frequent review of the code
 Configuration Management – tracking changes to the code repository and maintain a “trunk” code
 Regular Builds – new codes are to be integrated with the existing codes frequently through regular builds
 Visibility of Progress and Results

FDD makes use of Cumulative Flow Diagrams (a chart showing what are in progress and what have been
completed to visualize and track the progress) and Parking Lot Diagrams (a one-page summary of project
progress) as one of its tools.
Dynamic Systems Development Method (DSDM) Agile Model
 The Dynamic Systems Development Method (DSDM) project lifecycle is very detailed and broad, covering
business case development / feasibility study to post project tasks.

The DSDM lifecycle includes:

 Pre-project
 Feasibility / Business
 Functional Model Iteration
 Design & Build Iteration
 Implementation
 Post-project

Eight Principles of DSDM

 Dynamic Systems Development Method (DSDM) centers on eight principles which are closely aligned
with the Agile Manifesto:

1. Focus on 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

DSDM allows the use of certain “filters” to help determining which processes are needed or not for a
particular project nature / scope.

Crystal Agile Model

 Crystal Agile methodologies is in fact a family of methodologies designed for different team sizes and
criticality, e.g. Crystal Clear (small team with low-criticality systems) andCrystal Magenta (large team with
high-criticality systems).
 with the increase in team sizes and project criticality, Crystal methodologies introduce changes to the
processes (called scaling) to fit the projects in order to secure project success.

Core Principles of Crystal

 Process Tailoring – tailor the processes (including requirements, rules, etc.) to the actual needs of the
project (depending on the sizes, number of teammates, nature, etc.)
 Frequent Delivery
 Reflective Improvement – checking for ways to improve
 Osmotic Communication
 Personal Safety – people can safely raise questions and issues
 Focus
 Easy access to Expert Users
 Technical Environment – automated tests, frequent integration and configuration management
The Agile Team
Self-organization
 Self-organizing teams are the foundation for Agile project management
 traditional project management: top-down approach, follow instructions/planning from managers, little
or no input from the front-line staff
 Agile project management: the problem is handed down to the project team to determine what and how
to do
 in Agile projects, the project manager/Coach/ScrumMaster are there to facilitate the team in times of
dysfunction, e.g. conflicts are necessary for high performing teams, if the team culture is too reluctant to
enter into conflicts, the Coach should be the one to introduce some conflicts
 Self organization includes: team formation, work allocation (members are encouraged to take up works
beyond their expertise), self management, self correction and determining how to work is considered
“done”
 all members of the team are collectively responsible for the success (or failure) of the project, everyone is
responsible for everything
 Agile projects work best when the team members are seasoned, self-directed and highly motivated
 team members should be involved in the selection and interviewing of new members

Open and Transparent

 contribution and progress of individual members should be visible to all the team
 work does not belong to a single member but the whole team

Small Team Size

 in the book Succeeding with Agile by Mike Cohn, it is suggested that the team should be able to be fed
with “a couple of pizzas”
 for larger projects, the team should be sub-divided (break down the project into sub-projects)
 for Scrum teams, the optimal team size is 7 ± 2

Colocation
 the ideal co-located team should be all in the same room with all barriers (e.g. partitions) removed – to
facilitate communication and collaboration while minimize distraction
 team members as well as the customer should sit around a square/circular table facing each other
 members can hear and see each other to facilitate communication
 colocation can avoid the formation of silos (expert groups focusing on single aspects of the project,
communication across different groups is very challenging)
 make use of information radiators (e.g. charts/backlog lists/user stories posted on the walls) and
whiteboards
 if physical colocation is not feasible, virtual colocation by making use of instant messengers/video
conferencing software is highly encouraged

Agile Tooling
 use of Agile tooling (a class of tools, technologies and practices) should be made to help building bonding
and sense of belonging by encouraging communication, participation and information sharing
o high-tech Agile tooling: instant messengers, video conferencing, online Agile project management
tools
o low-tech Agile tooling: recreational space, daily stand-up meetings, team building activities
Empowered Team
 the Agile team is given the power to self-direct and self-organize by making and implementing
decisions, including: work priority, time frames, etc.
 the team may optionally given the power to add value to the customer and choose team members
 an important aspect of the empowered team is to have the customer/product owner co-locating with the
team
 “the best person to make the decision is the one whose hands are actually doing the work”
 factors needed: organizational buy-in, alignment with corporate goals, shared vision, clear
communication, customer involvement and team accountability

Ground Rules
 ground rules are unwritten rules about the expectation of the project team members
 including: work time, culture, language, rituals, etc.