Agile pmo brussels 2012

1,139 views

Published on

Excellent presentation on the Agile PMO give by Mr. Stephen Messenger during the Agile Consortium Inner Circle in Brussels on Oct. 23rd.

This presentation addressees key aspects of running agile project and programme offices. The focus is mainly on the introduction and running of project management offices within an agile environment. As agile becomes increasingly popular among development teams within larger organisations frictions often arise between the different ‘cultures’. Often a PMO is seen as the ‘process police’ to be feared rather than a centre of excellence to be called upon for support, guidance and assistance. The PMO is often caught between the projects and the overall organisation, with demands coming from both sides. Getting the best for the business while ensuring the most important projects to the business receive a key focus to ensure maximum success, remains key however.

Published in: Business
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,139
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide
  • MontessoriPure consultancy companies where there is no IT at all – e.g. 4-person education consultancyUp to 5 minutes – point 2 is essential to get across(not IT specific, governance layers, project structure, long history – tried and tested in a variety of environments/regulatory Sox and Pharma, online startups, defence, banking, online gambling)(wide variety of industry and methods - scrum included)
  • MontessoriPure consultancy companies where there is no IT at all – e.g. 4-person education consultancyUp to 5 minutes – point 2 is essential to get across(not IT specific, governance layers, project structure, long history – tried and tested in a variety of environments/regulatory Sox and Pharma, online startups, defence, banking, online gambling)(wide variety of industry and methods - scrum included)
  • Mention other names for the PMO – Corp Project /Programme Office We cover all 3 scenarios. The focus is 2 and 3.
  • NEVER Gate 4Talk through diagram explaining gates (and process VERY quickly), include where gates 2 and 6 would occur.Highlight that this enables benefits management during the life of the project and cover points in the Benefits Management section:Business Case incrementally improved – power tool for PMO to manage portfolioNeed to think about how this impacts on the traditional projects. Their BCs may not be so easily updated once the project is started. Can stop an Agile proj more easily (need swift decision making) and more beneficial work undertaken.BC reviewed at every gate 5 Benefits from early incs justify later incsBen mgmt process for programmes which usually justify bens during their lifetime could be adapted.Bounding Box could be used instead of the BC approach. – Basically mgmt by exception – mgmt regularly checks that the team stays within the boundaries.
  • Do not go through this in detail.Discuss Feast or Famine and potential different approach – using up budget or you won’t get it next yearBudget range for agile projects – bottom end business as usual and essential capabilities maintained – upper end maximum the enterprise can afford. The business streams may or may not spend extra but budgets would not depend on spending this year’s allowance.
  • Mention Quality Management is clearly important here but will be discussed in answer to next question
  • Use MoSCoW for all projects – stress time-based nature of MoSCoWPMO puts any accepted proposal as a W and it moves up as decided by the governing bodyMention PAQ for assessing whether project proposals should be for Agile or not.
  • Could mention the following but they come into quality mgmt laterFacilitated workshops Continuous involvement of the business / user communityRegular reviews – early testing Incremental approach – control – know when things aren’t going well much quicker – Rigourous configuration management – ensuring that quality is not degraded once built in
  • Change is a fact of life in agile projectsThis is the rest of the section on Change Control
  • Velocity – beware changing team members, type of work, environment etcCycle time – customer request to delivered solutionBoomerangs – 2 key reasons – defects or misunderstandingsCustomer involvement – time spent working on the project Customer satisfaction – quickly captured during the reviews of the products from those who are paying for it.
  • Mention that Appendix C of the pocketbook contains a Project Health Checklist which can be modified by the PMO for other agile methods
  • PMs transitioning to Agile could be supported in planning, etc. by PMO
  • Mention estimating pocketbook
  • Ensuring that stakeholders aren’t overstretched between projects etc
  • Org may supplement the dsdm phases with specific activities – such as those reqd by regulatory bodies or internal audit etcDsdm agile project framework for Scrum (available on the website)Same with products and naming, roles Templates available on the website Checklist for tools in PB – support agile / support techniques / good user interface / involvement / export / versions / support evolutionary protoyping / etc
  • Developing and managing central agile library or inernal webpage / wiki Fast-track projct mobilisation service - templates – guidanceManaging a pool of agile coaches – who attend reviews and bring learning into central poolCommunity of practice, brown bag sessions etc
  • Talk through transition plan if timeTop - attitudesBottom – practices
  • Agile pmo brussels 2012

    1. 1. Julia Godwin – Director DSDM Consortium 1
    2. 2. We’ll look at…• How we got here• Some definitions Some questions Some answers• Typical Gates • Project Planning and Monitoring• Annual vs Agile • Support for Estimating Portfolio Management • Resource Management• Portfolio Prioritisation • Stakeholder Engagement• Change control of • Standards for Methods and Tools requirements • Knowledge Management• KPIs for Agile work • The Place to Go• Quality Management 2
    3. 3. How we got here• Brief background• Why DSDM?• The team• Our scope: Implications for a PMO of Agile approaches 3
    4. 4. Some Definitions• Our P in PMO stands for Projects• Three scenarios where Agile PMOs are needed: 1. Agile approaches are the norm – the PMO is new 2. The PMO is being driven by the use of Agile approaches 3. The PMO is promoting Agile approaches 4
    5. 5. Questions to answerPMO specialists ask: 1. How do we cope with less precise business cases? 2. How do we prioritise projects against each other if you can’t tell in advance what the benefits are? 3. How can this work in our regulated industry? 4. How do we recognise and report that an Agile project is going wrong? 5. How do we align seemingly ad hoc Agile project reporting with our time-based governance?We would add: 6. How could we make the life of Agile project easier and quicker while also serving the needs of the organisation? 5
    6. 6. Some answers to…1. How do we cope with less precise business cases?1.2. How do we prioritise projects against each other if you can’t tell in advance what the benefits are?3. How can this work in our regulated industry?4. How do we recognise and report that an Agile project is going wrong?5. How do we align seemingly ad hoc Agile project reporting with our time-based governance?6. How could we make the life of Agile projects easier and quicker while also serving the needs of the organisation? 6
    7. 7. Gated Review ProcessesTypical Gates1. Permission to investigate an idea2. Permission to build a Business Case3. Business Case approval – go ahead4. Permission to test deliverables5. Permission to deliver6. Project closure 7
    8. 8. Annual vs. Agile Portfolio Management Factor Annual AgileBasis for funding The known state of the organisation at the The known state of the organisation at anydecisions end of the financial year and the point during the financial year prediction for the next yearCapacity for change Limited by the allocated budget Enabled through continuous monitoringCommitment to “Once and for all” decisions made annually Discretionary funding decisions enabledspend throughout the yearUse of funding Potential for holding back on using Funding used to the full when allocated to resources early in the financial year, move the organisation forward because “they might be needed later”Exceeding budgets Reported at fixed points, e.g. quarterly – Reported at the time when it becomes leading to disaster recovery apparent - enabling better control of financial risksBenefits delivery May well be aligned to the annual cycle for Aligned to the ability to deliver ease of measurement and overall governanceRisk assessment Based on the known state at the start of Based on the state of the portfolio in its the financial year incremental delivery 8
    9. 9. Some answers to…1. How do we cope with less precise business cases?2. How do we prioritise projects against each other if you can’t tell in advance what the benefits are?3. How can this work in our regulated industry?4. How do we recognise and report that an Agile project is going wrong?5. How do we align seemingly ad hoc Agile project reporting with our time-based governance?6. How could we make the life of Agile projects easier and quicker while also serving the needs of the organisation? 9
    10. 10. Portfolio Prioritisation• Portfolio-level MoSCoW rules – Must have – at the core of business change – Should have – would be must have if there were no issues with resourcing, etc. (will be a Must Have soon!) – Could have – icing on the organisational cake – Won’t have this time – accepted as valid Business Cases but for later consideration• Assessing individual project’s suitability to Agile approaches 10
    11. 11. Some answers to…1. How do we cope with less precise business cases?2. How do we prioritise projects against each other if you can’t tell in advance what the benefits are?3. How can this work in our regulated industry?4. How do we recognise and report that an Agile project is going wrong?5. How do we align seemingly ad hoc Agile project reporting with our time-based governance?6. How could we make the life of Agile projects easier and quicker while also serving the needs of the organisation? 11
    12. 12. Change Control of Requirements - 1 Rqmts Rqmts 12
    13. 13. Change Control of Requirements - 2• Control changes to the breadth of requirements – not the depth• Consider how to achieve – Reduction of current procedures – Elimination of as many approvals as possible – The lightest possible Change Control Form – Stakeholders involved throughout the project• Monitor external dependencies 14
    14. 14. Some answers to…1. How do we cope with less precise business cases?2. How do we prioritise projects against each other if you can’t tell in advance what the benefits are?3. How can this work in our regulated industry?4. How do we recognise and report that an Agile project is going wrong?5. How do we align seemingly ad hoc Agile project reporting with our time-based governance?6. How could we make the life of Agile projects easier and quicker while also serving the needs of the organisation? 15
    15. 15. KPIs for Agile work• Velocity – one team’s productivity• Cycle time – from customer request received to solution delivered• Boomerangs – things that bounce back from delivered solutions• Customer involvement – time spent working on the project• Customer satisfaction – captured during the project, e.g. at Timebox Reviews 16
    16. 16. Quality Management• PMO needs to ascertain how the Agile quality principles below fit with corporate procedures, etc. – Excellent requirements evolved through facilitated workshops, etc. – Fitness for business purpose through continuous, consistent and focused customer involvement – Continuous review of the evolving solution and supporting documentation – Continuous validation and verification of the evolving and delivered solution through testing – Preservation of built-in quality through rigorous configuration management 17
    17. 17. Some answers to…1. How do we cope with less precise business cases?2. How do we prioritise projects against each other if you can’t tell in advance what the benefits are?3. How can this work in our regulated industry?4. How do we recognise and report that an Agile project is going wrong?5. How do we align seemingly ad hoc Agile project reporting with our time-based governance?6. How could we make the life of Agile projects easier and quicker while also serving the needs of the organisation? 18
    18. 18. Project Planning and Monitoring• Gantt charts only go so far• Need visible statement of what each Timebox will deliver (e.g. using MoSCoW rules)• Project information is on walls, whiteboards, cards, …• PMO can track what has/has not been delivered• Tools used to store information on walls can help the PMO – but should not replace the walls 19
    19. 19. Support for Estimating: points to consider• The horizon for estimates is much nearer than traditionally• The accuracy of estimates improves as the detailed requirements emerge• Historic data must be from Agile projects because – Project phases/activities will be different (especially evolutionary development) – Length of time on tasks different because of different communications – Level of customer involvement will be different (undertaking tasks not traditionally included in project plans) 20
    20. 20. Some answers to…1. How do we cope with less precise business cases?2. How do we prioritise projects against each other if you can’t tell in advance what the benefits are?3. How can this work in our regulated industry?4. How do we recognise and report that an Agile project is going wrong?5. How do we align seemingly ad hoc Agile project reporting with our time-based governance?6. How could we make the life of Agile projects easier and quicker while also serving the needs of the organisation? 21
    21. 21. Resource Management• Fine-tuned processes for acquiring resources swiftly (not just people)• Efficient HR systems (timely training, keeping skills up to date, employing contractors, etc.)• Avoid context-switching for scarce human resource• Include appropriate levels of customer participation in human resource plans 22
    22. 22. Stakeholder Engagement• PMO business as usual, e.g. monitoring which projects/programmes dealing with whom• PMO not part of the close engagement• Potential PMO activities: – Supporting efficient procedures for meeting rooms – Briefing stakeholders – Workshop kits – Facilitation 23
    23. 23. Standards for methods and tools• Tailoring guidelines – processes, products and roles• Pocketbook lists criteria for tools to be selected for use in Agile projects 24
    24. 24. Knowledge management• Agile knowledge may not be documented so remains local• PMO could – Manage a central Agile library or wiki or… – Provide fast-track project mobilisation service – Manage a pool of Agile coaches – Facilitate knowledge sharing, e.g. through COPs, brown-bag lunches, … 25
    25. 25. focus on compliance Planning the transition to Agile PMO focus on assurance dictatorial collaborative close to the business distant from clerical facilitative and projects business or projects reactive proactive responsive to avoiding change business change to projects bureaucratic responsive The ensuring rule-based empowered staid andadministrators experts / advisors Place incremental traditional delivery to Go periodic spikes encouraging small championing continuous support of demand on “big bang” & monitoring chunks of work projectsmeasures a significant measures arising respecting doing it all (context-overhead for projects from projects resource switching for people, constraints pet projects, etc.) 26
    26. 26. www.dsdm.org 27

    ×