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:
- The "build it and they will come" Agile approach – this means there is a sense of a problem and some vision of a solution that is not rooted in a business case, objectives, known effort, adoptability, and cannot adequately be budgeted for, or measured for success.
- The "Waterfall" Agile approach – this comes with a plan that defines costs for requirements, design, development, testing, deployment and a strategy to execute using Agile leading to a totally misaligned resourcing model, timeline, and support structure.
- The "Known Unknown" Agile approach – with credit to Donald Rumsfeld and NASA, means that we go into an initiative knowing there is a lack of understanding but will figure it out on the fly, which poses a significant risk of failure notwithstanding the already inherent risks of the Unknown Unknown of any project.
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.
Comments