Agile Project Management

Agile Project Management

• 1.
  DSDM® Atern -APMG™ Agile Project Management A brief summary of its foundations according to the Handbook version 1.1 Pablo Gonzalez Garcia 2013
• 2.
  Contents Agile Project Management Fundamentals Philosophy Principles Preparation TheLifecycle Roles and Responsibilities Products Facilitated Workshop MoSCoW Prioritisation Timeboxing Requirements Measurements Quality Planning Risks 2/22
• 3.
  Fundamentals Agile Project Management DSDMAtern → Agile Project Delivery Framework = Project Management Lifecycle + Product Development Lifecycle Time Cost Fixed Variables Acceptance criteria is agreed and set before development commences Quality Variable Features • • • If Contingency is required: MoSCoW rules for prioritization Minimum Usable Subset is guaranteed Business Benefit drive the prioritization Contingency is managed within the prioritization of the features rather than by adding extra cost or time. 3/22
• 4.
  Philosophy Agile Project Management Principles Process People Products Practices ProjectLifecycle Roles & Responsibilities Deliverables Techniques Atern → Tailored to suit Project Environment ↓ Adequate formality so that waste is eliminated and all activities add value “Negotiation is around the fine detail” 4/22
• 5.
  Principles I 1- Focuson the Business Need 2- Deliver on Time 3- Collaborate Agile Project Management • • • • Understand the true business priorities Establish a sound business case Seek continuous business sponsorship and commitment Guarantee the minimum usable subset • Timebox the work • Focus on business priorities (MoSCoW) • Always hit deadlines • Involve the right stakeholders at the right time • Ensure that the members of the team are empowered to take decisions on behalf those they represent • Actively involve the Business Representatives • Build a one-team culture 5/22
• 6.
  Principles II Agile ProjectManagement 4- Never compromise Quality • • • • • 5- Build incrementally from firm Foundations • Strive for early delivery of business benefit • Continually confirm the correct solution is being built • Formally re-assess priorities and on-going project viability 6- Develop iteratively • • • • • • Set the level of quality at the outset Ensure that quality does not become a variable Design, document and test appropriately Build in quality by constant review Test early and continuously Do Enough Design up Front (EDUF)* Take an iterative approach to building all products Build customer feedback into each iteration Accept that most detail emerges later rather than sooner Embrace change Be creative, experiment, learn and evolve *Enough Design up Front (EDUF) instead of : Big Design up Front (BDUF): Traditional projects, lack of flexibility or creativity No Design up Front (NDUF): Other Agile approaches, too risky in complex structures 6/22
• 7.
  Principles III Agile ProjectManagement • Run daily team stand-up* sessions • Use facilitated workshops 7- Communicate • Use rich communication techniques such as modelling and prototyping continuously and • Present instances of the evolving solution early and often clearly • Keep documentation lean and timely • Manage stakeholders expectations throughout the project • Encourage informal face to face communication at all levels 8- Demonstrate control • Use an appropriate level of formality for tracking and reporting • Make plans and progress visible to all • Measure progress through focus on delivery of products rather than completed activities • Manage proactively • Evaluate continuing project viability based on the business objectives *The Daily Stand-up: Each team member in turn describes: • What they have been doing since the last Stand-up • What they will be doing between now and the next Stand-up • Any problems, risks or issues Short and fixed duration (15 minutes) 7/22
• 8.
  Preparation Agile Project Management I.S.F.- Instrumental Success Factors 1. Acceptance of the Atern philosophy before starting work 2. Appropriate empowerment of the solution development team 3. Commitment of Senior Business Management to provide the necessary Business Ambassador involvement 4. Incremental Delivery 5. Access by the solution development team to business roles 6. Solution development team Stability 7. Solution development team Skills 8. Solution development team Size (7±2) 9. A supportive commercial relationship P.A.Q. - Project Approach Questionnaire  identifies and confirm level of achievement of above ISFs and assess potential risk areas to be addressed  Completed during feasibility process on the Outline Plan product  Re-assessed during foundations process on the Management Foundations product 8/22
