3. So why choose Agile then?
•
Because it's 'cool'
•
Someone said to do it
•
I like how you 'stand up'
•
You are so 'Retro'!
4. Why do projects?
•
Projects are about introducing change to;
•
New or existing processes, systems,
applications. Eg; New payment system
•
RTB - Running the business or BAU
changes. Eg; Update the website
content
•
CTB - Change the business to compete
or survive. Eg; Discounted offer
•
Organisations need to be good at projects
in order to deliver change
•
And we know projects sometimes fail or
not deliver the expected change for many
many reasons
•
We are not selling rainbows and unicorns
we are about delivering value
Agile is ONE way of being
good at delivering projects
5. Projects Succeed because...
•
User involvement and commitment
•
Executive / Senior Management sponsorship
•
Defined business objectives
•
Good control of project costs
•
Skilled and experienced team
•
Proven technology
•
Why has your project been considered a success??
6. And they fail because...
•
Unclear scope, objectives and requirements
•
Changing scope, objectives
•
Poor project management and governance
•
Lack of skills and experience
•
Artificial and unrealistic deadlines
•
Use of new technology
•
Poor quality
•
Why did your project fail??
13. We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
•
Individuals and interactions over processes and tools
•
Working software over comprehensive documentation
•
Customer collaboration over contract negotiation
•
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
14. You said what?
“....allows us to focus on delivering the
highest business value in the shortest time”
– Mike Cohen
17. The A Checklist for suitability
•
Do the sponsor and management understand and accept the agile philosophy as their buy-in is essential?
•
Will the team members be empowered to make decisions?
•
Is there senior user commitment to provide end user involvement? Can the organisation accommodate the frequent delivery
of increments?
•
Will it be possible for the project team to have access to the users throughout the project?
•
Will the project team remain the same throughout as stability is important? Will the team have appropriate skills?
•
Will the individual project team consist of 6-8 people or less?
•
Will the project use technology suitable for prototyping?
•
Is there a highly demonstrable user interface?
•
Is there clear ownership?
•
Will the solution development be computationally non-complex as the more complex the greater the risks? Can the solution
be implemented in increments?
•
Has the development a fixed timescale?
•
Can the requirements be prioritised - Must have O Should have Could have O Wont have (MOSCOW)
•
Can users define requirements interactively?
Source:Alan McSweeney
18. Pragmatic
1. of or pertaining to a practical point of view of practical considerations
19. A list of when not to
•
Process control / real-time applications
•
Requirements that have been fully specified before any programs
are written
•
Safety-critical applications
•
Solutions aimed at delivering re-usable components (a contentious one,
however this talks to the theory we are building and delivering business value NOW not
for tomorrow)
•
Well known and understood scope, risk, technology, - very little
"newness", we've done this before we can do it again
•
Building a house!
20. Selection criteria ideas
•
How complex is the project (think back to the classifications)
•
How much of the plan & requirements have you pre-baked, you may
be further along project methodology and approach than you think
•
Who's hungry? What appetite is there for Agile, don't do it if it doesn't
feel right
•
How engaged can/will you product owner(s) be?
•
Stability and accessibility to resources?
•
Flexibility towards scope. If you can't or won't accept change then
don't bother
•
COLLABORATE, COMMUNICATE, ADAPT, TEST, LEARN
21. “Agile is not something you become, it's
something you become more of”
–Mike Cohen