A project is generally defined as “a temporary endeavor undertaken to create a unique product, service or result.” Projects are limited by the scope, budget, and schedule. All of which are measured to understand the progress of the project and success in achieving the scope, budget, and schedule.
Agile Methodology is derived from the Agile Manifesto (available at https://agilemanifesto.org/) documented in 2001 by a small group in Salt Lake City. Their focus was on software development. The core values are (arguably) product (not project) driven:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
I’ve had many contacts over the years regarding positions for which I was qualified which fell apart on my lacking the status of a “certified” Scrum Manager. Which makes it a bit odd that twice I was contracted specifically for an extensive Traditional Project Background and Experience. My job: to deliver the status and progress of the corporate agile software development in traditional project metrics.
On another contract, I was hired as the Scheduling SME and MS Project SME. My last delivery (6 months prior to my expected departure / possible extension) was a process to load the MS Project Schedule into a Jira structure, then used along with the Agile Development structure(s) as a Schedule. Jira is optimized as a collaboration tool and allows scheduling of issues and other components of the structures, but requires an add-on to “schedule” – usually utilizing MS Project.
All the above sets the stage for three issues:
- Agile is at its heart a Product Development methodology – akin to a System/Software Development Life Cycle.
- Agile does not have the measurements in place for an apples-to-apples correspondence reporting with traditional project management reporting.
- The Agile Team mindset resists requests for reporting / data other that “Agile” reporting.
- I’ve been asked countless times over the years if I know / understand SDLC. I also managed several projects, and participated in others which were structured as multiple iterations of a development, with checks / gates at the end of each iteration to determine the success of the iteration, and any changes required for the next iteration. Incorporated in each was a Go / NoGo checkpoint. Yes, Agile was not a methodology yet, but it was a Traditional Project structure for an Agile project. So, my question over the years has always been – why is it considered yet another PM Methodology? Knowing that the scope, budget, and schedule will be constantly changing (as virtually every project with which I’ve been involved has done).
- On the contract asking for a Jira “schedule” (without using MS Project, by the way) I was also asked for Earned Value. Given the typical flexibility of an Agile product development, it can seem impossible, but consider the typical project and the changes that happen. Defining the expected number of sprints, knowing the “capacity” of a given Scrum Team, and projecting costs against those story points allows calculation of Planned Value, Acutal Costs, and Earned Value. Which can then be used to determine the Schedule Variance, and Cost Variance, Schedule Performance Index, Cost Performance Index, Estimate at Completion, and Budget at Completion. All while the Agile / Scrum Teams continue to utilize their performance metrics.
- The two actions of incorporating the Agile / multiple iteration projects under the traditional Project Management Methodology and defining a complete Earned Value Management system removes the difficulties of having two different understandings of just what the Agile team is doing. It also avoids the problem of Directors being requested to put the Agile reports into the standard terms of reference used by the Portolio managers.
As the project progresses, the normal change processes are used to record scope, schedule, and budget changes and fed into the Earned Value Management system.