• 9.
  The Lifecycle Agile ProjectManagement Pre-Project Proposal Feasibility First opportunity to asses the feasibility from a Business and Technical perspective Foundations Establish firm foundations on the Business, Solution and Management areas Exploration and Engineering Evolve the solution with functional requirements (Exploration) and non-functional requirements (Engineering) Deployment Put the solution in live use Post-Project Assess whether the benefits have actually been achieved 9/22
• 10.
  Roles and Responsibilities AgileProject Management • Business Visionary Business Ambassador Business Analyst Team Leader Technical Coordinator Business Advisor Solution Developer Solution Tester DSDM Coach Other Workshop Facilitator Solution Development Team Technical Advisor Project Manager Project Level Business Sponsor • • • • Business Sponsor: owns the Business Case, takes financial decisions. Business Visionary: Customer vision, interprets needs. Technical Coordinator: Supplier vision. SDT: can be one or more Size 7 ± 2 One DSDM role does not necessarily mean one person. Business Manage ment Solution 10/22
• 11.
  Products I Pre-Project Feasibility Agile ProjectManagement Terms of Reference: Business Driver and Scope for the project overall. Justification for the Feasibility phase Feasibility Assessment: Outline Business Case, Risk Assessment, Outline Solution, Feasibility Prototype (opt.) Outline Plan: Outline Plan, Project Approach Questionnaire (P.A.Q.) Business Foundations: Business Vision, Business Case Prioritised Requirement List: High Level Requirements, MoSCoW priorities Requirements are baseline, agreed and signed-off Solutions Foundations: Business Area Definition (BAD), System Architecture Definition (SAD), Deployment Approach Definition (DAD): Solution review and testing strategy Foundations Solution Prototype (opt.) Management Foundations: Project Organisation, Project Governance, Management Approach (P.A.Q. re-assessed) Delivery Plan: Schedule of Timeboxes, Deployment Plan (outline) Delivery Control Pack: Risk Log, Periodic Reports, Change Control Records (only changes on the scope) 11/22
• 12.
  Products II Agile ProjectManagement Evolving Solution: Business Models (from BAD), Design Models (from SAD), Business User Documentation, Prototypes, Deployable Solution, Support Documentation Exploration and Engineering Solution Assurance Pack: Business Testing Pack, System Testing Pack, Solution Review Records (input for Timebox Review Record) Deployment Plan: Business Deployment Plan, System Deployment Plan, Benefits Realisation Plan Timebox Plan: for each development Timebox Timebox Review Record: for each development Timebox Deployed Solution: An in increment of the solution in live use Deployment Post-Project Project Review Report: Increment Review, Benefits Enablement Summary, End of Project Assessment Benefits Assessment: For each increment (outcome) and/or for the project as a whole 12/22
• 13.
  Facilitated Workshop Objective Owner Participants Facilitator Agile ProjectManagement Product Solution Needs the outcome of the workshop Is the driver for it to happen Set of people who are chosen and empowered to produce the product or solution Neutral and independent person Benefits  Rapid, high quality decision making  Greater buy-in from all stakeholders  Building team spirit  Building consensus  Clarification of issues Success Factors  Effective, trained, independent Workshop Facilitator  Flexibility in the format, but clearly defined objectives  Thorough preparation before the workshop  Results of previous workshops are built in  Decisions and agreements are not forced  Workshop report within 48 hours 13/22
• 14.
  MoSCoW Prioritisation Must Have ShouldHave Could Have Won’t Have (this time) Agile Project Management Maximum 60% of total effort Worst Case, Minimum Usable Subset (based on anticipated benefit) Cannot deliver without this No point delivering on target date without this What happens if this requirement is not met? ‘Cancel the project’ Maximum 20% of total effort Expected Case Important but not vital May be painful to leave out, but the solution is still viable May need some kind of workaround Maximum 20% of total effort Best Case Wanted / desirable but less important Less impact if left out (compare with a should have) Agreed these requirements will not be delivered Recorded in PRL 80% of the solution can be produced in 20% of the time that it would take to produce the total solution 14/22
