Introduction to Agile

Learning Objectives

This module explains the background to Agile Project Management, and presents an overview of

different Agile approaches. It explains how Agile Project Management based on DSDM is positioned

within different Agile approaches. It also gives you a chance to capture your concerns, if indeed you

have any, about choosing an Agile approach.

Agile Project Management Source

Agile Project Management thinking has been evolving over many years. DSDM stands for Dynamic

Systems Development Method. DSDM is a robust Agile Project Management and delivery framework. It

was launched in 1995 as an alternative to large prescriptive project management methods, and has its

roots in RAD, which stands for rapid application development. DSDM originally sought to provide

some discipline to RAD. In 2007, the DSDM Consortium released Atern. The word Atern was formed

from shortening the words arctic tern, a bird that is seen as being highly collaborative. In 2011, the

APM group and the DSDM Consortium created the first accredited Agile Project

Management Foundation and Practitioner Qualifications. In 2014, AgilePM v2 was released to better

reflect trends in evolutionary solution developments. A common mistake made in project

management is to blame a particular approach for the failings of one or more projects. The most likely

cause of failure is that the approach has not been implemented appropriately.

Agile Concerns and Issues

It's likely that you've heard of Agile. There are many misconceptions as to what it means and how it's

applied. These may be genuine, but may also be based on hearsay or second-hand experiences.

These misconceptions may be because of misunderstandings of what Agile is, or as sometimes

happens, these could be led by Agile fanatics who insist that Agile does not do this, or Agile does not do
that. In reality, Agile has to be pragmatic, and in some organizations, has to be stronger. Take a few

moments to write down your concerns. You should find that they have been addressed by the end of

the course. If you find they haven't, then please contact us and our Agile Project Management experts

will be happy to resolve them. Some common misconceptions and the Agile responses have been

included within the support material for this module.

What Is Agile?

Agile, in this context, is a generic style of working. It takes a holistic view of projects, rather than being

just a set of delivery techniques. Have you ever been involved in a project that spans several months,

only to have customers not use the end result? Most developers have, and probably more than once.

Ensuring that what you develop actually addresses the needs of the client has always been one of the

biggest challenges in any development. Addressing this problem was one of the motivations behind the

Agile Manifesto. The first guiding principle of the Agile Manifesto states that our highest priority is to

satisfy the customer through early and continuous delivery of valuable outputs. In a fast-paced

environment, Agile ensures that solutions meet the business needs and is focused on timely delivery.

Delaying decisions as much as possible until they can be made based on facts and not on uncertain

assumptions and predictions is fundamental to an Agile approach. This does not mean that no planning

should be involved; on the contrary. Planning activities should be concentrated on the different options

and adapting to the current situation, as well as clarifying confusing situations by establishing an

environment where rapid action can be taken. Agile is all about flexibility. The principle of responding to

change over following a plan is considered a strength of Agile. This does not mean that Agile does

away with the need for planning; things change, and you want to have flexibility to adjust and react to

those changes. You clearly want to have a plan for where you're headed and approximately how you'll

get there, but you also want to leave room to adjust your plan. You'll see as you move through

this course how the generic style of working is demonstrated throughout Agile Project Management.
Agile Approaches

There are a number of specific Agile approaches, as well as a generic Agile style of working. Extreme

Programming is a software development methodology containing mainly programming practices, such

as test-driven development, pair programming, and continuous integration, but little management. Lean,

which came from the manufacturing environment, is all about efficient processes. The focus is

on eliminating waste from the production line, and thereby reducing cost. Scrum is a very simple Agile

process designed for delivering software in small chunks, taken from a backlog of work to be done.

The strength of Scrum is that it is very simple, but this is also a weakness, because there is no concept

of a project that is managing delivery of a finite piece of work with a process containing a beginning,

middle, and end. Scrum, Lean, and Extreme Programming are lightweight approaches with minimal

structure and guidance. DSDM and Agile Unified Process are stronger, but are still Agile. The strength

of DSDM lies in it being designed to deliver projects in an Agile way.

Agile Manifesto

In 2001, representatives of all the leading Agile methods got together in the USA and created a

Manifesto for the newly formed Agile Alliance over a two-day period. Some Agile methods, for

example, XP, are way over to the left-hand side of the Manifesto statements, and others are seen as

more middle-of-the-road. DSDM is more middle-of-the-road, but still conforms to the Agile alliance.

Agile has traditionally been seen as a way of delivering IT projects, but it has been successfully applied

to many types of projects.

Which Agile Approach

Going Agile is not necessarily a simple choice, since Agile is an umbrella term to describe a generic

style of working. Within Agile, some of the approaches are very lightweight and provide little structure or

guidance. For a simple environment, these lightweight approaches may be sufficient. For a

complex environment, where an organization is running projects within programs, and where an

organization has to comply with formal processes such as CMMI, ITIL, or external quality processes, a

stronger Agile approach is usually needed. Some organizations choose a lightweight approach, such as

Scrum, and then build their own management structures around it. However, this complex

corporate environment is just the backdrop that DSDM is built upon, often described as Agile with rigor.

It maintains agility, but is designed to work within and work with corporate constraints, many of which

are non-negotiable.

Module Summary

This brings us to the end of this module. During this module, you have seen how Agile has evolved over

the years, and that it is seen as a generic style of working to ensure that the right solution is developed

on time within budget to meet the business needs. Agile Project Management is based on DSDM, and it

is this approach that forms the basis for the APMG, Agile Project Management Foundation and

Practitioner Qualifications. You may still have some concerns about using Agile Project Management,

but these should be addressed as you progress through this course.

Agile Project Management - The Basics

Learning Objectives

This module will outline the basic components of Agile Project Management to provide you with a

framework to help with your understanding of the approach. The philosophy of Agile Project

Management will be explained, and each of the principles investigated, and how they support the Agile

Project Management philosophy.

The Basics

Each diagram here represents a main component of the Agile Project Management's framework. We'll

take a brief look at each of them. The philosophy overarches the way we do things. This is supported
and underpinned by the eight principles, which describe the Agile Project Management's attitude and

mindset. The life cycle supports the principles. These are key factors that need to be in place for DSDM

projects to deliver successfully. The roles and responsibilities covering who does what are shown in the

form of an alien baby. Then we have the products that are produced when they are created and

how they evolve through subsequent phases. Lastly, there are techniques such as MoSCoW

prioritization, iterative development, timeboxing, facilitated workshops, and modeling. If you

haven't already done so, take a look at the Agile primer under support materials to familiarize yourself

with these components.

What Is Negotiable?

This diagram shows the basic difference between a traditional and a DSDM approach. On a traditional

project, 100% of the features and full quality are promised at the start. When problems occur,

typically the deadline slips, time varies, and this usually increases costs. More people are assigned to

work on the project, which also increases costs, and often still results in time slippage as newcomers

are brought up to speed. Quality is also viewed as at risk, simply because testing comes at the end of

the lifecycle, as does documentation, so it is often skimped. It is common and also bad practice

for customers to try and fix features, cost, and time. They will say, I want it all by this date with this

team. This is usually impossible, and it is important to agree up front what can be negotiated if problems

occur. Agile Project Management takes the opposite approach. Early in the project, typically at the end

of Foundations, a deadline, costs, and team size are agreed. The quality standard to be achieved is

formally defined. The requirements are prioritized and the must-haves for the project are confirmed. If

problems occur, then the least important feature will be dropped. Delivery on time of a less than

100% solution is viewed as more important than late delivery of everything. It is important to stress that

the least important and least valuable features are negotiable.

AgilePM® - Philosophy
The Agile Project Management philosophy is that any project must be aligned to clearly define strategic

goals and focus on early delivery of real benefits to the business. It's vital that stakeholders buy into the

philosophy. The key stakeholders, including the business and technical representatives, need to have a

good understanding of the business objectives for the project. The solution development team need to

be empowered to take decisions about the development. There needs to be a great deal of

collaboration among all stakeholders to ensure the solution meets the business needs. The business

needs to understand that they will get a working solution on the agreed date, and that it won't always be

100% of the solution. And first using an Agile Project Management approach, the stakeholders will have

concerns. They'll say, so you can't always say at the outset exactly what I will get in the end.

Their concerns are relayed by explaining that they will be defining what is important to meet the

business needs, and that the majority of the discussion is around the finer detail of the deliverables, and

not the major requirements. Change is inevitable, as more is understand about the solution being

developed.

The Principles

The eight principles support the Agile Project Management philosophy. They represent an ethos-- a

culture and a way of working. They give guidance of the attitude and mindset required for Agile Project

Management in order to deliver a consistent approach. Breaking any of the principles will be a risk to

the integrity of the Agile processes and to the success of the project. The principles are based on best

practice in its truest sense. They define the way things are done. The first principle is focus on the

business need. The second principle is deliver on time. The third principle is collaborate. The fourth

principle is never compromise quality. The fifth principle is build incrementally from firm foundations.

The sixth principle is develop iteratively. The seventh principle is communicate continuously and clearly.

The eight principle is demonstrate control. Each of these will be looked at in detail over the next eight

lessons.
Principle 1

Focus on the business need underpins the fact that every decision taken during a project should be

grounded in what the business actually needs. A project is a means to an end, not the end itself.

A sound business case is at the heart of every project, and it should be based on what the business

priorities are. Ongoing commitment from the stakeholders is essential to ensure that the project

will satisfy the business priorities. A job project management has a high level of direct involvement from

the business representatives on projects and in project teams. A lack of commitment to

providing resources from the business to an Agile project team is often a source of failure for Agile

projects. Managing stakeholders so that the business delivers on these commitments is critical. If the

business is not involved, or if they do not deliver on their commitments, even an Agile project with the

best team of developers in the world will fail. The minimum usable subset represents the must-

have requirements defined using the MoSCoW technique. The business roles that are defined in Agile

Project Management ensure that there is a high level of business involvement in the project. The

business products that are created in the Foundations phase provide a clear statement of the business

vision for the project. The prioritized requirements list by the end of Foundations defines the overall

scope of the project and is prioritized using a MoSCoW technique. This defines the high level must-

have, should-have, and won't-have for now requirements for the project. Timeboxing is used to control

the creation of the low-level products in an iterative way, and the application of the MoSCoW technique

prioritizes these low-level products to ensure the time boxes finish on time and are continuing to meet

the business need. These two techniques contribute to the successful application of this principle.

Principle 2

On time delivery is often the single most important success factor for the business. Late delivery can

undermine the whole rationale for the project, especially if there are market deadlines or

legislative deadlines. The two key techniques that support this principle are the use of timeboxing and

the application of MoSCoW prioritization. Timeboxing concentrates on delivering on time at the lowest

level, which means on time delivery at the highest level is guaranteed. MoSCoW prioritization

requirements within the timebox and continually reviewing what can be achieved in the agreed

timeframe ensures that timeboxes finishes on time every time.

Principle 3

Teams collaborating and working in an active spirit of cooperation will always outperform groups

working only in loose association. Collaboration encourages increased understanding, greater

speed, and shared ownership of the project. Stakeholders are involved at the appropriate time

throughout the project, and it is this close collaboration with the development team that empowers

the team members to make decisions about the development. The roles of business sponsor, business

visionary, and business ambassador are key in ensuring appropriate business representation. The

