Often I speak with IT project measurement folks about the permeation of agile into their project estimation processes. While the Agile Manifesto recently celebrated its 15th birthday, it’s just been the last several years that I’ve seen agile gain substantial momentum in becoming the official method many companies shepherd their projects. Or has it…?
The graphic above shows that the use of agile over waterfall has yielded desirable results in terms of reaching business goals of delivering on time, within budget and with complete functionality. Yet I still hear IT project measurement people voice concerns about fully adopting agile for their projects.
My observations, from talking to many people trying to estimate agile projects, are from a purely estimating perspective. Before agile emerged, many development shops were building their projects via waterfall, ERP, RUP and other methods, all of which provided respective value. Upon agile’s debut, it was but a whisper, among a few, as the next leading development methodology. Over the years skeptical minds were slowly changed and adoption increased. Today more organizations are using agile to develop their projects, but I have found a surprising number of estimators telling me in a hushed tone – they aren’t really developing in agile, despite the proclamation from on high. They are using more a combination of agile and other development methods, yielding an agile hybrid, sometimes sheepishly referred to as “wagile” or “agilefall”.
Regardless of the development method, the C level still wants a project done on time, within budget and stable at delivery, but faith in agile hasn’t seemed to fully blossom yet, hence the inclination to interject older development methods along with agile.
I’ve been told that the sizing of agile projects is quite challenging due to the potential subjectivity as to how to measure size consistently in story points across divisions within an organization. A story point may mean different things to different groups across a company. However, this not unlike the challenge we face when trying to define any standard size entity across an organization (aside from function points which is a global standard).
Yet another point of concern is the transition of terminology from older development methods to agile. The people I have spoken to realized that the term “project” is not used in pure agile speak, rather agile thinks in terms of "delivered functionality". And there are other new terms that, in some cases, refer to familiar concepts, but they are new nonetheless and need to be employed in the agile world in order for us to talk to each other. The sizing and terminology concepts can easily fill their own blog posts!
Perhaps this is the natural evolution of a methodology maturing and agile is continuing to find its place in the estimation/development world. At the end of the day, the C level is looking for how much a project will cost and how long it will take to deliver, agile or not.