Agiles 2009 - Agile PMO


Published on

Many companies nowadays had embraced agile practices in their core methodologies and are seeing improvements in the way they manage expectations with their customers or in their product quality as well. Is there anything left to achieve in the path of continuous improvement?

Followed by Lord Kelvin’s famous quote "If you can’t measure it, you can’t improve it.", Ariel Schapiro, PMO at Southworks, will introduce a process that helped him on measuring project’s health with Key Performance Indicators focused at improving a service-based business. This scenario usually requires more measurements than velocity, burndown and burnup charts in order to enhance aspects of the projects such as the daily work organization, awareness of the big picture, knowledge sharing and progress-seeking spirit.

Ariel will explore the process in which these indicators are measured and its incremental nature. Also how PM’s from different teams are collaboratively engaged on this engineering approach on agile practices.

As corollary, a statistical analysis will help on drawing the conclusions of the efficiency of this process.

Target audience:
Scrum practitioners, PMO members, project managers, developers and process owners

Key benefits:
- Understand indicators beyond velocity, burndown and burnup in order to measure project’s performance in service-based businesses.
- Get a sense of the application of engineering practices to agile contexts.

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agiles 2009 - Agile PMO

  1. 1. Agile PMO”improvingprojectshealth”<br />Ariel Schapiro<br />
  2. 2. Plan<br />¿?<br />
  3. 3. context<br />
  4. 4. Southworks.NET<br />ISO 9001:2000<br />x 4<br />
  5. 5. Projects<br />.NET<br />WCF<br />Training Kits<br />Handsonlabs<br />SaaS (S+S)<br />Silverlight<br />WPF<br />WF<br />Identity<br />Windows Azure<br />Reference implementation applications<br />
  6. 6. SCRUM-likeProcess<br />TDD<br />PairProgramming<br />(2~3 months total duration)<br />Customer participation<br />Weekly meetings schedule<br />Iteration Backlog<br />
  7. 7. Continuous Improvement<br />
  8. 8. HealthCheckmeasurementprocess<br />
  9. 9. Anatomy of the process<br />HardIndicators<br />Formal Process<br />(ISO, CMMi)<br />RetrospectiveServices<br />Customerfeedback<br />
  10. 10. HardIndicators<br />Teamselfassesment<br />basedonthresholds<br />and backed up byevidence.<br />
  11. 11. HardIndicators<br />HardIndicators<br />
  12. 12. RetrospectiveServices<br /><ul><li>Good…
  13. 13. Poor…
  14. 14. Consider…</li></ul>RetrospectiveServices<br />
  15. 15. Customerfeedback<br />Customerfeedback<br />
  16. 16. Anatomy of the process<br />HardIndicators<br />Formal Process<br />(ISO, CMMi)<br />RetrospectiveServices<br />Customerfeedback<br />
  17. 17. Results &conclusions<br />
  18. 18. Results<br />Age (weeks)<br />
  19. 19. Results<br />
  20. 20. Results<br />&quot;The project map helped me to understand the global scope of the project and to know easily what are we working on right now.“<br />“These assets really help me on planning ahead the testing process.&quot;<br />&quot;Screencasts were and still are very useful for me to go over the progress made during the sprint.“<br />
  21. 21. Conclusions<br />Improvement because of:<br />Self measurement: reflecting<br />Osmotic communication (Alistair Cockburn) at a company level<br />Scrum + engineeringpractices<br />Valuable initiatives imitation<br />Sharing + Reusability<br />
  22. 22. Ariel Schapiro<br /><br /><br />Thanks!<br />