Module 01 - Introduction Flashcards
Agile History - early 1990’s
- Waterfall
- RAD
Most SDLCs used the ‘Waterfall’ approach.
Problems with the approach:
- Prescriptive and bureaucratic
- Difficult to overcome problems or errors
- Difficult to incorporate new ideas
- Need to re-open earlier ‘closed’ stages
- Customers didn’t know what they wanted
Attempt to address problems and speed up development process - Rapid Application Development (RAD) method.
No industry standard to define a RAD framework.
Agile History - DSDM
- DSDM
- DSDM Consortium
- Lightweight methods
Dynamic Systems Development Method (DSDM) was introduced by the DSDM Consortium - standardisation
DSDM Consortium - UK based s/w developers - a not-for-profit organisation - develop & promote independent RAD framework.
DSDM - foremost of the “lightweight” methods:
- Agile Unified Process (AUP)
- Crystal Clear
- Extreme Programming (XP)
- Feature Driven Development
- Lean
- SCRUM
The Agile Manifesto
- Timeline & organisation
- Agile Manifesto
2001 reps from XP, Scrum, DSDM and other ‘lightweight’ agrees framework
‘The manifesto for Agile Software Development’ or the ‘Agile Manifesto.’
Formed the Agile Alliance – a non-profit organisation committed to advancing Agile principles and practices.
The Agile Manifesto
- Individuals and interactions are more important than Processes and tools
- Working software is preferable to Comprehensive documentation
- Customer collaboration is better than Contract negotiation
- Responding to change has more value than Following a plan
DSDM Atern
- Timeline
- Agile PM
2007 - Latest version - DSDM Atern
2010 - the DSDM Consortium AgilePM.
Since 2010 DSDM Atern has evolved into Agile PF or the Agile Project Framework.
Retains DSDM’s project focused principles and delivery level process simplified to reflect current trends in evolutionary solutions development.
DSDM Philosophy
- Philosophy
- Stakeholder engagement
DSDM philosophy - 80% of the business benefit can be achieved relatively easily and quickly. Remaining 20% can take a disproportionately longer time and higher cost
Focus on early delivery of the most significant business benefits. Less important features dropped to ensure benefits are on time.
Key stakeholders must:
- Understand the business objectives and priorities
- Accept that change is inevitable
- Be willing to accept a ‘fit-for-purpose’ solution
- ‘On-time but incomplete’ better than ‘perfect but late’
DSDM Approach
- Traditional approach
- DSDM approach
Traditional approach
- Define the FEATURES that are to be delivered;
- Define the QUALITY requirements of those features;
- Define the COST and TIMESCALES to deliver features
- FEATURES and QUALITY are generally taken as FIXED,
- COSTS and TIMESCALES are seen as VARIABLE
DSDM approach
- Agree the TIMESCALE and COSTS early in the project,
- Define the required QUALITY standard.
- Prioritise FEATURES & confirm Minimum Usable SubseT.
- TIMESCALE and COST elements are kept FIXED
- Less important FEATURES dropped to keep deadlines.
DSDM Principles:
The philosophy is supported by eight basic principles:
- Focus on the Business need
- Deliver on time
- Collaborate
- Never compromise quality
- Build incrementally from firm foundations
- Develop iteratively
- Communicate continuously and clearly
- Demonstrate control
Principle 1 – Focus on the Business need
- Teams must
- Supported by
Decisions must be viewed against the main project goal - deliver maximum benefit in the shortest possible time
Teams must:
- Understand the true business priorities
- Establish a sound Business Case
- Seek continuous business sponsorship and commitment
- Guarantee the minimum usable subset of features
Supported by:
- Business roles
- Business products
- Key techniques (Timeboxing and MoSCoW)
Principle 2 – Deliver on time
- Teams must
- Supported by
Deadlines are non-negotiable
On-time delivery is often the most important success factor. Late delivery can undermine the project rationale
Teams must:
- Timebox the work
- Focus on business priorities
- Always hit deadlines
Supported by:
- Key techniques (Timeboxing and MoSCoW)
Principle 3 – Collaborate
- Teams must
- Supported by
Teams must be aligned and directed towards a common goal
Teams must:
- Involve the right stakeholders; at the right time
- Ensure members are empowered to make decisions
- Involve business representatives
- Build a one-team culture
Supported by:
- Business roles
- Facilitated Workshops technique
Principle 4 – Never compromise quality
- Teams must
- Supported by
Whilst FEATURES are viewed as variable, QUALITY is not
Teams must:
- Set the agreed level of quality at the outset of the project
- Ensure that QUALITY doesn’t become a variable
- Design, document and test appropriately
- Build in quality by constant review
- Test early and continuously
Supported by:
- Business and technical testing products
- Early and ongoing reviews
Principle 5 – Build incrementally from firm foundations
- Teams must
- Supported by
Basic product working as quickly as possible > Demonstrate to relevant Stakeholders > Refine and improve based on feedback until it satisfies the Business requirement
‘Enough design up front’
Teams must:
- Strive for early delivery of business benefits
- Continually confirm the correct solution is being built
- Reassess priorities and project viability with each delivered increment
Supported by:
- The DSDM lifecycle
Principle 6 – Develop iteratively
- Teams must
- Supported by
Approach relies on iteration to embrace change and produce a better solution
Teams must:
- Do enough design up front to create solid foundations
- Take an iterative approach to building all products
- Build customer feedback into each iteration
- Accept most detail emerges later, rather than sooner
- Embrace change
- Be creative, experiment, learn and evolve
Principle 7 – Communicate continuously and clearly
- Teams must
- Supported by
Poor communication is a common cause of project failure
Teams must:
- Run daily stand-up sessions (SCRUM)
- Use facilitated workshops
- Use rich techniques such as modelling and prototyping
- Keep documentation lean and timely
- Manage stakeholders’ expectations
- Encourage informal face-to-face comms at all levels
Supported by:
- Stand-ups
- Facilitated Workshops
- Modelling and prototyping
Principle 8 – Demonstrate control
- Teams must
- Supported by
Project must be in control at all times.
Teams must:
- Use right level of formality for tracking and reporting
- Make plans and progress against plans visible to all
- Measure progress of delivered products rather than completed activities
- Manage proactively
- Evaluate project viability based on the business objectives
Supported by:
- Key techniques – Timeboxing
- Management foundations
- Timebox plans