business analyst is responsible for ensuring that the business needs are properly analyzed and

correctly reflected in the guidance that the time needs to generate a solution. Facilitated workshops

contribute to greater buy-in as participants feel more involved and committed, having had the

opportunity to participate and contribute to both the content and the decisions made. This helps them

build rapport and fosters a team spirit.

Principle 4

In our job project management, the level of quality should be defined at the start of the project, and all

work should aim to deliver that level of quality no more, no less. If the business agrees that the features

defined in the minimum usable subset have been provided adequately, then the solution should be

acceptable. Unlike traditional projects, quality should not become a variable, it is fixed at the outset. The

design and testing are driven by the quality required, and documentation should be appropriate to the

quality needs. Tests are written before the deliverable is produced, so all parties are aware of what the

quality of requirements are, and this also enables tests to be undertaken early and frequently

throughout development. Early and ongoing testing helps ensure the quality of the evolving solution.
Nasty surprises should not occur. On time delivery is considered part of the quality acceptance for the

project. Initial MoSCoW prioritization of the work and continual reassessment of what can be

achieved within a timebox ensures that timeboxes finish on time every time.

Principle 5

In order to deliver real benefit early, Agile Project Management advocates incremental delivery. A series

of releases is referred to as increments, with each increment providing more functionality to the

business. After the first increment, the core product is delivered, which can already be used by the

customer. This encourages stakeholder confidence, and creates feedback for subsequent increments.

Based on feedback, a plan is developed for the next increment, and modifications are made

accordingly. This process continues with increments being delivered until the complete product

is delivered. Agile advocates first understanding the scope of the business problem to be solved and

the proposed solution, but not in such detail that the project becomes paralyzed. Analysis paralysis

needs to be avoided. The scope is defined and a high level plan is produced during the Feasibility

and Foundations phases. The project is then developed incrementally through Evolutionary

Developments.

Principle 6

Where incremental delivery is about delivering smaller portions at a time, iterative development is about

developing through repeated cycles, often adding more functionality to the product. Multiple iterations

repeat or return to create a fully integrated product. For example, a website may allow payment by

credit or debit cards, but the ability to pay by PayPal may be added within a later iteration. The concept

of iteration is embedded throughout the lifecycle, down to the lowest level of development

timeboxes. Agile Project Management is pragmatic about change, using iteration to embrace change

and produce a better solution. It recognizes that change is inevitable, and therefore enough design is

done up front to create the foundations for development to start. This allows for more detail to emerge,
and the solution to evolve throughout development. Within the constraints of time and cost, change

is actively encouraged via feedback to evolve the most appropriate solution. Constant review ensures

that what is being developed is what the business really needs.

Principle 7

Poor communication is often cited as the biggest cause of project failure. Agile Project Management

techniques are designed to improve effectiveness of communication, both for the team and for

individuals. It emphasizes the value of human interaction. This is far more effective than communication

through large textual documents. The customer and supplier work very closely together in order to

break down any potential communication barriers. The solution development team are encouraged to

have daily stand-up sessions where issues can be shared and often resolved without the need for

escalation. Facilitated workshops ensure a team-based approach to rich communication

and collaboration. Many projects benefit from the use of models, prototypes, and mockups to

communicate.

Principle 8

The project manager takes a more facilitative role in Agile Project Management, but it is still essential

to be in control of a project at all times. This requires a change of style for those project managers who

are used to controlling their developers tightly. The level of formality for tracking and reporting needs to

be appropriate to the project. Progress is monitored by the delivery of products and the project viability

is continuously evaluated based on the business objectives, which can often change throughout the

project. The use of well-defined timeboxes with constant review points, plus preparation of management

foundations and timebox plans are designed to assist the project manage and the team to follow

this principle. Control is not just viewed as a project management issue. This principle applies to the

whole team.
Module Summary

This module has outlined the basic components of Agile Project Management to provide you with a

framework to help with your understanding of the approach. The philosophy of Agile Project

Management has been explored, and each of the principles investigated on how they support the Agile

Project Management philosophy.

Roles and Responsibilities

Learning Objectives

This module will look at the roles defined within Agile Project Management and identify the roles

included in each of the project, solution, and supporting categories. It will also look at the key

responsibilities of each role.

Roles and Responsibilities

This diagram, known affectionately as the alien baby, shows how the team fits together. Orange

indicates business personnel, blue indicates the project management personnel, green indicates

the solution and technical roles which contribute to the technical development of the solution, and grey

indicates process roles. The project level roles are the directors, managers, and coordinators of the

work for the project, made up of the business sponsor, business visionary, business analyst, technical

coordinator, and project manager. The solution development team roles are the engine room of the

project. They shape and build the solution and are collectively responsible for its day-to-day

developments and for assuring its fitness for business purpose. The solution development team is

made up of team leader, business ambassador, business analyst, solution developer, and solution

tester. The business analyst facilitates the relationship between the business and technical roles,

ensuring the business needs are understood by the solution development team. The supporting roles
are made up of the business advisors, technical advisors, workshop facilitator, and DSDM coach. They

provide assistance and guidance to the project on a more ad hoc basis throughout the lifecycle.

Project Role - Business Sponsor

This is the most senior project level business role. A good business sponsor increases the likelihood of

success for the project. The sponsor's prime concern is in the value and benefit of the project, rather

than the fine details. The sponsor is responsible for the business case, will own the solution once it

is delivered, and will be responsible for the realization of any benefits associated with it. They make

sure that the funds for the project and any other resources required are made available. Because

Agile projects move at a fast pace, the sponsor needs to respond rapidly to issues raised, and they

need to be at an appropriate position in the organization to resolve business issues and make financial

decisions.

Project Role - Business Visionary

The business visionary provides the big picture and the context for the project. Where the project is part

of a larger program, the visionary is in a position to judge project issues in the light of the program and

the potential impacts beyond the project. The business visionary is more actively involved than the

business sponsor, and is responsible for interpreting the needs of the business sponsor and

communicating these to the team. They remain involved throughout the project, providing strategic

direction, and ensuring that the solution will enable the benefits to be achieved. They ensure there is

collaboration across the business areas affected by the project and act as the final negotiator if there

are any disagreements between team members. The business visionary has responsibility to contribute

to the key requirements, and to approve changes to the high level requirements in a Prioritized

Requirements List. We will be exploring the Prioritized Requirements List later in the course.

Project Role - Business Manager

In our job project management, the role of project manager is not necessarily the same as a project

manager role on a traditional project. In Agile Project Management, the team leaders often do

what would usually be considered a traditional project management role. There is normally only one

project manager, or at least a single person who is ultimately accountable for delivery of the project. For

example, where you have a supplier project manager and a customer project manager, only one of

these would hold the final responsibility for the delivery. The style of an Agile Project Manager is

more facilitative than command and control. The project manager coordinates all aspects

of management of the project at a high level. In line with the Agile Project Management concept of

empowerment, the project manger is expected to leave the detailed planning and delivery of the

products to the team leader and members of the Solution Development Team. The project

manager should take responsibility for both the business and delivery aspects of the project, from

establishing the foundations of the project through to the deployment of the solution.

Project Role - Technical Coordinator

The technical coordinator role is the technical equivalent to the business visionary, ensuring that the

solution is technically sound and cohesive. The technical coordinator is responsible for ensuring that

non-functional requirements are achievable and sensible. Non-functional requirements describe

how well something needs to be carried out, for example, the security or performance aspects of the

solution. This is the technical design authority, providing the glue that holds the project together

while advising on technical decisions and innovation. The technical coordinator determines the

technical aspects of the project, and ensures that the project meets any appropriate industry

standards. They're also responsible for managing the technical transition of the solution into live use.

Team Roles

The solution development team on an Agile Project Management project is empowered to make

decisions on a day-to-day basis within their agreed terms of reference. They do not have to formally
agree each decision with the project manager. Team leaders are often selected by the team, and can

be rotated. This is a leadership role, rather than a management role, and the person holding it will

ideally be elected by his or her peers as the best person to lead them through a particular stage of the

project. The business analyst role is important, especially in a large corporate environment, where this

is more likely to be a dedicated role than combined with the solution developer role. The business

analyst must not act as a blocker for direct contact with the business. They typically work alongside the

business, but they are not empowered to make decisions on behalf of the business. The business

analyst is the guardian of the prioritized requirements, ensuring that the project scope does not balloon

and that only low-level detail is added during development of the solution once Foundations have been

base-lined.

Solution Roles

Solution developers carry out the work required to deliver the technical or specialist products. If they are

not full-time on the project, then the project must be their top priority. Typically the solution tester reports

to the technical coordinator about the test results and quality, rather than to the team leader. The tester

and developer roles are often merged, but larger organizations usually have specialist testers.

Technical advisor supports the team by provision of specialist technical input. They are the technical

equivalent of a business advisor. Examples of this role could be operations or support technical author

or an IT security expert.

Business Ambassador and Advisor

The business ambassador is one of the business roles within the solution development team. These are

typically highly skilled, very busy people who the business struggles to spare. The role provides the

business perspective for all the decisions related to the way the solution's fitness for business purpose

is defined and implemented. The business ambassador guides the development of the solution. The

business advisor, who is often a peer of the business ambassador, is called upon to provide specific
and often specialist input into the solution development or testing. They are typically a subject matter

expert, and might come from such areas as compliance, legal, financial, or security. This role must

be filled by named individuals who accept the responsibilities and have adequate time available.

They're not expected to have as much day-to-day involvement with the project as the business

ambassador. There may need to be several levels of business advisor involvement on larger projects.

Supporting Roles

A workshop facilitator with no stake in the outcome of the workshop enables the group to work together

to achieve an agreed goal. Workshop facilitators need to be effective, trained, and independent.

A DSDM coach can be very useful for a team with limited experience of using Agile Project

Management. They are there to help the team members get the most out of the approach. The coach

should ideally be independently certified, which ensures they are competent to fill this role.

Module Summary

This module focused on the roles defined within Agile Project Management and how each role fits into

one of the project solution and supporting categories. It's also looked at the key responsibilities of each

role.

Preparing for Agile Project Management

Learning Objectives

This module looks at the style of project management required for Agile Project Management. It

confirms the constraints that need to be managed, what is seen as the main factors that are

instrumental to delivering successful Agile projects, use of the Project Approach

Questionnaire, determining risks that a project is investigating. This module also looks at how testing

and configuration management are applied to Agile Project Management.

Management Style

Agile Project Management requires a more hands-off management style. Project managers are more

focused on troubleshooting rather than directing. Agile Project Management is a practical process,

designed to cope with uncertainty by progressing through a series of small steps and inspecting and

adapting after each step. This is very similar to a sailing journey. There is a big plan, but a sailor does

not expect to predict the exact time they will be at a specific GPS position. Good sailors adapt to the

tides, winds, and currents as they go. This is also typical of Agile. The progress of the project is

measured by the delivery of products, not by the activities to produce them. Velocity is the speed at

which the products are delivered. Agile Project Management is designed to keep the velocity at a high

rate throughout the project. The teams are empowered and our search will be self-directed, rather

than taking directions from the project manager. This means that the style of project management

should be more hands-off, where the project manager focuses on resolving problems, so that the team

