Earlier in September, I presented at the Project Management Institute DC Chapter’s PM Symposium called Design for Agility, Focus on Impact! My presentation topic was titled “How to do a better job of measuring performance in Agile development.” This topic is important to me as we have been helping our clients’ transition to Agile development methodology for some time now.
As we transitioned from waterfall development to Agile development, often hybrid agile, we have encountered a number of stumbling blocks. We have wrestled with how to quantify progress in Agile since metrics that are used for traditional project measurement approaches do not adequately measure project health or progress. With Agile methodology, end goals are defined at the beginning; but requirements are not thoroughly defined from the get-go, creating challenges for many of us who have been raised on traditional project management and measurement approaches.
A large majority of my audience had project management experience and a good number had PMP certification. A variety of different industries and government experience were also represented by the attendees. Additionally, many continue to work on Agile projects and have similar issues with metrics.
Several attendees in the audience spoke about common challenges they face with their Agile projects. These include pressure from project sponsors to use and schedule scope variance metrics to measure progress in ways possible with the Waterfall development methodology; lack of understanding by senior leadership that end-users and stakeholders must spend time with Agile teams to define requirements on an going basis; lack of willingness among project leadership to prioritize the product backlog (requirements) to meet project deadlines; and the push to have consulting companies agree to a fixed cost for an Agile project when requirements are yet to be fully defined.
At the end, I reminded attendees that Agile is still new and evolving, unlike traditional project management approaches that have had decades to be formed and standardized around the world. By and large, the presentation resonated with the audience, and it was great to share the lessons learned and best practices from our Artemis teams with those who attended my presentation. I especially enjoyed the discussion with those who talked to me after the session. We had a hearty discussion about how to plan budgets for Agile development projects – using a labor hours approach that is based on prior project estimates was a good start. We also talked about how to measure responsiveness in Agile projects, and the types of projects that the Agile approach is best suited for.
I would like to give a shout-out to the PMI staff, who are all volunteers, for putting together an interesting array of topics packed into one full day! Please stay tuned for a second blog in which I delve into more about my presentation on Agile project measurements.