Agile Project Management Principles and Methodologies - Study Notes

IT Project Management: Agile Principles and Methodologies
______________________________________________________________________________
Study Notes www.SlideShare.net/OxfordCambridge Page 1 of 44
Agile Principles and Methodologies (01)
Agile Project Management
Study Notes v.1.0
Entry Level
+W Series - Technology Skills For Women.1
1 Men too are allowed to read on, if they wish do so, as the language style and the document format are
universal J.

______________________________________________________________________________
1. About “+W Series - Technology Skills for Women”
Study Notes in the field of technology are put together under this category for the following
reasons:
• To encourage girls and ladies, who wish to do so, to stand up and look over the fence
into technology related topics.
• With no apprehension or fear.
• And perhaps consider embracing a career move into a technological path.
• Or simply to broaden their general knowledge; after all IT is already in most aspects of
everyday life.
• No matter the ground for a decision, their skills, their professional strengths, and their
contribution can only be something positive in any technological fields.
Enjoy!
“Education is not about the filling of a bucket but the lighting of a fire!” (William Butler Yeats)

______________________________________________________________________________
2. Table of Contents
1. About “+W Series - Technology Skills for Women” .................................................................. 2
3. Foreword ............................................................................................................................................... 6
4. About this publication ....................................................................................................................... 7
4.1. Overview................................................................................................................................................. 7
4.2. Learning Objectives ................................................................................................................................ 7
5. Document’s Sections .......................................................................................................................... 8
6. Understanding Agile .......................................................................................................................... 9
6.1. Linear process model.............................................................................................................................. 9
6.2. Imperative and Iterative Model............................................................................................................ 10
6.3. Agile Project Management: an incremental model.............................................................................. 10
6.4. Agile Project Management: an iterative model.................................................................................... 11
6.5. Benefits of an incremental and iterative project management model ................................................ 11
7. Agile Values and Principles ........................................................................................................... 12
7.1. Origins of Agile: The Agile Manifesto.................................................................................................... 12
7.2. Agile Primary Values and Secondary Values......................................................................................... 13
7.2.1. Primary Value: Individuals and Interactions ................................................................................. 13
7.2.2. Primary Value: Working Software ................................................................................................ 14
7.2.3. Primary Value: Customer Collaboration ....................................................................................... 14
7.2.4. Primary Value: Responding to Change.......................................................................................... 14
7.3. Agile first six Principles ......................................................................................................................... 14
7.3.1. Agile Principle: Satisfy the Customer ............................................................................................ 15
7.3.2. Agile Principle: Welcome Change ................................................................................................. 15
7.3.3. Agile Principle: Deliver Software Frequently................................................................................. 15
7.3.4. Agile Principle: Work Together ..................................................................................................... 15
7.3.5. Agile Principle: Motivating Individuals.......................................................................................... 15
7.3.6. Agile Principle: Use Face-to-face Communication ........................................................................ 15
7.4. Agile remaining six Principles ............................................................................................................... 15
7.4.1. Agile Principle: Working Software Equals Progress ...................................................................... 16
7.4.2. Agile Principle: Constant Pace....................................................................................................... 16
7.4.3. Agile Principle: Technical Excellence............................................................................................. 16
7.4.4. Agile Principle: Self-organizing ..................................................................................................... 16
7.4.5. Agile Principle: Reflection ............................................................................................................. 16
7.5. Conclusion ............................................................................................................................................ 16
8. Agile Project Management Model ................................................................................................ 17
8.1. Envisioning Phase ................................................................................................................................. 17
8.2. Speculating Phase................................................................................................................................. 17
8.3. Exploring Phase..................................................................................................................................... 17
8.4. Adapting Phase..................................................................................................................................... 18
8.5. Closing Phase........................................................................................................................................ 18

______________________________________________________________________________
9. About Agile Methodologies ............................................................................................................ 19
9.1. Extreme Programming (XP) .................................................................................................................. 19
9.2. Lean principles & Tools......................................................................................................................... 20
9.3. Kanban.................................................................................................................................................. 21
9.4. Crystal Methodologies.......................................................................................................................... 21
9.5. Feature-driven Development (FDD) ..................................................................................................... 22
9.6. Dynamic Systems Development Method (DSDM)................................................................................ 22
9.7. Model-driven Development (MDD)...................................................................................................... 23
9.8. Disciplined Agile delivery (DAD)............................................................................................................ 23
9.9. Test-driven Development (TDD)........................................................................................................... 24
9.10. Behavior-driven Development (BDD) ............................................................................................... 25
9.11. In conclusion..................................................................................................................................... 26
10. About Scrum Framework ........................................................................................................... 28
10.1. Scrum: A Lightweight Agile Framework............................................................................................ 28
10.2. Spring Goals...................................................................................................................................... 28
10.3. Planning ............................................................................................................................................ 28
10.4. Inspecting and Adapting ................................................................................................................... 28
10.5. Daily Scrum....................................................................................................................................... 29
10.6. Sprint Review.................................................................................................................................... 29
10.7. Sprint Retrospective ......................................................................................................................... 29
10.8. Concluding Words............................................................................................................................. 29
11. Adopting an Agile Approach ...................................................................................................... 30
11.1. Considering Adopting an Agile.......................................................................................................... 30
11.2. A.D.A.P.T Steps ................................................................................................................................. 30
11.3. Awareness......................................................................................................................................... 31
11.4. Desire to Support Change................................................................................................................. 31
11.5. Ability................................................................................................................................................ 31
11.6. Promoting Agile ................................................................................................................................ 31
11.7. Transferring ...................................................................................................................................... 31
11.8. In Conclusion..................................................................................................................................... 31
12. Initiating a Project in Agile ........................................................................................................ 33
12.1. Establishing a Business Case............................................................................................................. 33
12.2. Components of a Business Case ....................................................................................................... 33
12.3. To Summarize ................................................................................................................................... 34
13. Creating a Vision and Charting an Agile Project ................................................................. 35
13.1. Developing a Project Vision and Project Charter is Key.................................................................... 35
13.2. The Product Vision............................................................................................................................ 35
13.2.1. Interviewing Stakeholders............................................................................................................. 35
13.2.2. The Vision Statement.................................................................................................................... 35
13.3. The Project Charter........................................................................................................................... 35
13.3.1. Vision Statement – Element of Project Charter............................................................................. 35