can get on with doing what needs to be done. Collaborative effort is key to the success of Agile Project

Management.

Agile - Management Style

The columns on the left share the characteristics of a team that needs tight management, and this may

be typical of a more traditional style of management. Agile projects are very dynamic with rapidly

evolving solutions and frequent demonstrations by the business ambassadors and business advisors.

There's no time to manage this daily activity using a bureaucratic approach. Everybody will know what

is happening because they're part of a small team working closely together. The team takes the

initiative to produce what is required. The team worked together to produce the solution and

close collaboration and cooperation. Regular reviews are built into the process to ensure the team

inspects and adapts. The teams take a much more proactive rather than reactive approach to the

project.
Understand Your Constraints

The biggest risk to successful implementation of Agile Project Management is the culture shift that is

required within an organization to truly want or need to become Agile. The organization must be

prepared to adopt the principles, understand what this means to the way they need to operate to get the

most out of Agile. Consideration needs to be given to the roles, the people available to fulfill the roles,

and their understanding of what is required of them. This may be different from their existing project

management roles. Agile Project Management needs people fully committed to the approach to be fully

effective. The project variables need to be understood. Contingency depends on there being sufficient

flexibility in the depth and detail of the features. The project will be seriously compromised if the majority

of the features are defined as must-haves. The project approach questionnaire helps to identify the

risks in using Agile Project Management, and then steps can be taken to overcome them. The drivers

for the project need to be understood, and the project approach questionnaire is a mechanism to help

get the approach right. Before we look at the questionnaire, we need to consider the key factors that

instrumental to the success of Agile Project Management, which we will look at in the next two lessons.

Project Constraints - What Is Important?

In a traditional project approach, functionality is fixed early on in the specification, and the project

promises to deliver 100% solution. The project manager then manages resources and time to

deliver the agreed features. In Agile Project Management, the project timeframe is absolutely fixed by

the end of the Foundations phase, once enough analysis and design has been done to give

a reasonable level of confidence in what is needed. The team size is fixed, because as research and

experience show, adding more resources to an already late project usually makes it even more

late. Requirements must be variable. Printing a newspaper is a good example. It must be printed on

time, but if a new story arises, they don't delay printing and delivery of the paper, they drop a

lower priority story. Sometimes a critical new item is included early as a newsflash, with details in the

next edition. Typically traditional projects allow a 10-20% contingency around cost and time to deliver
the fixed features. Contingency in Agile Project Management is typically driven by the use of the

MoSCoW technique. The timebox plan should allocate no more than 50-60% of the overall effort to

the must-have requirements. This leaves 40-50% of the effort to be allocated to the shoulds and coulds.

In the event that the musts require more effort than planned, effort can be redirected from the

shoulds and coulds. It is, however, an expectation that the project will deliver more than the musts. The

high level of contingency means that only in exceptional circumstances will a project only deliver the

musts.

Agile Project Management

When a situation develops that makes reaching the projected results difficult or impossible, then

decisions needs to be made on how to resolve the situation. This can occur at different hierarchical

levels in the project. The decision topics for each level need to be documented in the management

approach definition, so that each level knows what the limits of empowerment are and when to

escalate. Only major issues are escalated beyond the team. Changes to the depth of detail are what

Agile is all about, allowing the team to make changes as necessary to get the job done. Changes in the

breadth of the solution are changes to the overall scope of the project, which was set at the end of

Foundations. These changes in breadth, for example, to add a major new function, will need to be

escalated to the business visionary, and maybe even the business sponsor. Where the project is part of

a program, then escalation becomes more complex, and all parties need to have a clear escalation

process in place to enable fast decision making.

Factors Instrumental to SUCCESS

The following factors are important in making Agile Project Management work effectively in any

organization and is seen as factors instrumental to success. The philosophy of delivering the right thing

at the right time and handling change dynamically may result in less than 100% of the solution being

understood. The Solution Development Team needs to be empowered to make rapid knowledge-

based decisions. It's important to have a high degree of business involvement, which comes from the

business ambassador and advisor. This ensures that decisions are business led. Incremental delivery

enables early return on investment, and the business benefits are achieved as early as possible. How

the Solution Development Team gets access to the business roles needs to be considered. Core

location is ideal, but often work is split across sites or across the world. The Solution Development

Team stability relies on the use of rich communication, team knowledge, and having an optimum

Solution Development Team size of seven plus or minus two. There's always a risk of bringing

in additional resources during the project to catch up, a common traditional practice, which in most

cases doesn't work, as productive team members slow down or they bring new team members up to

speed. It also usually means stealing resources from another project. The importance of the team

memory cannot be underestimated, especially since there's no detailed sign specification to fall back

on. The supportive commercial relationship requires collaboration between all parties in order to

achieve the best possible solution in the given time scale. These factors need to be addressed early,

as they're key to successful Agile projects. Where the issues cannot be addressed, then they should be

treated as a risk to Agile project Management, and managed accordingly. Many projects

successfully use Agile Project Management while still identifying that some of these factors will not be in

place. These projects recognize the Agile Project Management offers reduced risk, yet still offers

a much higher probability of success and adopting an approach that statistically often fails to deliver the

expected outcomes.

Project Approach Questionnaire (PAQ)

Typically this project approach questionnaire is completed by the project manager with the sponsor,

visionary, and technical coordinator during the Feasibility phase. It will be revisited by the end of the

Foundations phase, when there is a better understanding of the working relationship and some of the

early answers captured during feasibility may have changed. There is no expectation of a 100% set of
strongly agree responses. Any neutral or negative responses present a risk to the Agile approach, and

these risks need to be addressed and mitigated. The results of the PAQ will help populate the risk log.

Testing Concepts

Testing is an important practice in upholding the principle to never compromise quality. It takes

place throughout the lifecycle. The value of early defect identification should not be underestimated. It

can be tens of times cheaper to rectify a problem during exploration as compared to

production. Therefore, the aim is to fail fast. The inclusion of the solution tester, business, and

developer roles within the Solution Development Team encourages collaborative testing. There needs

to be some form of documented test scripts. They don't need to be formal, but there is a need to be able

to recreate errors and then prove the fix has worked. Testing the solution from a process perspective

should be started as soon as possible. An Agile product should be tested by someone other than its

creator to ensure that both the requirement is understood and that the product meets it. Active

involvement of the business role ensures that an independent perspective is applied. Tests need to be

prioritized, because it's not possible to exhaustively test all products. The primary method

of prioritization is the MoSCoW technique. Each test should be aligned to a requirement. With test

driven development, the tests are specified before the product is created. This ensures that

the acceptance criteria are confirmed before any effort is wasted on creating the wrong product. Risk-

based testing means ensuring that tests are focused on the higher risk areas first, rather than running

lots of low value tests.

Preparation - Configuration Management

Configuration management is an important aspect of Agile projects. It enables the team to keep control

of the solution as it evolves to avoid duplication or conflict of effort, and to ensure that that at all times

reverting to the last safe point a baseline is always possible. Configuration management involves

identifying all the component parts, configuration items, and supporting items, such as documents
from across the lifecycle, controlling their storage, and knowing their status, i. e. draft or accepted, and

their interdependencies at all times. This contributes to the change control approach and a quality

control. The configuration management approach must be appropriate for the project. Excessive

formalities should be avoided. It must not impeded progress or prevent necessary change. All too often

the Solution Development Team, left to their own devices, will avoid deciding to baseline a product.

Therefore, the configuration management approach needs a champion within the project who

is responsible for administering the approach and resolving any differences of opinion. The

configuration management champion is often the technical coordinator, or a nominated member of the

Solution Development Team.

Module Summary

This module has explored many of the project management fundamentals that are important to take into

account when delivering an Agile project. If the instrumental success factors are not understood, then

the use of the Agile Project Management can introduce risks. The Project Approach Questionnaire

forms a useful basis for considering these risks. Testing is important in upholding the never

compromising quality principle. This module has also looked at configuration management, which is a

discipline that still needs to be applied to an Agile project and the formality of it needs to be agreed at

the start of the project.

The Pre-project and Foundation Processes and Products

Learning Objectives

This module introduces the Agile Project Management lifecycle, and the products produced over the

lifecycle. It then looks at the first three phases, Pre-Project, Feasibility, and Foundations phases,

and the products that can be produced within these phases in more detail. These first three phases are

completed sequentially. There needs to be a good understanding of the scope of work, how it will be

carried out, and by whom, before moving on to developing a solution. There also needs to be some
documentation to support this. We will look at what is done in each phase and how these phases and

products can be adapted in different sizes of projects.

The Development Framework

This lesson will give you a brief overview of the Agile Project Management lifecycle. The project lifecycle

has six phases. In line with the fifth and sixth principles, the Agile Project Management lifecycle is both

iterative and incremental. The solution may not be delivered to the business in one go, but in a series

of increments that increase the breadth and/or depth of the solution with each delivery. In this way,

urgent business needs can be addressed early, whilst less important features are delivered

later. DSDM integrates a project management lifecycle and a product development lifecycle into a

single framework. The Pre-Project phase ensures that only the right projects are started and that

they are set up correctly. The Feasibility and Foundations phases are completed sequentially. They set

the ground rules for the iterative and incremental developments that is to follow, and there is a clear

break between Foundations and the first iteration of the development phase. Feasibility and

Foundations can be merged in small projects, and the key thing is to understand the scope of the work,

how it will be carried out, by whom, when, and where. It also assesses whether or not Agile Project

Management is a suitable approach for the project. The idea here is to just enough planning up front.

The definition of these early phases is unique to Agile Project Management, and provides the stable

and high level baseline against which the project is managed. Without this baseline, controlling scope is

almost impossible. During the evolutionary development phase, all or part of the problem or

opportunity is investigated, and a partial solution is created and made robust enough for operational

use. The Solution Development Team work within timeboxes and use iterative development,

MoSCoW prioritization, modeling, and facilitated workshops to create a solution that will be technically

accurate and meet the business needs. The deployment phase places the solution created in

an increment in an operational use. There are three possible outcomes of deployments. The first is that

all the requirements have been s satisfied, and hence, no further work is currently needed. Then, there
is no returning arrow. The second is that a major change of scope was discovered during developments

that had to be ignored for the time being in order to deliver on the required date. This means returning

to the Foundations phase and taking a process on from there. The third is that features that were

already planned for the next increment are now to be added, or that the next increment will solely

address areas of technical concern, so the process returns to evolutionary development. After the

project has delivered the solution to the business, the project team is disbanded and the post-project

phase comes into play. This covers such activities as keeping the solution operating effectively

and checking that the expected business benefits have been achieved.

Products - Summary

Each phase of the project has a minimum set of products produced, referenced, or updated from it. The

color coding is such that orange indicates business products, blue indicates the project

management's control products, and green indicates all products that contribute to the solution being

created. The product's descriptions are generic and should be refined to suit the needs of each

organization and project. Take care not to make them too prescriptive, so that the flexibility that has

been built into Agile is not lost. Not all of the products will be required for every project. The products

marked with a G are governance products and will often be required for gateway approvals and may be

required to demonstrate compliance with corporate and regulatory standards. For example, the

Feasibility assessment, which needs to be considered before moving onto the Foundations phase.

Some of the products are evolutionary, such as the delivery plan, which is created in Outline and

