5. What is Agile?
Generic Description of a style of working
Flexibility
Working closely with customer throughout
Ensuring final solution actually meets business need
Deferring decisions about detail as late as possible
AGI L E
6. What is Agile?
We are uncovering better ways of developing software
by doing it and helping others do it.
Through this work we have come to value
People and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan
That is; while there is value in the items on the right; we value the items on the left more.
(But Agile is not just about delivering software, it applies to all types of project)
9. Basics – The Principles
Principles support the philosophy
Highlight attitude and mindset needed by team
Compromising any principle undermines philosophy
• And introduces risk
Applying all principles ensures maximum benefit
Collectively principles enable organizations to
collaboratively deliver best value solutions
10. Basics – Principle 1
Focus on the business need
– Decisions based around project goal
– To deliver what business needs it to deliver, when it needs to be delivered
– Requires team to
• Understand true business priorities
• Establish sound business case
• Seek continuous business sponsorship
and commitment
• Guarantee Minimum Useable Subset
• Supported by
– Business roles
– Business Products agreed at Foundations stage
– Key techniques - MoSCoW prioritization and Timeboxing
11. Basics - Principle 2
Deliver on time
Requires team to
Timebox the work
Focus on business priorities
Always hit deadlines
Supported by
Key techniques : Timeboxing and MoSCoW
To build a reputation for timely and predictable deliveries
12. Basics - Principle 3
Collaborate
Requires team to
Involve the right stakeholders at the right time, throughout project
Ensure team members are empowered to make decisions
on behalf of those they represent
Actively involve business representatives
Build one-team culture
Supported by
Business roles
Key technique : Facilitated workshops
13. Basics – Principle 4
Never compromise quality
– Requires team to
• Set level of quality at the outset
• Ensure quality does not become a variable
• Design, document and test appropriately
• Test early and continuously
• Build in quality by constant review with the right people
• Supported by
Testing products
Early and integrated testing
Regular reviews throughout lifecycle
Key techniques : MoSCoW and Timeboxing
14. Basics - Principle 5
Build incrementally from firm foundations
Requires teams to
Strive for early delivery of business benefit where possible
Continually confirm correct solution is being built
Formally re-assess priorities and ongoing project viability with
each delivered increment
Supported by
The lifecycle
Creating a solid base of knowledge (Feasibility and Foundations)
before developing incrementally (through Exploration and
Engineering)
15. Basics - Principle 6
Develop iteratively
– Iterative development allows team to converge on accurate solution
– Nothing built perfectly 1st time
– Requires team to
• Do enough design up front (EDUF) to create strong foundations
• Build products using an iterative approach
• Build customer feedback into each iteration
• Accept that most detail emerges later rather than sooner
• Embrace change – the right solution will not evolve without it
• Be creative, experiment, learn, evolve
– Change is inevitable, allow for it and harness its benefits
• Supported by
– Iteration and constant review
Ensures the evolving solution aligns with what business really needs
16. Basics – Principle 7
Communicate continuously and clearly
– Requires team to
• Run daily stand-up sessions
• Use facilitated workshops
• Use ‘Rich Communication’ –modelling, prototyping
• Present iterations of evolving solution early and often
• Keep documentation lean & timely
• Manage stakeholder expectations throughout
• Encourage informal, face-to-face communication at all levels
• Supported by
User involvement and empowerment
Stand-up and Facilitated workshops
Clearly defined roles and user involvement
Models and prototypes – to make early instances of
solution visible
17. 17
Basics – Principle 8
Demonstrate control
Requires team, especially Project Manager and Team Leader, to
Use appropriate level of formality for tracking and reporting
Make plans and progress visible to all
Measured progress through delivery of products
Manage proactively
Continuously evaluate project viability based on business objectives
Supported by
Key technique : Timeboxing
Constant review
Planning products
Management Foundations and Timebox Plans
18. Agile Project Management
Different style of management (compared to traditional)
Enabling constant change during elaboration of the detail
Continuously correcting course
Maintaining aim on target (delivering a usable solution on a fixed date)
Monitoring progress in a different way
Measured by delivery of products (not by activity)
Sustaining the high rate of progress throughout
Targeting and motivating empowered teams
(Not directing them)
Collaboration requires a no-blame culture
Building culture of team success/failure
19. Agile – Management Style
Tightly Managed Teams Self Directed Teams (Agile)
Take directions Take initiative
Seek individual reward Focus on team contributions
Focus on low-level objectives Concentrate on solutions
Compete Co-operate
Comply with processes, Continuously look for better
regardless of outcome ways of working
React to emergencies Take steps to prevent
emergencies
21. 21
MoSCoW Prioritization
Must Have Guaranteed Minimum Useable SubseT
No more than 60% effort
Should Have Expected Work arounds difficult/costly
@ 20% effort
Could Have Possibly Work arounds easy/cheap
@ 20% effort
Won’t have this time Maybe next time Out of Scope for this timeframe
Requirements that cannot be de-scoped without causing the project to fail
Requirements that can be de-scoped as a last resort to keep the project on track
Requirements that can be de-scoped without causing significant problems
23. Timeboxing
2-4 (exceptionally 6) weeks
Investigation Refinement Consolidation
10-20% 60-80% 10-20%
Created by the Team
• Timebox supported by
MoSCoW for this Timebox
Milestone dates – Daily stand-ups
e.g.. Planned Review sessions • Communication and control
Roles and Responsibilities – Reviews
Deliverables (with acceptance criteria) • On-going acceptance and risk
reductions
24. Timeboxing - Iterations
Agree Timebox Sign-off what
Scope and has been
MoSCoW delivered.
priorities 10-20% 60-80% 10-20%
Assess impact
effort effort effort
of what has not
Investigation Refinement Consolidation been “done”
Investigate Work on the Finish off, ensuring
detail of work Solution in overall output
to be done line with agreed of Timebox is
MoSCoW priorities fit for purpose
25. Timeboxing - Iterations
For each iteration (Investigate, Refine, Consolidate) within a
Timebox Identify what has to
be done
in this iteration
Agree informal
Review the solution with
plan for how this will
Business Ambassador
be achieved in this
(and others?)
iteration
Evolve solution as
appropriate with detailed
input from Business
Ambassador
26. Timeboxing - Iterations
Review Review Review
Investigation Review Refinement Review Consolidation Review
• Team share results • Team share results • Share final results of
of their investigation with so far with Ambassador, Timebox with Ambassador,
Ambassador, Visionary Visionary (possibly) Visionary (probably), and
(possibly) and Technical and Technical Coordinator Technical Coordinator
Coordinator • Agree and prioritise work • Confirm deliverables are fit
• Team validate what they are to be completed by end of for their intended purpose
intending to deliver by Timebox (i.e.. meet agreed
end of Timebox acceptance criteria)
27. Timeboxing – Provides Control
Deploy Deploy
• Control is applied at the detail level – this Development Timebox
– Delivering on time every time
• If this Timebox is on time, the Increment (and Project) are on time