______________________________________________________________________________
13.3.2. Objectives or Mission.................................................................................................................... 35
13.3.3. Success Criteria ............................................................................................................................. 36
13.3.4. Priorities and Compromises .......................................................................................................... 36
13.3.5. Risks and Mitigation ..................................................................................................................... 36
13.3.6. Team Roles.................................................................................................................................... 36
13.3.7. Project Charter Format: A One-Page Document........................................................................... 36
13.4. Conclusion ........................................................................................................................................ 36
14. About Agile Contracts .................................................................................................................. 37
14.1. Purpose of Contracts ........................................................................................................................ 37
14.2. Suitable Contracts for Agile Projects ................................................................................................ 37
14.2.1. Service Contracts........................................................................................................................... 37
14.2.2. Fixed-price Contracts .................................................................................................................... 37
14.2.3. Cost-reimbursable or Time-and-materials Contracts.................................................................... 38
14.2.4. Not-to-exceed With Fixed-fee Contracts....................................................................................... 38
14.2.5. Incentive Contracts ....................................................................................................................... 38
14.3. Concluding Words............................................................................................................................. 38
15. About Agile Documentation ....................................................................................................... 39
15.1. Working Software as Primary Measurement of Progress................................................................. 39
15.2. Common Documentation for Agile Projects..................................................................................... 39
15.3. Focus on Delivering Highest Value First............................................................................................ 39
15.4. Vision Statement Document............................................................................................................. 39
15.5. Project Overview Document............................................................................................................. 40
15.6. Requirements Documentation ......................................................................................................... 40
15.7. Acceptance Testing Documents........................................................................................................ 40
15.8. Support Documentation ................................................................................................................... 40
15.9. User Documentation......................................................................................................................... 40
15.10. Creating Effective Communication ................................................................................................... 40
15.11. Summary........................................................................................................................................... 40
16. Key Agile Concepts Summarized .............................................................................................. 41
16.1. Characteristics of the Agile method ................................................................................................. 41
16.2. Identify Primary Agile Value Priorities.............................................................................................. 41
16.3. The Five Phases of the Agile Project Management Model ............................................................... 41
16.4. Types of Documentation Best Suited for Agile Environments.......................................................... 42
17. Agile Principles Key Words ....................................................................................................... 43

______________________________________________________________________________
3. Foreword
This publication consists of introductory elements related to Agile project management, all for free and free
for all.
That is said, the information gathered here may be use:
• Either to give the reader an overview of the key points of the topic, before deciding for a full scale
study of that very topic.
• Or to act as a study guide for learners wishing to expand their knowledge on this given topic.
Agile Projects are characterized by the use of short work iterations and incremental product development. In
this publication, we shall learn about the core values and principles outlined by the Agile Manifesto.
We shall also learn about:
• Some of the more common Agile methods and practices,
• How to create an Agile product roadmap, and
• The unique aspects of Agile contracts and documentation.

______________________________________________________________________________
4. About this publication
4.1. Overview
Agile projects use of short work iterations and incremental development of products that focus on business
priorities and customer value. In this publication, we should be able to comprehend:
• Fundamental Agile concepts, including
• The eight Agile Values and
• Twelve Agile Principles.
This study notes document also covers the five Phases of the Agile project management model and
introduces the most common Agile methodologies and frameworks.
To conclude, this publication introduces key activities for managing an Agile project, including/
• Creating a product vision and project charter, and
• Best contract and documentation types.
4.2. Learning Objectives
• identify characteristics of the Agile method
• distinguish between primary and secondary Agile values
• identify the five phases of the Agile project management model
• identify some of the methodologies that can be used for Agile project management
• recognize the four Scrum inspect and adapt events
• identify the five A.D.A.P.T steps required to transition to Agile
• identify the recommended components of a business case
• recognize the elements of a project charter
• identify the contract types suitable for Agile projects
• identify helpful types of documentation for Agile projects
• demonstrate the understanding of the Agile principles and methodologies

______________________________________________________________________________
5. Document’s Sections
1. Understanding Agile
2. Agile Values and Principles
3. Agile Project Management Model
4. About Agile Methodologies
5. Scrum Framework Overview
6. Adopting an Agile Approach
7. Initiating a Project in Agile
8. Creating a Vision and Charting an Agile Project
9. About Agile Contracts
10. About Agile Documentation
11. Key Agile Concepts Review

______________________________________________________________________________
6. Understanding Agile
After going through this section, we should be able to identify characteristics of the Agile method.
There are countless ways we can manage a project and most common project management methodologies
fall into one of two model types:
• Defined and linear process model, or
• Empirical and iterative process model.
6.1. Linear process model
In the defined and linear process model, there's a very linear approach planned for the project work. And
work gets carried out following that plan through distinct and complete project phases. We complete one
phase of a project, then move on to the next phase, each phase needs to be completed before moving to the
next.

______________________________________________________________________________
6.2. Imperative and Iterative Model
In the empirical and iterative model on the other hand, we use actual and empirical data gathered as project
work is gradually performed, working in iterations, building on what's been done, and introducing or
changing elements as we go.
Sometimes performing work in cycles to create the end result, therefore building a project includes the
following three stages:
• Design & Development,
• Testing, and
• Implementation.
6.3. Agile Project Management: an incremental model
Agile Project Management is considered an incremental model for project management.
Therefore, instead of project work being completed in a linear model with one final delivery phase, the
project work is divided up into increments. And each increment of project work goes through:
• Requirements,
• Design,
• Development, and then
• Testing and delivery.
Then, we move on to the next piece of project work. That way, we are taking the project one piece at a time
and delivering each piece.
Requirem ent Design Development Testing Delivery
1
2
3
4
Time
Increment

______________________________________________________________________________
6.4. Agile Project Management: an iterative model
Agile Project Management is additionally considered an iterative model.
Consequently, not only are we building the pieces of our final product incrementally over time, we are also
iterating.
That means in the first increment, we might initially build the minimum features that are required for our
product, such as login functionality for example.
Then once we have tested that functionality, in the next increment of work we may build more robustness
into that feature. Consequently, we are incrementally adding different features to our end-product, and
adding robustness to our features with each iteration.
6.5. Benefits of an incremental and iterative project management model
With Agile being iterative and incremental, the focus is on delivering the highest value items first.
Subsequently, if we are starting with highest value items first, then we know that we have at least tackled
the things that are the most important to our stakeholders.
Another characteristic of Agile Project Management is that we identify issues much earlier. Because testing
is ongoing with each iteration rather than just in one testing phase at the end of the project life cycle, issues
are identified much earlier in the development process.
Feedback from the project stakeholders is also obtained early and often at the end of each iteration. This
makes it possible to incorporate that feedback into the next iteration. Once that feedback has been
received, and since we haven't moved too far ahead in the project work, it's much easier to make changes as
well.

______________________________________________________________________________
7. Agile Values and Principles
After reading this section, we should be able to distinguish between primary and secondary Agile values.
7.1. Origins of Agile: The Agile Manifesto
In February of 2001, a group of 17 independent software practitioners came together and authored what is
called the Agile Manifesto.
The Agile Manifesto was born out of a need for a software development methodology that was driven by the
features and end product, rather than being driven by traditional project management methods that
focused more on the project management process itself, and less on the final product. The Agile Manifesto is
comprised of 4 values and 12 principles.
•
Follow ing
4 Value s 12 Principle s
Agile Manifesto