Feasibility, and then more detail is added in Foundations. Others are milestone products. They are

created specifically at a point in the lifecycle. For example, the foundation summary, which provides

a snapshot of the business solution and management products at the end of the Foundations phase.

We'll be looking at each of the products over this module and the next.

Pre-project Phase
Pre-Project phase is concerned with clarifying what needs to be investigated during Feasibility. This

phase is particularly important in larger organizations, where such investigations need to be prioritized

as part of a portfolio or program. Users of Prince2 will identify a clear alignment to the starting up a

project process. The business problem or opportunity needs to be stated. The project needs to be

aligned with business strategy. The work required and resources needed to carry out the Foundations

phase needs to be planned. This phase should be kept as short as possible. The primary aim of the

terms of reference is to scope and justify the Feasibility investigation. It's likely to be a short document

of a maximum of two pages, although in many organizations, a simple email or even a verbal

agreement will be sufficient to allow a potential project to enter the Feasibility phase.

Feasibility Phase

All projects should be assessed for their ability to meet the business objectives and the deliver the

expected benefits. The potential benefits are identified. These should outweigh the costs of

delivering them. The Feasibility stage establishes whether the project is viable, both from the business

and technical perspective. The approach of delivering the product is considered. The approach covers

the way that the solution will be developed, for example, in house, outsourced, or possibly in

partnership with other organizations. There may be a requirement for some offshore development work,

for example, some of the development team may be based abroad. The project manager style

is considered, and whether Agile Project Management is the best approach for this project. The roles

and responsibilities and the overall governance of the project are also considered. The initial cost

and timescale for the projects are estimated. It's important to note that during Feasibility, these

estimates are based on limited knowledge and they'll be revisited at the end of the Foundations phase.

These estimates are usually presented as a range at this point, for example, between 50 to 100 days,

or between 100, 000 pounds and 200, 000 pounds. Feasibility is complete when there's enough

information to determine whether the selected option should be carried forward into Foundations. Agile

recommends using facilitated workshops to capture this information. Stopping a non-feasible project at

this point is a sign of organizational maturity. Many projects are stopped at the end of Feasibility, as

the investigation proves that they are too expensive, too risky, or perhaps it's not the right time to do this

work.

Feasibility Products

The business case provides a vision and business justification for the project. An example of a mission

for an online retailer might be we intend to provide our customers with the best online

shopping experience from beginning to end, with a smart, searchable website, easy to

follow instructions, clear and secure payment methods, and fast quality delivery. It describes the

business as it is expected to be at the end of the project or at the end of each increment of the project.

The business justification is usually based on an investment appraisal, determining whether the value of

the solution warrants the cost to produce it, support it, and maintain it, balanced against an acceptable

level of risk. The business case is produced in outline during Feasibility and is used to justify whether it

is worth moving into the Foundations phase. During Feasibility, the Prioritized Requirements List

records the very high level requirements to be addressed by project. Early indication of the

MoSCoW priority is stated in relation to meeting the objectives of the project driven by the business

needs. A requirement describes a service feature or function that the user needs. A typical high

level requirement might be the user needs to be able to make fully secure online payments in order for

them to feel comfortable ordering goods from us. The Solution Architecture Definition describes the

high level design framework for solution, both from a business and technical perspective, and should

begin to make the scope of the project clear. This may be a diagram at this early phase. The

Development Approach Definition describes how the development team will work and the standards

they will use, particularly around how quality will be assured, and will include the testing strategy. During

Feasibility, this might just reference some pre-existing standards, and how the AgilePM approach will

be tailored. Because very little is known yet about the final solution, this can only be in outline at this

point. There may be some deadlines that have to be taken into account, and early estimates of
timescales and costs are used to support the business case. The Management Approach Definition

during Feasibility will be looking at the approach to delivering the solution. For example, will it be

outsourced, developed in house, or in partnership with others? Is it a completely new solution, or an

enhancement to an existing solution? The project approach questionnaire will be used to identify any

risks associated with using the AgilePM approach. The Feasibility assessment presents the findings of

the Feasibility phase to the business sponsor for the business to make a decision on whether there is

sufficient justification to move on to the Foundations phase. It summarizes all of the other products and

can often take the form of a presentation.

Foundations Phase

The aim of the Foundations phase is to establish a firm base for the project. There are three

perspectives that need to be focused on, the business, the management, and the solution. The

business objectives are to baseline at a high level the overall requirements for the project and describe

their priority and relevance to the business need. This enables the business case to be detailed for

the project. The solution objectives are to state any business processes that are to be supported and to

identify any information that will be used, created, and updated by the proposed solution. Any strategies

for deployment and technical implementation standards need to be described. These contribute to

assuring the appropriate level of quality is understood. It may also be possible to start designing the

solution architecture and identifying physical or infrastructure elements. The management objectives

are to establish appropriate governance and organization for the project. The Solution Development

lifecycle and any techniques to be applied for managing projects and communicating progress are

described. A schedule for development and deployment activities is produced and baselined.

Any identified project risks are described, assessed, and mitigation planned. These three perspectives

are used to assess the continuing viability of a project. It's possible that during this phase as more

is understood about the project, it becomes evident that isn't sufficient viability, and the decision is taken

not to continue with the project. The business perspective is covered by the business visionary,
the solution perspective by the business visionary and technical coordinator, and the management

perspective by the project manager. The Foundations phase is complete when enough detail is defined

to enable a move into the expiration phase to begin product development. Enough can vary

from organization to organization. If a project is part of a large, complex program with complex

architectural constraints and third-party supplies, it will need stronger design up front and a

small internal project delivering a product into an existing framework. Typically foundations will be about

two weeks' duration for a three month project. The use of models rather than textual specification is

encouraged here. Static models can be used to help develop later prototypes and to make ongoing

maintenance and support possible. Models are much more meaningful than textual

specifications, because they're easier to understand, resulting in a better quality solution.

Foundations Products

By the end of the Foundations phase, the project manager needs to ensure that the business case

includes the vision, the estimated costs, and any other analysis that is needed to justify the project.

The business case should be strong enough to secure the investment and gain appropriate supports

from the business for the resources required to deliver the solution. By the end of Foundations,

the project manager needs to ensure that the Prioritized Requirements List records all of the high level

requirements to be addressed by project, at least for the first increments. They need to be broken down

enough for more than one to be able to fit into a timebox. Each requirement should have the

acceptance requirements defined for it and MoSCoW priorities assigned. They need to be

estimated sufficiently to enable the overall costs and timescales to be fixed at the end of Foundations.

The business visionary needs to ensure they represent appropriate breadth in order to achieve the

business benefits and then approve them. The project manager then needs to ensure the Solution

Architecture Definition is sufficiently understood by all of the project management team, but in particular,

the Solution Development Team. It should help to define the solution, but not so much that it constrains

the evolutionary nature of iterative development. The project manager needs to ensure that the Solution
Development Team understand and are fully committed to the way of working defined in the

Development Approach Definition. This is often already documented in the organization's

quality management system, or parts of an existing quality plan, in which case the project manager just

needs to make sure the teams understand it. The project manager, working in collaboration with the

solution development team, creates the schedule of timeboxes for the project, or at least for the first

increments. The MoSCoW priorities should demonstrate that a viable solution can be developed in

the fixed timescale. We'll look at this in more detail in a later module. This plan will be changed once

development work starts, but it will be tracked back against this baseline agreed at the end

of Foundations. By the end of Foundations, the project manager needs to ensure that the Management

Approach Definition defines the approach to delivering the solution. The project approach questionnaire

is revisited, and any outstanding risks to the approach will need to be managed. We will look at risk

management in more detail in a later module. The Foundations summary presents the outputs

of Foundations phase to the business sponsor and all seen as stakeholders, often in the form of a

presentation. They should be confident that there is sufficient justification to move into the development

phase.

Module Summary

This module has looked at the over all Agile Project Management Lifecycle. And a brief look at the

products that can be crated and updated throughout the lifecycle. It then looked at the pre-project,

feasibility and foundations phases and products in more detail. In a small project, it might be sensible

to combine the feasibility and the foundations phases and the products can as formal or as informal as

the organizational standards allow. Remember that the key thing is to do just enough to satisfy all stake

holders that there is a viable enough proposal that should now move forward into development.

Evolutionary Development, Deployment

Learning Objectives
The purpose of this module is to explain the Evolutionary Developments, Deployments, and Post-

Project phases. As you've seen in the previous module, the Feasibility and Foundations phases

are completed sequentially and set the ground rules for iterative and incremental developments. In this

module, you'll look at how the Evolutionary Developments can be configured and combined in

many different ways to suit the development of the solution. The Agile Project Management products

created, used, and modified in each of these phases are also investigated.

Evolutionary Development

The schedule of timeboxes was set out in the delivery plan at the end of Foundations. The Solution

Development Team now takes on the day-to-day managements to evolve the solution through the use

of timeboxing, MoSCoW prioritization, modeling, and facilitated workshops. Using timeboxing, the

Solution Development Team creates the solution increments using iterative developments. They

investigate the lower level detail with the business ambassador and business advisors. The Prioritized

Requirements List that was baselined at the end of the Foundations is broken down into smaller, more

detailed requirements. The main objective of evolutionary development is to build the right solution from

a business and technical perspective. This gives the stakeholders a chance to see the solution at an

early stage and be assured that what is being developed is what they want. The business

representatives define how the solution will work in practice, and testers start creating and running

tests. The developers often create models and prototypes to enhance communication with the business

and confirm understanding. Business analysts ensure that the prototypes support the required

business processes. Where possible, any prototypes produced should evolve rather than be thrown

away. The project manager passes the day-to-day management of the timeboxes to the Solution

Development Team, and ensures they have everything they need to produce the solution.

Evolutionary Development and the Agile PM

The main focus for the project manager during Evolutionary Development is to create the right project

environment to enable the Solution Development Team to get on and produce the solution.

This requires a more facilitative, hands-off style of management. The project manager will participate

and often facilitate the timebox kick-off, ensuring that the Solution Development Team fully

understand the requirements of the timebox. The project manager is responsible for committing the

required resources to the timebox. A key focus for the project manager is to manage the engagement of

the business ambassadors, business advisors, and any other part-time resources required during the

timebox. Their level of involvement and commitment is monitored, as this is key to ensuring to

Evolutionary Development is working well. After the kick-off, the Solution Development Team organizes

themselves and take responsibility for the detailed planning, execution, and testing of the requirements.

Manage by exception allows the team to escalate any issues to the projects manager that are beyond

the remit of the Solution Development Team. The project manager does everything they can to protect

the team from distractions and unplanned work outside of the scope of the priorities set for the timebox.

The project manager will often attend the daily stand-ups as an observer and will contribute if invited to

by the Solution Development Team. The project manager may participate in timebox reviews,

typically at the end of refinement and consolidation. At the timebox closeout, the project manger will

attend to measure progress to ensure any learning is taken into account in future timeboxes,

and update the delivery plan with any incomplete work. Some could-have requirements may get

dropped for the increment, or may become must-have requirements for the next timebox. The delivery

plan will need to be updated accordingly. During Evolutionary Development, the project manager

works primarily with visionary and technical coordinator to plan for the Deployments phase.

Evolutionary Development Products

