It is budget season for most investment firms, and the best-laid plans for 2016 expenditures are carefully being developed to address priorities of business and IT. Unfortunately the best-laid plans of mice and men oft go astray as the old idiom says. Plans go astray for varied reasons like unforeseen needs of the business, vendor challenges, market events, and poor execution. These could all merit a lengthy write-up, but there is an industry transformation in execution methodology which tosses a monkey wrench into many firms' annual planning efforts, the desire for agility.
It is the goal of most organizations (hopefully) to efficiently deliver technology solutions. Agile methodology champions collaboration, evolving requirements, iteration and incremental value delivery, and faster time to market of deployable solutions. Some also maintain that Agile ensures cost certainty because of short cycles and predictable delivery.
I would challenge the notion that any technology can be delivered to defined objectives, quickly, at high quality, with organizational buy-in, at reduced cost and certainty. This is not to say a good plan can't be executed on, only that there are trade-offs that need to be managed based on expectations and priorities. I have learned this from practical experience and by working with and learning from people I regard as some of the best technology leaders in the industry.
I would assert from these experiences that increasing the quality, collaboration, and iterations, while executing in an Agile manner leads to greater uncertainty and higher costs in the same manner that traditional SDLC methodologies would. Conversely if you gate technology delivery and execution based primarily on cost, you are likely to have to trade off objectives, quality, etc.
How do you avoid the pitfalls of Agile methodology cost uncertainty? I've seen many red flags in the industry, particularly amongst those who have immature Agile capabilities, what I would plot as "Ad-hoc" or "Doing Agile" on some proposed Agile maturity models. The immaturity of Agile capabilities leads to poor conceptualization and staging of initiatives, example of which include:
So how do you plan budgets around Agile? For firms who are just developing Agile capabilities, start with a traditional business case that defines what need is being solved, who needs to own and participate in the project, what the team structure and collaboration model will be, and take a crack at strategizing some of the incremental delivery priorities of the initiative. Set a not-to-exceed budget with room for adjustment and assume dedicated resources and possible engagement of external assistance. Lower expectations and understand that you must learn about your firms' ability to execute in an Agile way, and you must develop these skills along with delivering the work at hand. Firms who have assessed their own abilities, and who have developed a mature capability, adopt a business as usual approach, with a baseline cost model determined by past capacity to deliver supplemented by additional estimates for strategic, transformative, or large scale efforts.
At the end of the day, for many firms the investment required to become Agile could be as substantial as investments in the projects firms are undertaking. The question is whether firms plan for it or experience it though the pain of execution; either way the cost will be incurred.