______________________________________________________________________________
7.2. Agile Primary Values and Secondary Values
The Agile Manifesto contains four values, which are further broken down into two sets:
• Primary Values,
• Secondary Values.
The four Primary Values are:
• Individuals and Interactions,
• Working Software,
• Customer Collaboration, and
• Responding to Change.
The four Secondary Values are:
• Processes and Tools,
• Comprehensive Documentation,
• Contract Negotiation, and
• Following a Plan.
All of these values contribute to the success of our project, nonetheless the Primary Values are the values
that contribute most to successful projects and are valued over the Secondary Values.
7.2.1. Primary Value: Individuals and Interactions
The first Agile value says that we value individuals and interactions over processes and tools. Sometimes in
our corporate environments or in team environments, we value certain processes and working with certain
tools more than we value the individuals and interactions that create success.
What that means is if, for example, we have a tool that we are using that costs us a lot of overhead, we
should be thinking whether to continue using that tool. We should be thinking more about:
• How do we foster more communication?
• How do we foster more collaboration?
And if there is a process that ultimately seems wasteful and doesn't really create a lot of optimization and
help people being creative or doing their best work, then we should rethink that process and focus more on
having individuals interact in ways that bring out the best ideas.
Prima ry :
• Individua ls and Intera ctions
• Working Softw a re
• Customer Collaboration
• Responding to Change
Se condary :
• Proce sses and Tools
• Comprehe nsive Documena tion
• Contract Negoc iation
• Follow ing a Plan
Agile Values

______________________________________________________________________________
7.2.2. Primary Value: Working Software
The second Agile value says that we should value working software over comprehensive documentation.
That means working software pieces should really be our measure of progress.
The ability to start a project and quickly prototype something, or come up with something that works, is a lot
more valuable than working for weeks and weeks, and in some cases, months, on documenting everything
very comprehensively, especially for software development projects, since there's a lot of change to the final
product across the life-cycle of the project.
7.2.3. Primary Value: Customer Collaboration
The third value is that we should value customer collaboration over contract negotiation. Accordingly, if we
have worked in an environment where we have a defined project plan, it sometimes becomes a big pain to
actually have our stakeholders request a change. That change, from out stakeholders, becomes a big
contract negotiation. A change request goes in, and then we have to identify whether the change is worth it.
On the contrary, in an Agile environment, it's understood that change is constant. Change is going to
happen. Thus, the focus should be on collaboration with the customer to make sure that we understand the
impact of the change, the need for the change, and the value that comes out of the change, instead of trying
to negotiate whether or not to make changes.
7.2.4. Primary Value: Responding to Change
The fourth and final Agile value is that we ought to value responding to change over following a plan. We
need to be able to respond to change and have a system that allows us to do so in a dynamic way, versus
following a linear defined plan, where we try to define everything upfront, which is typically going to change
over the course and lifetime of the project for certain, particularly in a software development project.
7.3. Agile first six Principles
In addition to the four Agile values outlined in the Agile Manifesto, there are 12 principles. These principles
should drive all work on our project. The first six principles are:
• Satisfy the Customer,
• Welcome Change,
• Deliver Software Frequently,
• Work Together,
• Motivate Individuals, and
• Use Face-to-face Communication.

______________________________________________________________________________
7.3.1. Agile Principle: Satisfy the Customer
It is important to satisfy the customer. The highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
7.3.2. Agile Principle: Welcome Change
It's also essential to welcome change, even late in development. Agile processes harness changes for the
customer's competitive advantage.
7.3.3. Agile Principle: Deliver Software Frequently
It's also important to deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter time-scale.
7.3.4. Agile Principle: Work Together
Working together is vital. Business people and developers must work together daily throughout the project.
7.3.5. Agile Principle: Motivating Individuals
Motivating individuals is also key to our project's success. It's important to build projects around motivated
individuals. We should give them the environment and support they need, and trust them to get the job
done.
7.3.6. Agile Principle: Use Face-to-face Communication
Face-to-face communication is the most efficient and effective method of conveying information to and
within a development team, particularly when time scales and development require the quick transfer of
information.
7.4. Agile remaining six Principles
The remaining six principles are:
• Working Software Equals Progress,
• Constant Pace,
• Technical Excellence,
• Sa tisfy the Custom er
• We lcome Change
• Deliver Softw a re Frequently
• Work Together
• Motive Individuals
• Use Fa ce-to-fa ce Comm unica tion
• Working Softw a re Equa ls Progress
• Constant Pace
• Te chnic al Excelle nce
• Simplic ity
• Se lf-organizing
• Reflec tion
Agile 12 Principles

______________________________________________________________________________
• Simplicity,
• Self-organizing teams, and
• Reflection.
7.4.1. Agile Principle: Working Software Equals Progress
This means that working functionalities in the product represent our signs of progress along the project
timeline, not the succession of project phases in a spreadsheet.
7.4.2. Agile Principle: Constant Pace
Constant pace is also needed. Agile processes promote sustainable development. The sponsors, the
development team, and the users should be able to maintain a constant pace indefinitely.
7.4.3. Agile Principle: Technical Excellence
In addition, continuous attention to technical excellence and good design truly enhances agility. Simplicity is
key and keeping everything simple is an art. Sometimes we tend to think that the more features we build or
the more complexity we build into our features, the better, when actually, the best products are the
simplest ones that have mainly the features and function the customer wants, while remaining
uncomplicated.
7.4.4. Agile Principle: Self-organizing
Moreover, the best architectures, best requirements, and best designs emerge from self-organizing teams.
7.4.5. Agile Principle: Reflection
And finally, the principle of reflection brings success, and carries it through future work. At regular intervals,
the team should reflect on how to become more effective, then the team tunes and adjusts working
behaviors and procedures accordingly.
7.5. Conclusion
The Agile Manifesto outlines four values that should be kept in mind for project management. The values
are:
• Value individuals and interactions over processes and tools.
• Value working software over comprehensive documentation.
• Value customer collaboration over contract negotiation.
• And value responding to change over following a plan.
Also, the Agile Manifesto outlines 12 principles that should help us guide our project. They are:
• Satisfy the customer,
• Welcome change,
• Deliver software frequently,
• Work together,
• Motivate individuals,
• Use face-to-face communication,
• Working software equals progress,
• Constant pace,
• Technical excellence,
• Simplicity,
• Self-organizing teams,
• And reflection.