This lesson looks at the products produced during the Evolutionary Development phase. The evolving

solution is entirely dependent on the objectives of the project and the current position in The

project's timeline. It's a convenient term to describe work in progress or a complete product or a

baseline or partial solution. It can include models, prototypes, supporting materials, and testing

and assurance records. It's produced by the Solution Development Team. The timebox plan is an

evolutionary product that takes the high level requirements for the timebox from the delivery plan,

and provides more detail and depth. It's created by the Solution Development Team and often takes the

form of a team board that shows work to be done, work in progress, and work completed. It's

updated at the daily stand-up. The timebox review record is an evolutionary product that captures the

feedback from each review in a timebox and describes progress up to that review. This is a governance

product, and it can be as formal or informal as required. If a structured timebox is being used, then there

will be a review for investigation, a review for refinement, and a review for consolidation. It's produced

by the team leader.

Configuring the Process - 3 Lifecycle Examples

Each phase of the DSDM process has a purpose, but the amount of effort and formality of that process

will differ from project to project and organization to organization. The Pre-Project phase may just be a

conversation, but in a more formal setting, the terms of reference may need to go through some sort of

portfolio level decision process. For a large, complex project, Pre-Project, Feasibility, and Foundations

will be required, but for a small, informal project, it could go straight from pre-project to Foundations. A

major decision that needs to be made in Foundations is whether the solution can be delivered and

deployed incrementally, which allows for the earliest possible delivery of value to the business.

Three examples follow, showing how project's lifecycles can be configured from the DSDM process, but

these are not the only ones. A single simple increment deployed after a series of timboxes where the

whole project is planned as one release. A multi-increment project with each increment made up of a

series of timeboxes and planned as multiple releases. A very agile multi-increment project

deploying after every timebox with many releases. This looks much like typical agile ongoing product's

developments, except here in a project environment, there will be an end to the project.
Deployment and the Agile PM

The main purpose of deployment is to get the basic functionality of the solution into live use to the most

important user groups as soon as possible in order to ensure the earliest delivery of benefits. Where the

product is to be sold or distributed outside of the organization, then the primary objective is to get

the product ready to ship. How many passes there are through deployments depends on how feasible it

is for the solution to be accepted incrementally. The project manager coordinates the day-to-

day activities to bring the solution increment into live use as and has often been planned back in

evolutionary development. This will often require inputs from the business visionary, technical

coordinator, and a fair amount of collaboration with the Solution Development Team and

other stakeholders. An incremental retrospective is held to discover what was successful about the

project or time period covered by that retrospective, what could be improved, and how to incorporate

the successes and improvements in future iterations or projects. The findings of the retrospective are

captured in the Project Review Report by the project manager. There also needs to be a more formal

decision as to whether to proceed to the next increments to revisit foundations to assess the viability of

the next increments or to close the project. At the end of the final deployment, a final retrospective is

held and captured in the project review reports. The project is formally closed and the

project performance is evaluated from the business, technical, and process perspective. The use of

Agile Project Management is reviewed and the process is fine-tuned for future projects.

Post-project Phase

The Post-Project phase takes place after the last planned deployment. It allows an organization to

reflect on the performance of the project, and what business value has actually been achieved.

This assessment can start as soon as the value can be measured, typically three to six months after the

project has ended. In many cases, the project will have closed prior to this phase. When the product

is being deployed in multiple increments, then it's possible to start the benefits assessment before the

final deployment, and then feed any proposals for change or enhancement back into the ongoing
project. The benefits assessment describes how the benefits have actually accrued and the deployed

solution is operational. The main objective is to assess whether benefits have been achieved. Where

the business case has stated the benefits are expected to accrue over a prolonged period, then there

may be several reviews. This also gives the organization the opportunity to address any discrepancies

between what was expected and what has actually been achieved.

Module Summary

We've come to the end of this module. This module has introduced the Development, Deployment, and

Post-Project phases and the products created, used, and updated, and as part of the lifecycle process.

Techniques and Practices

Learning Objectives

This module will look at each of the five techniques used in Agile Project Management, and especially

the daily stand-up to show how they all contribute to ensuring communication is effective. Each

technique plays a part, but when combined in a project, ensure that the communicate continuously and

clearly principle is applied to great value.

Communication

In the Standish Chaos Report produced in 1995, poor communication was cited as a number 1 reason

for project failure. And in a web poll released by the computing technology industry association in

March 2007, nearly 28% of the more than 1000 respondents singled out poor communication as the

number 1 cause of project failure. Agile specifically addresses many of the known project

communication problems by its style of working. It has solution development teams comprising of

both business and technical roles. It has short and frequent feedback cycles and the evolving solution is

highly visible throughout the project. Detail is added at the appropriate time in development, rather than
having a detailed specification at the beginning, when it's highly likely to change as the product

is developed. There are three key Agile Project Management techniques, detailed in the next three

lessons that are aimed at ensuring communication is focused and effective. These are

facilitated workshops, modeling, and iterative development.

Communication - Facilitated Workshops

Facilitated workshops are a specialist type of meeting with a clear objective. They have a workshop

owner who needs the outcome and is the driver for it to happen, and they have participants empowered

to make decisions. These workshops benefit from having an independent facilitator, who enables

and encourages the participants to achieve an agreed goal. Workshops are a key Agile technique for

encouraging collaboration and effective communication. They can be used throughout the lifecycle and

for a variety of reasons. For example, for requirements capturing and prioritizing requirements, project

kick-off, planning determining the terms of reference for each role, risk, and timebox reviews. They do

not replace meetings, but offer a good and often better alternative, especially where the subject matter

needs consensus and buy-in. The Agile project manager may need to support the team by getting

the right people to participate and to ensure the budget allows for appropriate venues for workshops.

There are many benefits to a project for using facilitated workshops, and these include rapid, high

quality decision making, greater buy-in from all stakeholders, building team spirit, building consensus,

and clarification of issues. For the workshop to be effective, there are several success factors.

These include having a trained and independent workshop facilitator, not forcing decisions and

agreements, and ensuring participants receive a workshop report, detailing decisions and actions

ideally within 48 hours of the workshop.

Communication - Modeling

It is useful for the project manager to be aware that modeling is actively encouraged in an Agile way of

working. A picture tells a thousand words. Models are a better way of communicating than
large documents. The Solution Development Team should be modeling techniques to ensure effective

communication between the business and technical staff. A single model does not always cover all

aspects of the project, as it would become too complicated. It typically focuses on who, what, when,

where, why, or how. Of course, the use and nature of the models varies from project to project, from a

full-scale model of a new school to a quick hand-drawn sketch. Modeling supports the principle of

deliver on time, because models are produced as early on in the project as possible, as it helps

alleviate misunderstanding, and therefore takes less time to develop. Modeling supports the principle of

communicate continuously and clearly, because modeling improves communication, and can often

challenge or clarify ideas through visualization. Modeling supports collaboration, because the

production of a model or prototype requires a collaborative approach, and the decisions that support the

model often need contribution from all stakeholders.

Communication - Daily Standups

Agile Project Management emphasizes the importance of ongoing informal, and where possible, face-

to-face communication, and relies on team members being open and honest. On a daily basis, the

Solution Development Team working in a timebox get together for a stand-up meeting. This is normally

run by the team leader, and is an opportunity to understand progress at a detailed level, and share

issues that might be getting in the way. It should not attempt to solve problems, unless the resolution

won't take more than a minute or two, but it can help to clarify the issue, and identify who should

participate in solving it. It can also be attended by other roles, often by the project manager, who is

there to observe progress and pick up escalated issues. The project manager should resist the

temptation to get too involved, as they are there to observe. The technical coordinator may be there

to keep up-to-date with technical decisions and pick up any escalated technical issues. Specialists may

be included where they are temporarily part of the Solution Development Team. The stand-up should

take no more than 15 minutes, and be held in the normal workplace, to emphasize the informality of the

session.
Key DSDM Practice: Iterative Development

The definition of iterative development is that it is a process in which the evolving solution or part of it

evolves from a high-level concept to something with acknowledged business value. It is the

key technique used by Agile Project Management to evolve solutions from a high-level idea to a

delivered solution. It's a process whereby repeated cycles of product development produce the results

that get closer to a desired outcome after each iteration. The cycle typically requires the team to

sequentially identify what they need to achieve in this iteration by having a conversation, think about

what is required, and plan how they are going to do it, action the plan by creating the required product

or products, followed by further conversation to review the outcome to determine whether further work

is needed. Often via prototypes or possibly early walkthroughs of the evolving solution, iterations are a

better way of communicating than via large documents. However, to prevent an endless cycle

of iteration, it needs to be controlled. When a review determines that the product is not right, then it is

important to be able to revert back to a previously agreed version. Appropriate application

of configuration management needs to be considered. The technical coordinator will define the

configuration management standards and the level of formality to be applied, but it is also the

responsibility of the whole team to ensure that the standards are complied with;

configuration management should help development, not hinder it, and care needs to be taken that it

does not constrain iterative developments. Iterative developments encourages the Solution

Development Team to work in a highly collaborative manner. Quality is never compromised by

ensuring early testing with the aim of failing fast so that changes and fixes can be applied early on in the

development. The teams communicate continuously and clearly throughout, and iterative

development allows for control over the development of the solution. The required level of quality

should be defined by the end of Foundations, and during Evolutionary Developments, there is

continuous review and testing. Reviews can be as formal or informal as the standards dictate.

Testing should be applied according to the level of quality required. There are three broad classes of

tests that can be applied. Positive tests check that a deliverable does what it should do; for example,
when you put a right key on a lock it opens the door. Negative tests check that the deliverable does not

do what it shouldn't do; for example, when you put the wrong key in a lock, it does not open the

door. Unhappy path tests check the behavior of the deliverable when an unusual or unexpected event

happens. For example, when you hit the lock with a hammer, it does not open or jam the lock.

MoSCoW Prioritization

MoSCoW is a key technique for helping to understand priorities. Prioritization can be applied to

requirements, tasks, products, user stories, acceptance criteria, and tests. Here we are looking at

prioritization in relation to requirements. The letters stand for M, Must Have, representing requirements

that are guaranteed to be delivered. S, Should Have, representing requirements that are expected to be

delivered. C, Could Have, representing requirements that are desirable, but less important than

Should Haves. W, Won't Have, this time representing requirements that won't be delivered. The Must

Haves represent the minimum usable subset, and when setting priorities, it is helpful to see these

as the requirements that cannot be emitted without causing the project to fail. The Should Haves

represent the requirements that would be costly if emitted, or ones for which workarounds would be

difficult. These requirements should be left out as a last resort to keep the project on track. The Could

Haves represent the requirements for which workarounds are easy and fairly cheap, and could be left

out without causing significant problems. The won't haves are requirements that we won't have this

time, and are out of scope for the project as a whole, or for the current timeframe. It's important to

also understand the levels of priority of the requirements. MoSCoW prioritization is only meaningful

within a given timeframe. A Must Have requirement for the overall project may not be a Must Have for

the first increment or release. A Must Have requirement for an increment could be a Should or Could for

the first or second timebox of that increment. The MoSCoW technique is designed to allow for delivery

for the minimum usable subset to be guaranteed. As a rule of thumb, the Must Haves should not

