Agile Project

Framework
From the Agile Business Consortium

(previously known as DSDM)

What is Agile Project
Framework?
An Agile Framework for IT Projects, developed in the Uk –
one of the earliest agile methods. www.agilebusiness.org
Evolving:
Version 1 1995
Version 2 1996
Version 3 1997
Version 4 2004
Atern 2006
Atern v2 2008
Agile Project Framework 2014
See https://www.agilebusiness.org/content/introduction-0
The 80/20 Approach
Nothing is built perfectly first time
80% of the solution can be produced in 20% of the
time it would take to produce the total solution
This is also known at the Pareto Principle

Suggested by a management consultant – Joseph

Juran but he named it after the Italian economist
Vilfredo Pareto who published a paper about 80/20
in 1896
 Flexing Requirements
FIXED Functionality Time
elementsResources

AGILE
TRAD

Time Resources VARIABL

Functionality E
element
s
8 Principles
Critical Success Factors
• Acceptance of philosophy
• Powers given to users
• Commitment from management
• Incremental delivery
• Easy access to business and end-users
• Team stability
• Development team skills
• Size of team (ideal size 6)
• Supportive commercial relationship
• Development technology available
Agile Project Framework
Stages in Lifecycle - 1
Pre-Project
Formalises a proposal and prioritises it in context of other work
being carried out in organisation in line with strategic goals
Feasibility
Is proposed project viable from business and technical perspective?
High-level investigation of potential solutions, costs and
timeframes
Foundations
Baseline high level requirements
Scope high level business processes
Identify user representatives
Scope non-functional requirements
Stages in Lifecycle - 2
Evolutionary Development
Iterative and incremental approach to developing solution
Solution will include product and business changes
Detailed user stories are investigated and translated into a product
Continual involvement of business roles to ensure fitness for purpose
Deployment
Assembly – incremental assembly of components of solution
Review – final acceptance check and retrospective of increment
Deployment – physical deployment of solution into operational use
Post-Project
Assesses business value achieved
Keep system operational
 APF PRODUCTS
ALL these products are EVOLUTIONARY, .i.e. they may change during the
project
Business Case Provides a vision and a justification for the project
from a business perspective. The business vision
describes a changed business as it is expected to be
at the end of the project
Prioritised Describes high level project requirements and
Requirements List indication of their priority for the business. Begins in
(PRL) Feasibility, baselined at end of Foundations, but may
change during the project
Solution Architecture High-level design framework for the solution - both
business and technical aspects. Provides scope but
does not constrain.
Development High-level definition of tools, techniques, customs,
Approach practices and standards that will be applied during
development
Delivery Plan High-level schedule of Project Increments and, for the
next Increment, Timeboxes that make up that
Increment
APF
ROLES
Orange = Business
Green =
Solution/technical
Blue =
Management
Grey = Support
Business sponsor Project champion, business case &
budget
Business visionary Senior business role, actively
involved in project
Project manager Responsible for business, technical
and delivery
Technical co- Sits above development teams
ordinator
Team leader Ensures team works as a whole
Business Comes from business area addressed
ambassador
Business analyst Analyses business needs
Solution Developer Specialist software developer
Solution Tester Performs non-user testing
Business advisor Supports team with specialist
business knowledge
Facilitated Workshops
Rapid, quality decision-making. Because all stakeholders
are present at the same time, there is great confidence
in the result.
Greater user buy-in. Workshops, run effectively, lead to
participants feeling more involved in the project
Building team spirit. It is a controlled way of building
rapport as well as delivering.
Process redesign by the user community. Participants
can gain a greater understanding of the inputs and
implications of their work.
Clarification of requirements when they are unclear.
Timeboxing
A timebox is a way of setting a deadline by which
a business objective must be met and a product
must be delivered
The aim of a timebox is to make something
It is product-based not task-based
Prioritisation - MoSCoW
Must have
O
Should have
Could have
O
Won’t have this time
Time-boxing &
Prioritisation
A FIXED period of time to achieve an objective
3 different levels: Project, Increment and Development
A development timebox should be 2 - 4 weeks long

Accept that you won’t do everything you plan

May have to drop some lower priority tasks
Therefore estimation must be ‘reasonable’
Development Timeboxes
A development timebox has 5 main stages:
1. Kick off meeting
2. Initial investigation of the products to be
delivered by the timebox
3. Refinement (development of the products
including testing and reviews)
4. Consolidation (final testing of software
products, completion of documents and
merging wth previous products)
5. Closing meeting
 PROTOTYPING IN TIMEBOXES

Jan Feb Mar Apr

Feas Foundation Increment 1 Dep Increment 2

s

Timebox Timebo Timebo Timebo Timebo

x x x x
 How might a project look?
A Project

8
m

Feasibility
Incr. One Incr. Two Incr. Three
Foundations

2m 3m 2m 1m

TB TB TB TB

2w
k
Control is achieved at the lowest level of time-
boxing