______________________________________________________________________________
8. Agile Project Management Model
After studying this section, we should be able to identify the five phases of the Agile project management
model.
While the Agile manifesto values individuals and interactions over processes and tools, and working software
over getting caught up and focusing on comprehensive documentation, there is still a recognized value in a
model outline for successful Agile project management.
One of the authors of the Agile manifesto, Jim Highsmith, developed the Agile project management model,
which consists of five phases. It is worth noting that these five phases do not have a linear progression, but
rather they are cyclical in nature.
Agile is really a cycle and a set of iterations or loops where we are performing several different activities
within each cycle, rather than working through a prescribed path with distinct step.
8.1. Envisioning Phase
The first phase of the Agile project management model is the envisioning phase. During this phase, we
envision what this product is going to be, what type of value we should be delivering to our end-customers,
and what the vision is for the overall project or product.
8.2. Speculating Phase
The second phase is the speculating phase, in which we start thinking about how to implement different
features or functionality that will actually fulfill that vision that we created in the envisioning phase.
8.3. Exploring Phase
In the exploring phase, we are performing iterations of learning. This is the phase in which we are:
• developing code,
• developing software,
• testing it,
• getting feedback on it, and
• figuring out the way to fulfill that vision.
1 Envisioning
2 Speculating
3 Exploring4 Adapting
5 Closing
Agile Project Management Model

______________________________________________________________________________
8.4. Adapting Phase
In Agile, in every cycle, and in every iteration, there is adaptation. As we learn, we adapt and change the
plan. We might even change our idea of what is higher priority or the way we work in order to optimize and
come out with the best ideas, as much as an effective strategy for working together as a team.
8.5. Closing Phase
Because the Agile project management model is iterative, that could mean closing a specific iteration, or the
whole project.

______________________________________________________________________________
9. About Agile Methodologies
After going through these paragraphs, we should be able to identify some of the methodologies that can be
used for Agile project management.
There are what seems like countless methodologies that we can use for managing our Agile projects:
• our specific project type will help determine whether an Agile methodology is suitable and
• which methodology should be used.
We need to consider both criticality and safety and security requirements:
• we can implement an Agile model rigidly with no deviations, or
• partially tailoring it to specific needs and in combination with another methodology as a hybrid
model.
Regardless of what we select, there are a number of common methodologies that we should be aware of
and should consider for our Agile projects.
9.1. Extreme Programming (XP)
The extreme programming or XP methodology is one of the first frameworks that could be considered Agile.
The iterations involved in Extreme Programming methodology are:
• Release Plan,
• Iteration Plan,
• Acceptance Test,
• Stand-up Meeting,
• Pair Negotiation,
• Unit Test, and
• Pair Programming.

______________________________________________________________________________
XP is a software engineering centric model and was developed by a number of software engineers who
wanted to improve:
• the way they worked together as teams,
• the way they worked with their stakeholders and,
• the quality of the end product that they were building.
XP focuses on the ongoing rapid delivery of software through quick, short releases with a recommended
one-week iteration. Each iteration results in production ready code.
9.2. Lean principles & Tools
Lean principles and tools are another approach to Agile project management. They don't prescribe specific
development methods, but instead provide guidelines for streamlining the development process.
The various Lean Principles are:
• Identify Value,
• Map the Value Stream,
• Create Flow,
• Establish Pull, and
• Seek Perfection.
The guidelines are driven by seven key principles to accomplish this, eliminate waste, build quality in, create
knowledge, defer commitment, deliver fast, respect people, and optimize the whole.

______________________________________________________________________________
9.3. Kanban
Kanban, another Agile framework, is derived from Lean principles and tools.
Its principles include:
• visualizing a workflow,
• limiting work in progress (WIP),
• focusing on the workflow, and
• continuous improvement.
9.4. Crystal Methodologies
Crystal Methodologies are a family of Agile methodologies named after the colours of crystals of different
hardness.
The Crystal Methodology to apply depends on the complexity or hardness of a specific software
development project.
As the size and criticality of the project increases, a methodology with more prescribed steps would be
required, instead of Crystal, to keep control of the development process.

______________________________________________________________________________
9.5. Feature-driven Development (FDD)
Feature-driven Development provides a client-centric, architecture-centric and pragmatic software
development process.
All aspects of the software development process are planned, managed, and tracked at the level of
individual software features.
Five main activities in FDD are:
• develop an overall model,
• build a features list,
• plan by feature,
• design by feature and
• build by feature.
9.6. Dynamic Systems Development Method (DSDM)
The Dynamic Systems Development Method is another framework for Agile development and, it reflects a
business perspective instead of a technical perspective. DSDM has three phases:
• Pre-project Activities,
• Project Activities,
• Post-project Activities.
DSDM requires a large number of items and designates a large number of roles but has flexibility in the way
activities are incorporated.

______________________________________________________________________________
• Feasibility is a short phase to assess the viability and the outline business case.
• Foundation is a key phase for ensuring the project is understood and defined well enough so that
the scope can be baselined at a high-level and the technology components and standards agreed,
before the development activity begins.
• Exploration is an iterative development phase during which teams expand on the high-level
requirements to demonstrate the functionality.
• Engineering is an iterative development phase where the solution is engineered to be deployable
for release.
• In the Incremental Deployment phase, for each increment of the project the solution is made
available. The Post-project phase assesses the accrued benefits.
9.7. Model-driven Development (MDD)
MDD requires extensive models prior to production. However, the Agile version of MDD (AMDD) involves
creating incremental models just to add sufficiently detailed support throughout the project life cycle.
Therefore, an Agile team can begin by developing a high-level model of the project requirements, and then
develop more low-level models for each iteration requirement.
AMDD principles include:
• assuming simplicity,
• modeling with a purpose,
• valuing content above representation,
• creating quality work,
• communicating openly, and
• traveling light.
9.8. Disciplined Agile delivery (DAD)
This is a process decision framework that is a people first, learning-oriented hybrid Agile approach to IT
solution delivery. DAD can be considered as the foundation of the Disciplined Agile (DA) toolkit.

______________________________________________________________________________
It has a risk value delivery cycle and it is:
• goal-driven,
• enterprise-aware, and
• scalable.
DAD is not prescriptive and instead it provides the guidelines for fitting together appropriate strategies and
approaches for a successful outcome.
In general, Disciplined Agile (DA) is a hybrid toolkit that builds upon the solid foundation of other methods
and software process frameworks.
As such, DAD adopts practices and strategies from existing sources and provides advice for when and how to
apply them together.
In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide
the process bricks and DAD the mortar to fit the bricks together effectively.
The focus of DAD is on delivery and the full system/product lifecycle goes from the initial idea for the
product, through delivery, to operations and support and often has many iterations of the delivery lifecycle.
9.9. Test-driven Development (TDD)
TDD is a design technique that emphasizes unit testing with tests written before code.
Its components include:
• test cases,
• test fixtures,

______________________________________________________________________________
• test suites, and
• test harnesses.
TDD is useful for specification and validation rather than overall system design. With TDD, the idea is that
before adding a functionality:
• We write an automated test about how this new functionality, we want to introduce to our
system, has to behave:
• We then run the test and we wait for it to fail.
• Then, we update the functional code to the specification,
• Next, we write the simplest code, for it to pass.
• We run the test again and make sure that this time it passes.
• At the end, we have to refactor (even the simplest code has undesirable properties) and make
sure that we have a clean code.
9.10. Behavior-driven Development (BDD)