represent more than 60% of the effort. The Should Have and Could Have represent 20% each.

This equates to 40% contingency, which will allow for even the most optimistic estimates. This means
that firstly the Coulds and then the Shoulds could be dropped to enable a timebox to complete on time.

There needs to be continuous review of priorities throughout the project, as a result of any change in

understanding of depth and detail Although the minimum usable subset is guaranteed, it's expected that

most projects will deliver the Shoulds, and indeed, some of the Coulds. Current best practice suggests

that delivering the Musts and the Shoulds ought to satisfy the business case, although some

organizations build their business case on just the Musts. Delivering the Coulds is always seen as a

bonus, and only delivering the Musts is considered the worst case scenario.

Prioritization - Who Decides?

Inexperienced teams may find that the business initially tries to set a high level of Must Haves in the

expectation that they will get more delivered. There's a need to reassure the business that the team

guarantees to deliver the Must Haves, but they should also expect delivery of most, if not all, of the

Should Haves. If things go well, the Could Haves may also be delivered. Adjustments will be made

by losing the features of least importance of value to the business in order to protect the deadline. If all

the requirements are Must Haves, this undermines the Agile ethos of fixing time and

resources adjusting features in order to deliver on time. The project manager and business analyst can

challenge a Must Have requirement. This can result in a high-level requirement being broken down into

lower-level requirements, each with a different priority, giving flexibility at a lower level. This means that

a must have can have some subcomponents, which are Should Haves, Could Haves, and

Won't Haves. It's usually these lower level sub requirements that are negotiated. Good prioritization is

about predictability, not about delivering just the Must Have and then relaxing. The business

sponsor expects delivery of all of the Must Have requirements, and most if not all, of the Should Haves.

This allows for a minimum of 20% contingency, which is double the 10% that is normally allocated to a

project, taking a more traditional approach.

Timeboxing
Timeboxing is one of the key techniques in Agile Project Management. A timebox is a well-defined

process to control the iterative creation of low-level products. Review points ensure the products

are produced to the right level of quality. The recommended time span for a timebox is 2-6 weeks. This

is not mandatory, but the advice is to keep them as short as possible. Two to three weeks is

more typical. There is always a kick-off at the beginning of each timebox. This is a short session

typically one to three hours, for the Solution Development Team to understand and accept the

timebox objectives as realistic. A timebox contains three main stages, investigation, refinement, and

consolidation. During the investigation stage, the detail of the products and how they will be measured

is agreed. This should take up to 10-20% of the timebox. The refinement stage is where the main

development and testing is done according to the agreed priorities. This should take up 60-80% of the

timebox. Consolidation is for tying up the loose ends and ensuring all the products meet their

acceptance criteria. This should take up no more than 10-20% of the timebox. The timebox is

concluded with a close-out, where the business visionary and the technical coordinator give

formal acceptance of the deliverables. Each timebox plan is created during kick-off. This will be

investigated further during module nine. A key method of communication and control is the daily stand-

up, which was explained in a previous lesson in this module. A free format timebox can be used where

other Agile approaches to development are used, such as scrum sprints. It can also be used where a

very informal approach to development is taken. It has a kick-off, iterative development, and a close-

out.

Timeboxing - Provides Control

The main purpose of the delivery plan created in Foundations is to set out a schedule of increments,

and then within each increment, a schedule of timeboxes. The schedule should show the

proposed number and duration of each timebox in the current increment. It should also indicate the

high-level focus for each timebox. If the project is being controlled at the lower level and each timebox is

on track, then it follows that the project is on track. If the team are in control at the development timebox
level, then the increment and the project look healthy. If the current development timebox is failing, then

the increment and project are seriously at risk and action needs to be taken. The advantage of this is

that it gives very early warning of problems, ensuring that they are not ignored. As we have seen in this

module, the MoSCoW technique is used to prioritize the work. Test-driven development ensures

that acceptance criteria are confirmed before any development work is undertaken, and used as a

measure to assess the deliverables. The team work in a highly collaborative manner and are

empowered to get the job done.

People, Teams, and Interactions

Effective communication relies on good communication skills and underpins teamworking and

transparency. Face-to-face is the most effective form of communication, and it is as much

about listening to the verbal messages and watching the body language as it is about speaking. It's

important to choose the right means of communication to suit the right circumstance. Conferencing,

video, or teleconference is useful when people cannot physically get together. Chat facilities are useful

for a quick interchange of information. Email is good for confirming what has been agreed. Collaborative

workspaces are useful for informal communication within the team. Documents are still important for

managing more formal information, but if you don't know who is going to read this, then don't write it.

Simple pictures are often more effective than verbal or written descriptions. The daily stand-up should

be run around a team board with video links to remote team members, but avoid large groups dialing in

or Skyping from their desks. There are many ingredients for effective collaboration. Having mutual trust

and mutual respect between team members, being open-minded and approachable as an individual,

being available when needed, being open to change, having clear direction and having consistent and

stable team membership. Most importantly, it's about having belief in yourself and in others.

Effective collaboration works best where individuals possess T-shaped skills. The vertical bar on the T

represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the

ability to collaborate across disciplines with experts in other areas, and to apply knowledge in areas of
expertise other than their own. It's the responsibility of the project manager to foster an environment that

allows DSDM teams to work collaboratively. All Agile approaches put high emphasis on team

collaboration. DSDM teams bring people together to achieve a shared goal from the business and

solution communities. Early DSDM phases and DSDM products help establish common goals

and foster a culture to support collaboration. Agile Project Management ensures that this culture gives

confidence and trust, so that people can be open and honest. Workshops and iterative developments

help build a collaborative culture. The leadership style must be facilitative and collaborative, a servant

leader, which focuses primarily on the growth and well-being of people. All of this contributes to a

healthy, collaborative, open, and honest environment that makes the whole project more effective.

Module Summary

This module has looked at how the use of the five techniques of facilitated workshops, modeling,

iterative development, MoSCoW, and timeboxing contribute to effective communication in the Agile

Project Management approach. It also looked at the daily stand-up and how this encourages a

collaborative approach to the development work. This module then concentrated on the use of

timeboxing for the development work and how iterative development is applied to each timebox. There

are frequent reviews throughout our timebox, which keeps the stakeholders up-to-date with the

progress of the deliverables.

Agile Control

Learning Objectives

This module will look at the many controls that are available to Agile Project Management, and how

each of the five techniques contribute to exercising an appropriate level of control over the project. It will

look at risk, and how the use of Agile Project Management itself introduces risk to the project, and

how this is dealt with. The module will look at what requirements are in more detail, and the difference

between a functional and non-functional requirement. It will also look at how estimating and

how estimates become more accurate throughout the lifecycle of an Agile project. This module will also

cover how to capture progress and help with estimating further iterations and increments of the project.

Agile Control - 1

At the end of the previous module, we looked at how timeboxes allow for control at the lowest level of

the project. If all has gone well at the timebox level, then the overall plan, whether than is an increment

or the overall project, is looking healthy. An advantage of an Agile approach is that a project manager

gets early warning of problems, possibly after the first two weeks of development. It highlights that

remedial action needs to be taken, and it avoids early optimism that problems are only temporary

and things will get better. If a project is behind early on, it will generally be at least that amount behind at

the end, usually even more behind. And yet teams and project managers continue to believe things will

improve. Sometimes early warnings may even highlight that a project is failing at the start. This

allows opportunities for stopping failing projects before more time and money is lost. This should always

be seen as a positive and as a sign of a mature organization. The project manager and the team leader

need to constantly review and respond to any issues that may affect the project, particularly they need

to ask themselves are there any communication, technology, people, or environmental barriers that are

impeding the team progress? What is working particularly well, and how can that be maximized?

What isn't working so well, and what needs to change? A project manager is more of a facilitator to

removing barriers and to ensuring that the enthusiasm, empowerment, and performance of the team

are not affected.

Agile Control - 2

When a problem occurs, it's vital that the deadline remains unchanged, since the whole approach is

about on time delivery. Once a deadline is slipped, it will become impossible to fix it in the future.

From the start, the teams and project managers must protect the deadline, and look for other ways of

solving the problem. The first choice will always be to drop the least important feature from the
timebox, or from the project, or both. Sometimes it is necessary to revisit the Prioritized Requirements

List in the light of the current situation. It's important for stakeholders to understand that though Agile

embraces change, it is change to the depth of the requirements, not change in the breadth. Adding new

Must Have high-level requirements is seen as a change of breadth and scope of the project. This is not

what the early estimates were based on, and for this reason, any new Must Haves require

formal change control. And how is this controlled? An Agile team working in a software development

environment highlights its completed work, the team's track record for delivering every two weeks, and

the projected delivery date for the next production deployment. They say we have committed to this

plan, and we are delivering to it with fully production-ready code every two weeks. If you add additional

work, we will not be able to deliver on time. Here is our evidence. Notice that they are not having a

conversation about who said what six months ago, they are all focused on the delivery date, and the

probable contents of the software to be delivered on that date. They're all committed to keeping quality

constant, rather than agreeing to allow more work to creep into the schedule. An Agile team will be able

to provide really good evidence to show why a request will or will not work with a projected budget and

timeline.

Managing Risk

Managing risks is no different in Agile than it is in any other project management approach. A risk log is

required and should be reviewed on a regular basis. Risks need to be identified, assessed for severity,

impact, and priority, then countermeasures proposed, planned, and regularly reviewed. This is standard

risk management practice. Agile Project Management addresses some traditional waterfall risks head

on. The approach is designed to deliver the right solution on time. The use of the MoSCoW technique

to prioritize requirements, and the ability to embrace change, ensures that the right solution is produced.

Testing is done as early as possible and continually through iterative development. But Agile

Project Management introduces some different risks from more traditional project management, those

associated with the principles and the instrumental success factors. These need to be monitored
closely, and the whole team has a responsibility to ensure the principles are being upheld. If

the business ambassador regularly misses sessions, then the rest of the Solution Development Team

are unlikely to deliver the right solution. If there is very detailed design up front and 100% of the solution

is expected, then the benefits of using the MoSCoW technique are limited and time and cost can't be

fixed. The use of small, highly collaborative teams means that a lot of communication may be

verbal, and any changes to the team can result in the new member not understanding the background

to decisions made. The whole team should be aware of the risks, but it is the project manager who

drives risk management. The project approach questionnaire helps identify potential risk areas. Once

completed in Foundations, it should be reviewed for each development timebox to see if the risk profile

for the project has changed.

Agile Requirements

A requirement is a service, feature, or function that the user wants the solution to have or do.

Requirements are often described in the form of a user story. User stories are short, simple descriptions

of a feature told from the perspective of the person who wants the new capability, usually a user or

customer of the product. They typically follow a simple template. As a role, I need the requirement or

feature, so that benefit to be gained. As you've seen in the previous lesson, high-level requirements get

broken down into more detail as the development progresses. One of the benefits of user stories is that

they can be written at varying levels of detail. A high-level requirement example from a desktop

backup product might be, as a user, I want to be able to backup my entire hard drive to secure my data.

Because this is generally too large for an Agile team to complete in one iteration, it's split into

multiple smaller user stories before it's worked on. This could be split into dozens or possibly hundreds,

including these two. As a power user, I want to specify files or folders to be backed up based on

