Overstuffing Fixed Budget Projects Not New in Agile

Photo by Zach Graves

Photo by Zach Graves

I came across an explanation of how to handle change in agile fixed budget projects that I found rather telling; to protect the innocent, I won't post it directly.  Here's what it said:

  1. Define baseline product scope -- create the product backlog.  (Shows an image with different size stories contained in an oval.)
  2. Define additional scope (Shows more stories contained in a square with an arrow to add them to the baseline oval.)
  3. Removed stories to make room (Shows ONE story moved from the baseline oval to be outside the oval.)

The written steps make sense, but the visual shows what really happens: the work added to the scope is significantly more than what is removed.  I remember having the same challenges with change requests and fixed budget projects in my pre-agile days, and I had to write contract addendums with additional cost in most cases.  

A prioritized backlog and regular delivery of working software can help tremendously in easing the anxiety that drives scope creep, not to mention the ability to gain value early by releasing software that can help cover future development costs and provide better direction with customer feedback.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.

Budgets and Agile Software Development

Photo by Jon Tucker

Photo by Jon Tucker

Agile delivers results earlier than traditional methods, and organizations can manage ROI more effectively by focusing on the most valuable work and doing less [by cutting lower value features and projects].  It seems like funding agile software development should be simple--provide enough money to pay for the team for a given period of time, don't change who is on the team, and prioritize the most valuable work first--but the budgeting practices of most organizations are far more complicated.  Capital vs. operational spending, a heavy reliance on contractors rather than full-time employees, and a focus on projects rather than product development make it more difficult to keep teams stable and focused on the highest value work.

Daniel Greening wrote a lengthy article about agile capitalization that I found interesting, although I suspect organizations will likely be unable to get rid of timesheets completely as long as they have contractors on their teams.  But in an agile adoption, it may be wise to talk to the organization's CFO or finance department to build support for investing in people and resources that can further enable success.  Lisa Crispin has some great tips on how to talk to the CFO about agile.  

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.