______________________________________________________________________________
BDD is often iterative and aims to improve a team's ability to deliver prioritized, verifiable business value
using a shared language known as ubiquitous language.
This methodology is a synthesis and refinement of practices stemming from Test Driven Development (TDD)
and Acceptance Test Driven Development (ATDD). However, BDD augments TDD and ATDD with the
following tactics:
• Apply the “Five Why’s” principle to each proposed user story, so that its purpose is clearly related
to business outcomes.
• Thinking “from the outside in”, in other words implement only those behaviors which contribute
most directly to the business outcomes, so that to minimize waste.
• Describe behaviors in a single notation which is directly accessible to domain experts, testers and
developers, thus improving communication.
• Apply these techniques all the way down to the lowest levels of abstraction of the software, paying
particular attention to the distribution of behavior, in this way evolution remains cheap.
IT teams could consider Behavior-driven Development for several reasons:
• BDD offers more precise guidance on organizing the conversation between developers, testers
and domain experts.
• Notations originating in the BDD approach are closer to everyday language and have a straight
forward learning curve.
• Tools targeting a BDD approach generally afford the automatic generation of technical and end
user documentation from BDD “specifications”.
9.11. In conclusion
An Agile Methodology is a people-focused, results-focused approach to software development that respects
our rapidly changing IT world. It is centered around adaptive planning, self-organization, and short delivery
times. It is flexible, fast, and aims for continuous improvements in quality.
There are numerous Agile methodologies we can use for our projects. Some of the most common ones
include:
• Extreme Programming or XP,
• Lean Principles and Tools,
• Kanban,
• Crystal Methodologies,
• Feature-driven Development, or FDD.
• Dynamic Systems Development Method, or DSDM,
• Agile Model-driven Development, or AMDD,
• Disciplined Agile Delivery, or DAD,
• Test-driven Development, or TDD, and
• Behavior-driven Development, or BDD.
Agile methodologies reduce the risk of spending months on a process that ultimately might fail because of a
mistake in an early phase of that project. Instead, a given Agile methodology relies on trusting IT project
teams to work directly with customers in order to understand the goals and provide solutions in a fast and
incremental way:
• Faster, smaller - Traditional software development relied on phases such as outlining the
requirements, planning, design, building, testing, and delivery. On the contrary, an Agile
methodology will look to deploy the first increment in a couple of weeks and the entire piece of
software in a couple of months for instance, through further increments.
• Communication - Agile teams within the business will work together daily at every stage of the
project through face-to-face meetings. This collaboration and communication will ensure the

______________________________________________________________________________
process stays on track even though conditions might change.
• Feedback - Rather than waiting until the delivery phase to gauge success, teams operating along
an Agile methodology will track the success and will speed of the development process regularly.
Thus, team velocity is measured after the delivery of each increment.
• Trust - Somehow, Agile teams are self-organizing. Instead of following a manifesto of rules from
management, intended to produce the desired result, they understand the goals and create their
own path to reach the given goals.
• Adjust - Participants will finetune and will adjust the process continually, following the “Keep It
Simple” principle.

______________________________________________________________________________
10. About Scrum Framework
After studying this section, we would be able to recognize the four Scrum inspect and adapt events.
10.1. Scrum: A Lightweight Agile Framework
As a lightweight framework for Agile project management, we say that Scrum is rather a framework than a
methodology, since Scrum does not prescribe how to implement certain things such as reporting, source
control, or even code.
Scrum utilizes an iterative, incremental approach which allows for predictability and better risk
management. As such, Scrum is centered around iterations or sprints that are typically anywhere between
one to four weeks in length. Most teams, nowadays, are implementing a two-week sprint length.
10.2. Spring Goals
Each sprint or iteration development period has a clear goal consisting of an agreed set of work items to
implement during that iteration.
Before starting any sprint, the Agile team gets together and agrees on the work items they will complete
within the course of a given sprint.
Therefore, at the end of each sprint, the goal is to have a product increment that can be inspected and
adapted, gaining feedback from stakeholders.
10.3. Planning
Each successive sprint then builds on the last and planning takes place in between the sprints. Still, although
we do have a general high-level plan for the overall release, sprints also allow us to inspect and adapt and
possibly change the plan for the next upcoming sprint, based on feedback or based on something we've
learned during the course of a previous sprint.
10.4. Inspecting and Adapting
The activities of inspecting and adapting are central to the success of Scrum, which includes four events that
provide opportunities to inspect and adapt:

______________________________________________________________________________
• sprint planning,
• daily Scrum,
• sprint review, and
• sprint retrospective.
Sprint planning meetings are the initial meetings where Agile teams will commit to a set of deliverables for
the sprint. As such, a sprint planning meeting is an opportunity to inspect and adapt because at this meeting,
the product owner is able to provide the team with some feedback based on either the last sprint or based
on things that have changed since the last sprint. Therefore, it's an opportunity to potentially reorder or
reprioritize the requirements backlog.
10.5. Daily Scrum
It’s true that the daily Scrum is another opportunity to inspect and adapt as a team. Everyday there would be
a Scrum meeting known as a daily stand up. It lasts typically 15 minutes maximum in which team members
discuss:
• what they've done,
• what they are going to work on, and
• any roadblocks or impediments to their work.
Each team member answers three main questions:
• What work have I completed since the last Scrum and why?
• What do I plan on completing between now and the next Scrum?
• Do I have any roadblocks or problems that the team can help me overcome?
Those items typically line up with sprint goal which have been agreed on at the beginning of the sprint.
Nonetheless, in the case that something has delayed or changed priorities, it's best to make sure that
everybody understands why the priorities changed with these work items and what challenges are being
experienced?
10.6. Sprint Review
The sprint review happens at the end of a sprint. It allows the Agile team to review and perform a demo of
the product of their work to stakeholders and to the product owner. It's also an opportunity to inspect the
team’s deliverables, to check what they've been working on, and adapt if necessary.
10.7. Sprint Retrospective
The sprint retrospective is the fourth event that provides opportunities to inspect and adapt.
In essence, it’s a meeting in which the Agile team can get together and talk about:
• what went well,
• what didn't go well, and
• what action items they can take in order to improve as a team.
10.8. Concluding Words
We may say that the primary goal of the Scrum framework is to have opportunities to inspect and adapt as
work progresses in our Agile project.
The four Scrum events that provide opportunities inspect and adapt are:
• sprint planning,
• the daily Scrum,
• the sprint review, and
• the sprint retrospective.

______________________________________________________________________________
11. Adopting an Agile Approach
After reading this section, we should be able to identify the five A.D.A.P.T steps which are essential to
transition to Agile.
11.1. Considering Adopting an Agile
While considering the adoption of an Agile approach, there are some factors to consider:
• the organizational structure,
• the project type,
• a customer's role, and
• the team composition.
All these factors influence how Agile can be adopted. All the same, it's important to consider how an
organization approaches change. On one hand, an organization that focuses on controlling change to
minimize potential disruption may struggle with an Agile methodology. On the other hand, if the focus is on
welcoming change, an Agile methodology will be easier to support.
11.2. A.D.A.P.T Steps
Regardless of the individual factors within the organization, the A.D.A.P.T steps identify five necessary
requirements for successfully transitioning to Agile, and they are:

______________________________________________________________________________
• create awareness,
• increase desire to support change,
• develop ability,
• promote successes, and
• transfer the Agile mindset throughout the organization.
11.3. Awareness
The first step of the A.D.A.P.T process is awareness. This means our organization needs to be aware of the
problems that it currently has.
• What are the process issues that are occurring?
• What are the inefficiencies?
• What are some of the issues that we want to improve upon?
Thus, it’s important to know that awareness around how Agile methodologies can help us achieve those
goals or fix those issues.
11.4. Desire to Support Change
The second step is desire to support change where there definitely needs to be a desire from our
organization, or from enough people in our organization, to make the change and to shift towards an Agile
methodology.
11.5. Ability
Ability is the next vital step for an organization to have to support an Agile approach.
In some cases, organizations may not have the ability to change because of certain factors:
• there might not be enough co-location of teams, or
• the engineering structure may not allow for elements like test-driven development or unit testing;
• it could also be down to an organization not currently having staff with the right skill sets to adopt
Agile.
11.6. Promoting Agile
Once the decision has been taken on whether to have the ability to actually move to an Agile methodology,
we start promoting it. This step includes:
• promoting Agile across the entire organization and, not just specific to our current projects;
• talking about the benefits or organization is expected to gain in adopting an Agile methodology.
11.7. Transferring
The fifth and final step is transfer. This is the step where we:
• finally make the transition, and
• start implementing Agile methodologies or frameworks in our organization.
11.8. In Conclusion
Moving to Agile is definitely not an easy undertaking. It includes change and also requires successful change
management.
It demands:
• an in-depth understanding of the reason(s) for moving to an Agile methodology, and
• comprehend why we're trying to change the way that we've done things up to now.
It involves:

______________________________________________________________________________
• cooperation with our organization’s governance,
• constraint and feedback, and
• organization and learning.
Nonetheless, the benefits for organizations that have moved to Agile methodologies have been:
• very clearly measured, and
• show a lot of improvement in areas that people and organizations care about.
A.D.A.P.T steps are required when transitioning to an Agile approach. They include:
• awareness,
• desire,
• ability,
• promote, and
• transfer.

______________________________________________________________________________
12. Initiating a Project in Agile
After going through this section, we ought to be able to identify the recommended components of a
business case, in the context of Agile methodologies.
12.1. Establishing a Business Case
When initiating any project, a good idea is to first make sure that we understand the opportunity and
whether it makes sense for our organization business to pursue that opportunity.
Consequently, the key activity for initiating an Agile project is establishing a business case or business
justification.
The purpose of having a business case is multiple. A business case helps ensure that everyone understands
what they are trying to achieve.
By establishing a business case for an end product, it becomes clear across an organization from executives
to managers, to marketing, to sales, to the IT development team, what the goal is for developing a given
product or working on such project.
Moreover, the business case also helps simplify decision-making by setting clear objectives and parameters.
Thus, by understanding those parameters, we can also start to create a framework for making decisions
around the product.
A business case also helps keep the project team focused on meeting a customer's overall objectives for a
given project. By defining the value that the customer sees or that the customer is seeking, it becomes much
easier for the team to focus on those elements, as to opposed to features or functionalities that the team
considers equally valuable.
More importantly, the business case provides the key criteria for judging the success of a project.
12.2. Components of a Business Case
Recommended components of a business case include:
• an opportunity,
• goals,
• strategy,
• project vision,
• milestones,
• investment, and

______________________________________________________________________________
• expected payback.
Certain components of a business case can include an opportunity which is a chance to create value or meet
a business need. To illustrate this point, in a hypothetical project the stated opportunity might be to update
the Facebook page with the organization's revised corporate image, to improve external communication,
and bring it in line with trend within the industry we operate in.
Another component in a business case are the goals which provide the reason why a project should be
implemented. They will inspire a team and for that reason they need to be:
• specific,
• measurable,
• attainable, and
• realistic.
Strategy is another component that ought to be included in a business case, because it’s the plan that will
help a customer achieve the specified goals.
Project vision specifies what a customer hopes a project will achieve once it's completed. Consequently, the
project vision should also be included in the business case. It also helps an Agile team to understand the
purpose of the project.
Milestones identify significant points in the development and delivery of a project or product. They should
be incorporated in our business case. Milestones help the team focus and make tracking progress it easier,
overall.
From its part, investment specifies what a customer will need to invest in a project and that, based on each
milestone.
Expected payback identifies both:
• the financial benefit or return on investment (ROI) that a customer can hope to gain from a
project;
• as well as what the payback is for the company as a result of the project.
12.3. To Summarize
There are seven different components that should be identified in a business case when we are initiating an
Agile project. They include:
• opportunity,
• goals,
• strategy,
• project vision,
• milestones,
• investment, and
• expected payback for both the customer and the organization.

______________________________________________________________________________
13. Creating a Vision and Charting an Agile Project
After reading this section, we should be able to recognize the elements of a project charter.
13.1. Developing a Project Vision and Project Charter is Key
Any project requires directions to steer the team toward success. Creating the product vision and
developing the project charter are two key activities that help guide the project team accomplishing the
goals of our Agile project.
13.2. The Product Vision
It is a compelling statement about:
• why we are building a product or service,
• the benefit the it brings,
• who we are building it for, and
• why we are uniquely positioned to develop it.
Furthermore, a product vision describes how a project can capitalize on the opportunities and fulfill the
goals of the business case. Therefore, a product vision should provide all the stakeholders, including the
development team, with a common understanding of what's required, without limiting that team's creativity
in finding adequate solutions.
13.2.1. Interviewing Stakeholders
An important part of creating a product's vision is to interview the stakeholders of the product about their
vision for the product.
Such an interview should focus on establishing minimum and maximum requirements for the product and
investigate the relationship between the project's potential risks and benefits.
13.2.2. The Vision Statement
A vision statement doesn't just describe a product's features, it focuses on how a product will add value.
Hence, it should motivate the development team and help them envision the final product.
13.3. The Project Charter
It’s a good way to:
• ensure that the intentions, outcomes and priorities are clear to both stakeholders and the Agile
team.
• to try to establish alignment on key elements of a project, especially at an early stage of the project
life-cycle.
13.3.1. Vision Statement – Element of Project Charter
A project charter may contain several elements. But one of the most common ones is the vision statement,
which defines the “why” of the project. This is the purpose, or the reason, why this project exists.
13.3.2. Objectives or Mission
Also included in the Project Charter, the objectives or mission are the “what” of the project, and they state
what will be done in the project to achieve the vision. It should also identify who the customer is and what
problem is going to be fixed with the end product.