file size, date created, and date modified. And as a user, I want to indicate folders not to be backed up,

so that my backup drive isn't filled up with things I don't need saved. The requirements evolve and

become more detailed at each lifecycle stage. There will typically be less than 10 requirements by end
of Feasibility, anything up to 100 by the end of Foundations, and greater than 100 by end of

development. Large numbers of requirements established too early are seen as a risk for Agile

Project Management, as this suggests too much detail too early. This is known as big design up front,

typified by a more traditional project management approach. The Prioritized Requirements List

is agreed by the business sponsor and relevant stakeholders. Ideally an initial small number of high-

level requirements from Feasibility get expanded to the next level of detail during Foundations. The low-

level detail is only expanded and clarified immediately before the work is to be done. Not formalizing the

low-level detail too early allows for flexibility within the overall scope without the need for formal change

control. Requirements need to cover both what the product needs to do, the functional requirements,

and how well it needs to do it, the non-functional requirements. The functional requirements describe

what is required, not how to deliver it. For example, a functional requirement would be that a system

must send a confirmation whenever an order is placed, but it should not say how. This could be an

email, a message onscreen, or an onscreen confirmation that can be printed. The how is up to the

Solution Development Team to explore. If solutions are stated too early, it can constrain innovation.

A related, non-functional requirement might be that the confirmation should be given within 12 hours

from the time of the order.

User Stories

A user story is one of the most common ways of expressing a requirement. It's always written from the

perspective of the end user. High-level requirements are sometimes called epics, which are large user

stories that can be broken down into a number of smaller stories. An epic is usually too big to fit into a

timebox. Epics are usually produced at Feasibility. By the end of Foundations, they need to be broken

down enough so that more than one user story can fit into a timebox. All user stories have the same

format. They should be written from the perspective of the role that we'll use or be impacted by solution

and defined in language meaningful to that role. This helps to clarify the true reason for the requirement.

The idea is not to go into low-level detail too early and they should be deliberately brief to
encourage conversation. User stories comprise of three C's, the card, which is the means of recording

the requirement, the conversation, which is generated from the user story, the confirmation, which is

the acceptance criteria recorded on the back of the card written as questions that expect a yes answer

and include the non-functional requirements. The invest model first documented in an article by Bill

Wake in 2003 provides guidance for creating well-constructed user stories. The I stands for

independent, because each story should stand on its own and be as independent as possible from

other stories. The N stands for negotiable, which is where the conversation is important. The stories are

placeholders, which the team will investigate in more detail during Evolutionary Development. The V

stands for valuable. Stories should represent features that have obvious business value to the user. The

E stands for estimable. Each story should be clear enough to be able to estimate the time scales for

development from. One Agile approach to estimation is by playing planning poker. Appendix C of the

AgilePM handbook explains how planning poker can help with estimating. S stands for small, because

stories should be small enough to be able to estimate from. If they are not, then they should be broken

down into smaller stories. T stands for testable, which means they need to be worded clearly and

specifically enough to be testable. A well-written user story does not combine, overlap, or conflict with

other stories, conforms to organizational standards and policies where applicable, is traceable back to

business needs expressed in business case and project objectives, and where several stories relate to

the same feature, but for different users, they cross-reference each other.

Agile Requirements - 2

The business analyst is responsible for requirements related documentation, which is especially

important considering the evolutionary nature of requirements in Agile Project Management. The

business analyst makes sure that it is only requirements which affect the depth of the project that get

added after Foundations. Change in breadth should be handled in a formal or an informal way,

depending on the nature of the project. Keeping on top of this is critical to prevent scope creep. The

business analyst is responsible for ensuring that the requirements are properly analyzed, and that the
Solution Development Team understand how they drive the development work. The business

analyst ensures that the right people in the business are brought in to communicate effectively with the

technical roles on the project. They are not meant to be the voice of the business, but more to

ensure the right people are being talked to. The business analyst helps the business to think through

and understand the full implications of the requirements. There should be a close-working

relationship between the business analyst, business ambassador, and solution tester. The business

analyst should have the skills to be able to identify any dependencies, overlaps, and conflicts

between requirements and the affect they have on the corporate objectives and direction of the overall

business.

Estimating

Estimates are used for different purposes to evaluate the business case, to assess feasibility, to

understand the project costs, or to produce high-level schedules. They are a means of communication

with stakeholders. Agile Project Management estimating is about asking how long have we got, what

resources do we have, and then working out how to achieve the objective within the time and

cost constraints. More traditional projects will usually try to work out how long the entire project will take

before any work commences. Agile Project Management makes estimating easier, because it only

makes firm estimates for the next increment, not for the whole project. The MoSCoW technique

includes contingency to cover the risk of the unknown. Where early estimates might have been over

optimistic, because not enough was known at that time, there is contingency to cope with a change in

estimates. The estimates are constantly reviewed and the accuracy of estimates should improve as the

project progresses, and understanding of the requirements deepens.

Estimating - 2

Estimates are only as precise as they need to be at that particular point in the lifecycle. At the end of

Feasibility, the estimates are just enough to justify the early business case and the planning required for
Foundations. At the end of Foundations, the estimates are based on more research, but not too much,

just enough to prove the business case is still justified, and for the delivery plan to be produced. This

delivery plan includes a schedule of timeboxes for the delivery of the project. During development,

each timebox informs more accurate estimating for the next timebox. Agile Project Management makes

estimating easier. You only need to make firm estimates for the next increment, not for the whole

project. Frequent delivery of timeboxes mean that actual results can be recorded sooner, and so

estimates can be revised and improved by inspecting and adapting. Typically at the end of a two-week

timebox, there is feedback on how good or bad the estimates were, allowing for this knowledge to

be fed into estimating the next timebox. It is easier to estimate what can be done within a fixed timebox

of, say, two weeks, than it is to estimate how long it will take to do something in its entirety. Feasibility

and Foundation estimates are top down broad-brush estimates. At these early stages there are a lot of

unknowns, and for that reason, the estimates cannot be accurate. More is known by the end

of Foundations, the middle level of requirements, so you can now commit to the deadline through the

delivery plan. During development, more precise bottom up estimating is done, based on a

more detailed work breakdown. The cone of uncertainty describes how the level of uncertainty

decreases as more research and development is done and more information is learned about the

project. The uncertainty tends to decrease, until the end of the project, when all risk has been

terminated or transferred.

Module Summary

This module looked at how control is applied to Agile Project Management and the contribution made to

control by each of the five techniques. It looked at how the use of Agile Project Management

itself introduces risk to the project, and how this is dealt with. The module looked at requirements and

how the business analyst role is key to ensuring requirements are captured and interpreted by the

technical roles. It looked at how estimates become more accurate throughout the lifecycle of an Agile

project.
Agile Planning

Learning Objectives

This module will concentrate on the style of planning and the maintainability objectives that need to be

considered when planning. It will also consider how the two quality drivers of process quality

and solution quality need to be addressed. And each of the planning products created through the

lifecycle will be looked at in more detail.

Planning Agile Projects

Experience has shown time and time again that detailed planning up front is a waste of time. Do you

know exactly what you will be doing this time next week? You will probably know roughly, but not

precisely. As you look even further ahead, the precision decreases accordingly, so planning in detail up

front becomes pointless. Many traditional projects plan in detail at the start of a project. Such detailed

plans may often be wrong, and they may give a false sense of confidence in the project. The

requirements will change as the business changes. As the users of the solution start to see what it can

do, they start to see other options. This is all part of evolving a solution. There are some misconceptions

that in using an Agile approach, planning is optional or very little planning needs to be done. Agile

projects still require planning to demonstrate there is control over the project. A high-level plan

is created for the overall project that sets out the overall scope, and then a detailed plan is created at

the start of each timebox. Each timebox is then evaluated, and the next timebox planned in

detail, based on the position at the end of the previous timebox. This is known as inspect and adapt.

Planning workshops used a facilitated workshop are a useful way of bringing the Solution Development

Team, including the business and technical roles, together to plan in a more collaborative manner. To

keep plans real, keep the detail out of plans until you get closer to the time you will be carrying out the

activities you're going to plan. Two to six weeks ahead is sensible.

Planning Considerations - Quality

Agile Project Management promises to deliver to a required level of quality. The acceptance criteria set

before any development starts mean that quality is a fixed project variable. Quality can encompass

customer satisfaction, technical, and support concerns, and often adherence to the organization's

best practice. There are two key areas to focus on, solution quality, and process quality. Solution quality

is about the fitness for purpose of the delivered solution. Can the business use it effectively? Is it

robust enough? Has it achieved the standard set for it? These are the development aspects that are

tested, and solution can be planned to meet these tests using test-driven development. Process

quality is about ensuring that there is a predictable, repeatable process in place. This is what quality

audits are looking at, and is the measure for international standards such as ISO 9001 or internal quality

management standards. When checking for process quality, the question does the project follow

accepted best practice is asked. Agile Project Management addresses both areas of quality. Its

practices and techniques lead to a solution that addresses the customer's requirements, satisfying

the solution quality. Following the Agile Project Management practices and techniques provides a

predictable approach that complies with process quality. A different approach to auditing may

be required, because on a traditional project delivery of anything but 100% of the solution will be seen

as a quality failure. In an Agile project, the quality of the solution is based on whether it meets the

minimum usable subset, and whether all the requirements meet the agreed standard.

How Agile Builds Quality

The ISO 9000 view of quality, which is achieving customer satisfaction and meeting product

requirements, fits perfectly with the Agile approach to project management. The Agile processes and

techniques help to ensure that what is produced meets the user's need. Agile has been recognized as

an appropriate project management approach for ISO 9001 accreditation. Facilitated

workshops, modeling, collaborative planning, and regular reviews can help to engage users and

stakeholders. The Foundation phase, the use of MoSCoW prioritization, and having business roles as
part of the Solution Development Team can help to ensure proper consideration of requirements from

the outset. Facilitated workshops, stand-ups, ongoing and focused user involvement, modeling, and

timeboxing helps to ensure the right people are involved at the right time. Timeboxing must go

prioritization, regular review sessions, and the involvement of the business roles as part of the

Solution Development Team all contribute to evolving the solution according to the business need.

Ongoing and independent testing, regular review sessions, and defined product quality and

acceptance criteria all contribute to validating the solution against the requirements. Compared to

standard audit style quality management processes in more traditional projects, Agile presents a simple,

but pragmatic approach.

Planning Considerations

Maintenance typically happens when the products have been deployed, but it has to be considered

from the beginning of the project. Maintenance should be considered early in the lifecycle. What

maintenance might be required, who will do it, and how easily maintainable does the solution have to

be? Making the solution more maintainable than it needs to be is a waste of development effort, making

it less maintainable than it needs to be will lead to more effort later. Fitness for business purpose is

essential criteria for acceptance of deliverables. There are three levels to maintainability in Agile. The

first level concerns projects where maintainability is required from the first delivered solution. In this

case, deployment needs to ensure the components of each increment can be fully supported before it's

released to the business. The second level is if the business wants the functionality as soon as

possible, and is prepared to add in maintainability after initial deployment. This means that the products

can be deployed fast and then re-engineered for maintainability later. This is often the case for

products released into a fast-moving market, or a new product into a fast-moving business. It is