• 15.
  Timeboxing I Iterative DevelopmentCycle Agile Project Management Timebox Control Kick Off Investigation • Review objectives • Provide a firm foundation to develop • Ensure feasibility the work • Agree acceptance criteria • Confirm availability of resources • Review dependencies • Assess risks Refinement • Develop the work • Testing • Ends with a review with Business Ambassador to decide if the acceptance criteria will be met • Define actions to achieve acceptance Consolidation • Perform actions agreed at refinement • Quality control Control • Timebox Review Records • Solution Review Records • Daily Stand-up meeting Close Out • Formal sign off • Assess work not completed • Lessons learned 15/22
• 16.
  Timeboxing II -Planning and Scheduling Timeboxes Agile Project Management Feasibility and Foundations P r o j e c t I n c r e m e n t 1 Timebox 1 Fixed end date / Output Exploration and Engineering Timebox 2 Fixed end date / Output Timebox 3 Fixed end date / Output Deployment Fixed end date / Outcome I n c r Application of the Timeboxing technique in conjunction with MoSCoW prioritisation will ensure on-time completion of each Timebox and the delivery of a fit-for-purpose product in that timeframe 2 16/22
• 17.
  Requirements Feasibility Agile Project Management Outline Plan Typically<10 requirements by end Feasibility Rough estimates ‘Broad picture’ Project Go / No-Go Foundations Delivery Plan Typically <100 requirements by end Foundations Accurate ± 50% ‘What’ to do Project Go / No-Go Exploration and Engineering Requirement • Service • Feature • Function Timebox Plan Typically >100 requirements by end Exploration and Engineering ‘How’ to do it Non-functional Requirement • Performance • Supportability • Capacity • Maintainability • Security 17/22
• 18.
  Measurements Business Value (or outcome) AgileProject Management Earned Value Analysis (EVA). Measure the value that has been ‘earned’ to date in the project (on the product/result/service). Output Used to define the objectives for the Timeboxes (deliverables). Quality Number of defects. Effort and delivery The effort of a timebox is fixed and it is expected to deliver a number of prioritised features. speed (velocity) Cost The Business Case is based on the balance between cost and business value. 18/22
• 19.
  Quality Agile Project Management Not100% but still a quality solution The quality is judged on whether the solution contains at least the Minimum Usable Subset (60% solution) and whether all delivered requirements meet the agreed standard. Maintainability Level 1 Maintainability is a required attribute of the initial delivered solution Level 2 Deliver first, re-engineer later Level 3 Short term, tactical solution 19/22
• 20.
  Planning Agile Project Management • • • • Planin detail Foundations Approximation of the size and duration of the overall project Outline the first increment List the planned dates for deployment of later increments • • • • Schedule the work Outline the number and likely length of the Timeboxes Include an outline of the Increments Describe the overall structure and approach Deployment Plan • Exploration and Engineering • Include Business Deployment Plans, System Deployment Plans and Benefits Realisation Plans Focus on specific tasks to be performed by specific individuals Timebox Plan • • Details the deliverables (outputs), activities and resources of a Timebox Focus on outputs Outline Plan Feasibility Delivery Plan Foundations 20/22
• 21.
  Risks I Agile ProjectManagement Risks to successful Atern Low or patchy availability of Business roles Having a fully detailed specification In the early lifecycle phases, define and agree the level of commitment needed. Try to introduce the concept of Iterative Development and Enough Design Up Front (EDUF) before time and effort is spent producing this detailed specification. Expecting the 100% solution Atern’s approach is based around the idea that Time, Cost and Quality are fixed and contingency is built around the prioritisation of Features. The best case is to deliver the 100% solution. Swapping resources in and out of the team Try to ring-fence the team for the duration of the project. Atern’s small teams and the use of rich communication means that a lot of the team information is known and shared informally, rather than being formally written down. 21/22
• 22.
  Risks II Agile ProjectManagement How Atern reduces risks The business don’t know exactly what they want This is seen as normal as the detail emerges through ‘Iterative Development’. The business change their minds Change is seen as a fact of life and is encompassed within the Timebox and MoSCoW prioritisation process. Not having all the detail agreed at the start Atern’s principle of ‘Build from Firm Foundations’ ensures Enough Design Up Front (EDUF) is done to move the project safely forward. Unwillingness to commit to final signoff Using Atern’s Timeboxes the business accepts the evolving solution incrementally. Late delivery The whole Atern approach is designed to deliver the right solution on time. 22/22