______________________________________________________________________________
13.3.3. Success Criteria
The success conditions, or namely success criteria, are a set of outcomes or results that define success of the
project for both management teams and stakeholders.
13.3.4. Priorities and Compromises
A project charter can also contain priorities and compromises, as it's paramount to understand what a
stakeholder may and may not accept as compromises before the Agile team commences with the project.
13.3.5. Risks and Mitigation
And it's also important to know what risks the project could face and to think about the acceptable
workarounds. Risks and mitigation strategies should be included in the project charter, too.
13.3.6. Team Roles
Team roles should also be included in the Project Charter. It’s important for stakeholders and others to know
who will be doing what in the project, and that should be documented, along with a high-level overview of
what each person is responsible and accountable for (a RACI approach).
13.3.7. Project Charter Format: A One-Page Document
The most important point to note about a project charter, in an Agile environment, is that it's no more and
no less a one-page document.
It ought to include the high-level essential items, mentioned here above, which create success for a project.
13.4. Conclusion
If a project charter should be no more than a page long, it should, nonetheless, include the following
important elements:
• a vision statement,
• objectives or a mission of the project,
• the customer,
• success conditions or criteria,
• priorities and compromises,
• risks and mitigation, and
• team roles.

______________________________________________________________________________
14. About Agile Contracts
After going through this section, we should be able to identify the contract types suitable for Agile projects.
14.1. Purpose of Contracts
In general, contracts help organizations manage their risks and resources. And in traditionally managed
projects, the most commonly used contract is a fixed-price contract.
Fixed-price contracts are considered not generally the best for Agile projects, as they assume a fixed scope.
Furthermore, they also place risk on the team implementing the project for the following reason. If the work,
at the end, exceeds the estimate or if requirements change the project team has to bear that loss and still
continue with the promised scope.
Fixed-price contracts may also take focus away from what might be best for both the product and customer,
while developers become bound by legal limitations that are no longer in the customer's best interest.
In response to that, a possible solution would be for a contract to specify the overall business goals that a
project team must enable a customer to meet. Instead of specifying detailed technical requirements.
However, this isn't always practical. Because in terms of legal requirements, business goals need to be
defined in monetary terms, which can be difficult.
14.2. Suitable Contracts for Agile Projects
There are different contract types which are suitable for each development phase of an Agile project.
14.2.1. Service Contracts
For instance, in the initiation phase, we may use a service contract. Therefore, instead of measuring specific
deliverables such as product development, a service contract may measure the time, cost, and materials
spent on coming up with for a roadmap or a story map within that given project.
14.2.2. Fixed-price Contracts
In the next phase of the project, or development phase, there could be be a series of fixed-price contracts
for each iteration.
It’s important to bear in mind that some variants on the fixed-price contract include:
• fixed-range contracts, and

______________________________________________________________________________
• fixed-price per user story.
14.2.3. Cost-reimbursable or Time-and-materials Contracts
These types of contracts operate on a pay-as-use basis. Hence, it's in the client's hands to decide whether or
not to pay the team to spend more time or more resources on developing additional requirements, making
changes or enhancements, or fixing issues.
14.2.4. Not-to-exceed With Fixed-fee Contracts
Due to their nature, they can protect both the project development team and the customer.
It's made up of a fixed-fee base as well as a not-to-exceed condition. It may be, for instance, that:
• the fixed-fee base for this project is x dollars/euros/yen/francs/pesos/rupees/pounds/krones,
• and then the not-to-exceed condition is we will not exceed 15% of that base.
14.2.5. Incentive Contracts
They can also be used to motivate project development teams by offering rewards for good performance.
The types of incentive contracts include:
• fixed price with incentive,
• cost-reimbursable with award fee,
• percentage increase or decrease based on time, and
• fixed price user story with additional hourly rate.
14.3. Concluding Words
If regular fixed-price contracts are not suitable for Agile projects, many other types of contracts are. These
types of contracts include:
• service contracts for the series of fixed-price contracts,
• cost-reimbursable or time-and-materials contracts,
• not-to-exceed with fixed-fee contracts, and
• incentive contracts.

______________________________________________________________________________
15. About Agile Documentation
After reading this section, we should be able to identify helpful types of documentation for our Agile
projects.
15.1. Working Software as Primary Measurement of Progress
One key principle of the Agile Manifesto is to emphasize Working Software over Comprehensive
Documentation, which means that we prefer having Working Software as our primary measure of progress
versus Comprehensive Documents.
Agile approaches focus on keeping documentation light or having just enough documentation to help us
carry on with our efforts and make progress with our project.
15.2. Common Documentation for Agile Projects
Most agile teams use specific forms of documentation, while favoring those that are simple and highly visual.
Very common documentation forms used by Agile teams comprise:
• the Project Backlog Iteration,
• a Sprint Backlog User Story Cards, and
• a Burnup and Burndown Charts.
All of these above are, at the same time, very simple to use and highly visual, while knowing that visual
communication is a lot more effective than communication via lengthy pages of text.
Indeed, people feel that documentation is required for every process in a project. Reasons put forward for
that might be it's needed for:
• managing risk,
• following a process,
• information sharing, or
• detailing requirements.
Nevertheless, these remain not valid reasons for generating comprehensive documentation, and they
hinder, rather than help in an Agile project success.
15.3. Focus on Delivering Highest Value First
In Agile environments, we manage risk better by focusing on delivering the highest value items first, as
opposed to creating comprehensive documents.
Agile environment practices show that we can still follow a very specific and very effective process without
having comprehensive documentation. Furthermore, sharing information among teams takes place in
collaborative environments where individuals are talking verbally and communicating without the need for
documents.
That means from an Agile perspective, thoroughly detailing requirements early in a project life-cycle is rather
inefficient. For the reason that, it's too soon at that stage for project customers to know what they really
want at a detailed level, which means requirements are likely to change.
It’s common knowledge that early on in a project, there is a point in time where we know the least about the
project outcome. Therefore, that would the worst point in the project life cycle to create very detailed
comprehensive documents about what's required for that given project to succeed.
15.4. Vision Statement Document
With what has been previously said in mind, there are of course valid types of documentation that are useful
and which contribute to the success of Agile projects. An example would be the Vision Statement, which
defines the ultimate goals of a project and the “why” we're building this project.