important that the funding is available for this later re-engineering; otherwise, the business can end

up struggling with a product that is never quite right. The third level is for a short term tactical solution,

where maintainability is not part of the acceptance criteria. This is usually for a stop gap with a limited
shelf life. The maintainability objectives should be considered during Feasibility and refined during

Foundations. The handover of solutions from development to different maintenance and support groups

is often a problem for traditional projects. Failure to handover means that the development team may be

sidetracked to providing support. Provision of appropriate documentation, training, and

effective communication makes for more efficient handover. In Agile, deployment handles everything

needed to move the solution, partial or whole, into the operational environment.

Planning Activity

This lesson will give a brief overview of planning through the phases and the lessons that follow will

take a more detailed look. Any planning required at Pre-Project is carried out at program or portfolio

level. The main focus is to decide whether to move into Feasibility and to indicate the resources

and timescales for Feasibility. Strategic planning starts in Feasibility. An initial outline of project

management and solution development approaches is proposed supported by the possible timeline

for delivery. This information is gradually refined during Foundations, generating high-level plans and

agreed ways of working. This forms the basis of the commitment to deliver what business needs when

business needs it. The delivery plan is the key plan produced in Foundations and shows the schedule

of development timeboxes with an idea of their probable content. The timebox plan created by

the team, not the project manager within Evolutionary Development, details what the solution

development team will be delivering in the next timebox, typically over the next two to six weeks. It

builds on the delivery plan created earlier. This is not a detailed task plan, but records planned outputs,

acceptance criteria, the MoSCoW priorities, and dates for key reviews. As the timebox plan is at

the lowest level of planning, estimates at this time are less uncertain and more accurate. Results from

timebox reviews will lead to an update of the delivery plan with what is actually happening. During

Evolutionary Development, a deployment plan is issued, showing when the increments of the evolving

solution will be deployed. This includes everything needed to move the solution or partial solution into

the operational environment. It may include business deployment plans for business process change in
training. The deployment stakeholders need to be involved with this plan, as deployment is often

handled by separate teams and can be a complex activity. Plans always need to evolve to meet

changes in real world circumstances. The business needs shift and a better understanding of what

is possible and what is necessary changes. The project manager is not responsible for all planning

activity, but they are responsible for ensuring all plans align with high-level plans to deliver what

the business needs at the time agreed within the agreed costs.

Planning - Early Phases

Planning at the Pre-Project phase depends on where the requirements for the project comes from. It

may have been identified as part of portfolio management or program managements, but it could just be

a verbal requirement. The resources and timescale for Feasibility need to be identified, and there may

be an early indication of timescale constraints for the project. The terms of reference will capture

this information. During Feasibility, the delivery plan captures the results of a high-level investigation

and a high-level of uncertainty expected. The business may have a schedule in mind that fits in

with business strategy and their business plans. There may be definite delivery dates for each

increment, and they may have an overview of what each increment should deliver. There may be

some budgeting dates that have been set, either by the business or by some external funding. There

are likely to be around 10 high-level requirements captured by the end of Feasibility. It is possible to

plan the next phase, Foundations, in more detail. The delivery plan will include the deliverables,

resources and facilities required for Foundations, and the timing of any facilitated workshops to be

held. The answers to the questions asked in the project approach questionnaire need to be considered,

and how any responses to the risks arising from these can be managed and planned.

Delivery Plan - Foundations

During Foundations, the team investigates the next level of detail and again, the next step can be

planned in detail and with reasonable confidence. More is understood about the requirements and
the overall MoSCoW priorities can be agreed. Because more is known, the accuracy is increases, and

uncertainty decreases, but it is still sensible to estimate within ranges, unless a fixed price estimate

is required. The requirements are likely to number in the 10s. The delivery plan concentrates on two

main areas, scheduling the work, and defining the approach. A schedule of timeboxes can now be

planned. For example, there will be three two week timeboxes to deliver increment one, followed by a

further increment. As each increment is completed, a new schedule of timeboxes is created for next

increment. The delivery plan describes the overall structure and approach to be adopted when working

in development timeboxes. It confirms the exact resources for the project, and outlines the number

and likely length of development timeboxes. It also provides information on the probable focus for the

timeboxes and the strategy for developing the solution. For example, it may state that the team will

be carrying out a semiformal investigation review, refinement review, consolidation review, and the

outcome and feedback will be recorded on the team wiki as a review record. The detailed planning of

each timebox is done at the start of each timebox and the detail of deployment planning is carried out

during the Evolutionary Development phase, when more is known about the solution.

Deployment Plan

The next level of planning considers how to deploy the evolving the solution. This is an expansion of

part of the early delivery plan. The deployment stakeholders need to be involved with this

plan, especially in larger complex organizations, where deployment is handled by separated teams and

can be a complicated activity. This can be planned within the development timeboxes, when enough

information is available to plan the detail of deployment. The deployment plan includes everything

required to move the solution or partial solution into its operational life and focuses on a schedule of

specific tasks to be done, rather than on products to be produced. It's therefore not usually possible to

timebox the deployment. The plan may contain a business deployment plan that will describe how new

business processes will be implemented, and any training that may be required. It may include a

system deployment plan for IT projects to describe how the system will be deployed. The benefits
realization plan is produced to show how and when the benefits are expected to realized after

deployment. Although this is a natural extension of the deployment plan, it's usually a separate

document, because it's used after the project for assessing whether the expected benefits have been

realized.

Timebox Plans

Timebox plans are the lowest level of planning and are produced by the Solution Development Team,

not by the project manager. The plan is, however, used by the project manager to

communicate expectations to the widest stakeholders and to measure the success of the team in terms

of what they actually deliver at the end of the timebox. This may be a major change in style from

managing a traditional project, especially if the management style has previously been more command

and control. At this level, the solution development team are agreeing what they're going to be working

on and the MoSCoW priorities over the next few weeks. They predict what is highly likely to be

delivered, the musts, what is likely to be delivered, the shoulds, and what may or may not be done, the

coulds. Because the timebox plan estimates are based on tasks, the level of uncertainty is lower and

the estimates are more accurate. The estimates are based on tasks, but the measurement of progress

is measured by the number of features completed, the outputs that meet the agreed acceptance

criteria. Care should be taken not to let the timebox plan become a detailed task plan.

Module Summary

As you've seen in this module, Agile Project Management uses a different style of planning from that

used in more traditional project management. In the early phases of the project, the planning focus is

concentrated on understanding just enough to ensure that the project is worth undertaking. The detailed

planning takes place in the development timeboxes, when there's a greater degree of certainty about

what could be accomplished. Balance needs to be maintained to apply the right level of process quality,

ensuring that it does not impeded the Agile nature of the project. The solution quality should
be understood by all stakeholders, and that it results in the solution meeting the business needs. The

maintainability level of the final product needs to be considered at the beginning of the project, because

it drives the nature of the development work. Each of the planning products have been investigated for

their purpose, content, and when in the lifecycle they're produced.

AgilePM® Exam Preparation

Learning Objectives

This module will look at the AgilePM Foundation and Practitioner exams and qualifications. You will

learn the format of each exam, the styles and types of questions for each exam, and the best way to

prepare for and approach the exams.

AgilePM® Foundation Exam

The Foundation exam tests the candidate's knowledge and comprehension of the AgilePM method, and

is a 40-minute closed book format containing 50 multiple choice questions. To pass the exam, you will

need to achieve a minimum score of 50%. Being a closed book exam means that you are not allowed

to use any reference materials during the exam. When you are ready to take the Foundation exam,

please contact your learning service provider to arrange your exams.

Foundation Exam - Styles of Question

The AgilePM Foundation exam contains classic multiple-choice style questions. These could be simple

true/false type questions, or ask you to select a correct answer from a possible four options. Despite the

different styles of multiple choice questions, please note that there will only ever be one correct answer

for each Foundation exam question.

Foundation Exam Suggest Approach

It's recommended that the three-run approach is used when taking the Foundation exam. This is

because some candidates feel tense at the start of the exam, and therefore need some time to settle

down and build confidence. Working through the exam paper in answering the questions that you know

will help build your confidence, so that when you work through the exam paper a second time, some of

the questions that you have missed will look easier. There's no negative mark in the AgilePM exams, so

you don't leave any questions unanswered, as there's always a chance that you might score

additional marks, even if you have to guess the answer. The last pass through the paper should include

any guesses.

AgilePM® Practitioner Exam

The objectives of the practitioner examination is to enable a candidate to demonstrate an understanding

of AgilePM and an ability to analyze and apply the guidance in an appropriate way in a given set of

circumstances described in a scenario. The practitioner exam is a two and a half hour objective test

consisting of four main questions. Each main question will contain a number of sub-questions, which

will total 20 question lines with one mark per question line, making a total of 80 marks available. To

pass the exam, you will need to achieve a minimum of 40 correct answers. The exam is open

book, which means that you can reference the AgilePM manual during the exam, but no other material

is allowed to be referenced. You may, however, handwrite notes or draw information physically onto the

pages of the manual, which you are likely to naturally do whilst learning the method. Candidates need to

pass the Foundation exam before sitting the Practitioner exam. When you are ready to take the exams,

please contact your learning service provider.

Practitioner Exam - Styles of Question

The AgilePM Practitioner exam contains a number of different styles of questions. The question types

are classic multiple choice questions, choose one from a list of possible answers, multiple

response, choose the correct options from a list. Candidates must remember to select, but limit the
number of responses to that requested in each question. If more responses are given than required by

the question, the answer will be void. Matching, involves linking items in one list to items in a second

list. There's only one correct response to each question, but options can usually be used more than

once or not at all. Sequencing, events to be positioned in a sequence. Assertion, reason, each item

consists of two statements, an assertion and a reason that could be linked by the word because. First

the candidate must determine whether the assertion is true or false, and then whether the reason is true

or false. If both are true, a third step is required, and the candidate must determine whether the reason

is a correct explanation for the assertion. You will have seen these in the exam simulations. Further

information is also available within the candidate guidance under support materials.

Practitioner Exam Approach

Some questions in the practitioner exam are straightforward, and some can be made easier by applying

exam techniques. For classic multiple choice questions, you should read the full question

and understand what's being asked. You should also read all the possible options before selecting your

answer. Multiple response questions require you to select a number of answers rather than just one. It

is important that you give the correct number of answers requested. For example, if the question asks

for three answers, and you select only two, or more than three, then you will score no marks for that

question. For matching style questions, you should bear in mind that for each question line, there is only

one correct response to each question. However, there may be two or more questions where the

response is the same. Sequencing questions can use a process by elimination approach.

When completing a sequencing question, you should aim to establish the first one or two steps in the

sequence. This will usually eliminate two or three of the possible options, leaving you with a

much simpler task of finding the correct answer. You should not attempt the assertion/reason questions

in one go. It is much easier to read the assertion first, and decide whether it is a true or false assertion,

then read the reason and decide whether that is a true or false statement. If either or both are

false, then you can make your answer selection. You will only need to go to a third step if both the
assertion and reason are true. If they are, then you can assess whether the reason explains the

assertion. To do this, you should read both statements with the word because in between them.

Module Summary

This brings us to the end of the course. We hope this course has prepared you well for your

certification. Please feel free to send us your comments and feedback using the details below.