______________________________________________________________________________
15.5. Project Overview Document
Typically, being just a few pages long, the Project Overview summarizes critical information about a project
such as the:
• Vision, Technologies used, and
• Operating processes.
15.6. Requirements Documentation
Requirements Documentation are not only helpful, but even essential to have. Product requirements may be
documented in many different forms, including for instance the Product Backlog.
15.7. Acceptance Testing Documents
These are also helpful as they lay out which acceptance criteria is used by testers to determine whether the
requirement has been met.
Acceptance Testing Documents specify those needed acceptance criteria, and they help inform project
developers on whether their work is complete, and that they meet stakeholders’ expectations.
15.8. Support Documentation
Support Documentation is designed for those who will become responsible for supporting a project and a
product after being released into production. It may include:
• Problem Escalation Procedures,
• a list of Important Contacts, and
• a Troubleshooting Guide.
15.9. User Documentation
User Document could include:
• Training Manuals,
• User Manuals, and
• Quick Reference Cards.
As such, User Documents are designed to equip users with a mean to use a product and to assist them
finding answers to questions about this product without having to contact support staff.
15.10. Creating Effective Communication
In an Agile environment, there are still documents that are generated of course, with the focus is on creating
truly effective communication, and not simply documenting whatever doesn't need to be documented. The
aim, here, is not spending too much time documenting project elements that we know will change later on
in the project life-cycle.
15.11. Summary
Helpful documentation to create for Agile projects includes:
• the Vision Statement,
• the Project Overview,
• Requirements Documentation,
• Acceptance Testing Documents,
• Support Documentation, and
• User Documentation.

______________________________________________________________________________
16. Key Agile Concepts Summarized
The Agile method prescribes best practices and standards for effective product development, thus after
thoroughly going through this section, we should be able to demonstrate and overall understanding of the
Agile principles and methodologies, including:
• recognizing characteristics of the Agile method,
• understanding Agile value priorities,
• identifying Agile project management model phases,
• distinguishing recommended Agile documentation types.
16.1. Characteristics of the Agile method
• Agile is incremental in nature, meaning work done in one phase is built upon in the next.
• The Agile methodology is iterative, and processes and phases may be repeated as necessary for
each deliverable as required.
• Agile best practice is to focus on the highest-value requirements first to ensure they are
completed and developed as required for the project. Indeed, the highest-value requirements are
addressed first, rather than on requirements that might be fastest to complete.
• In Agile projects, issues tend to surface early in the process, making it easier to address them as
required.
• A key characteristic of the Agile method is constant feedback as project work is completed,
allowing for any necessary tweaks to be implemented so the final product meets requirements.
16.2. Identify Primary Agile Value Priorities
• Agile methodology places primary priority on individuals and interactions to efficiently
accomplish project tasks. Truly, the focus is primarily on completing project work efficiently and
effectively, rather than focusing on documenting every detail.
• In Agile projects, a primary priority is on collaborating with customers to ensure the final product
reflects what the customer requires.
• Because of the iterative nature of Agile projects, a primary priority is effectively responding to
change, which is expected and encouraged throughout the project life cycle.
16.3. The Five Phases of the Agile Project Management Model
• Envisioning is the first phase of the Agile project management model.
• Speculating is the second phase of the Agile project management model.
• Exploring is the third phase of the Agile project management model.
• Adapting is the fourth phase of the Agile project management model.
• Closing is the fifth and final phase of the Agile project management model.

______________________________________________________________________________
16.4. Types of Documentation Best Suited for Agile Environments
Documentation is a secondary priority for Agile projects but is still necessary and valuable.
• The vision statement is a valuable type of documentation as it guides an Agile project work and
outlines what the project is trying to achieve.
• While highly-detailed documentation is not useful in an Agile environment, having an effective
project overview helps focus project work and priorities.
• Documents (support and user documentation) that help, and support project work are important
so work can be completed efficiently.
• It's important to document (acceptance testing documents) how project deliverables will be
measured, and how they will be tested, to ensure the project meets the expected outcomes.
• Requirements documentation is necessary so project work focuses on what the final product
should look like, how it will work, and what it will do.
• However:
o Having a project timeline is important, but in an Agile environment, highly-detailed
timeline plans are considered a hindrance rather than an effective aid.
o Agile projects focus on completing tasks that contribute to the final project deliverable
and addressing issues as they are identified, rather than documenting past results.

______________________________________________________________________________
17. Agile Principles Key Words
Ability: The third ADAPT step, where the actual ability for an organization to support an Agile approach is
assessed. Factors that can impede change include issues with collocation of teams, engineering structure, or
just not currently having people with the right skillsets to adopt Agile.
A.D.A.P.T steps: The five necessary requirements for successfully transitioning to Agile: Awareness, Desire,
Ability, Promote, and Transfer.
Adapting: Phase 4 of the Agile project management model, where changes or modifications to the plan take
place as a result of what was learned in earlier phases. Changes may include reordering priorities or altering
methodology to optimize teamwork.
Agile project management model: A five phase model that is cyclical, rather than linear. The phases are
envisioning, speculating, exploring, adapting, and closing.
Awareness: The first ADAPT step, where an organization seeks to become aware of its problems or goals and
how Agile methodologies can help to achieve goals or fix issues.
Closing: Phase 5 of the Agile project management model, where a specific iteration, or the whole project,
ends.
Daily scrum: An opportunity to inspect and adapt as a team via a daily stand-up meeting, typically 15
minutes maximum, in which team members discuss what they've done, what they are going to work on, and
any roadblocks or impediments to their work.
Desire: The second ADAPT step, where there is clear determination from the organization, or from enough
people in the organization, to make a change and shift toward Agile methodologies.
Envisioning: Phase 1 of the Agile project management model, where initial consideration is given to
determine the project or product, business value, and vision for the overall project or product.
Exploring: Phase 3 of the Agile project management model, where iterations of learning take place as a
product is developed, tested, reviewed, and reworked in order to fulfill the vision created in the envisioning
phase
Promote: The fourth ADAPT step, where a concerted effort is made to advocate for Agile across the
organization, including the benefits that the organization can expect to gain.
Scrum: A lightweight framework for Agile project management that utilizes an iterative, incremental
approach which allows for predictability and better risk management. It consists of four events: sprint
planning, daily scrum, sprint review, and sprint retrospective.
Speculating: Phase 2 of the Agile project management model, where creative thinking starts with regard to
how to implement different features or functionality in order to fulfill the vision created in the envisioning
phase.
Sprint planning: A meeting in which the team commits to a set of deliverables for the sprint. The product
owner provides the team with feedback, which allows the opportunity to potentially reorder or reprioritize
the requirements backlog.
Sprint retrospective: A meeting in which the team assembles to discuss what went well, what didn't go well,
and what action items they can take in order to improve as a team.
Sprint review: A meeting held at the end of a sprint that allows the team to review and demo the product of
their work to their stakeholders and to the product owner.
Transfer: The fifth ADAPT step, where the transition is made to begin implementing Agile methodologies or
frameworks in the organization.

______________________________________________________________________________

Agile Project Management Principles and Methodologies - Study Notes

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to Agile Project Management Principles and Methodologies - Study Notes

Similar to Agile Project Management Principles and Methodologies - Study Notes (20)

More from OxfordCambridge

More from OxfordCambridge (20)

Recently uploaded

Recently uploaded (20)

Agile Project Management Principles and Methodologies - Study Notes