While software development firms from coast-to-coast boast of utilizing agile app development to produce finished products ahead of schedule and under budget, reality says otherwise. Despite relying on the agile way of doing things, software development companies still deliver late and bill customers more than originally planned. The question is, why? According to Tech Crunch contributing author Sven Jungmann, the problem is myopia.
Jungmann’s January 4 (2017) piece does a very good job of detailing how myopia affects agile teams and their own view of what they are doing. Those negative effects often carry across an entire project to the detriment of the client and the finished product. According to Jungmann, the problem of agile app development not delivering what it promises is a very real problem backed up by research.
A 2013 paper from a team of Oxford researchers showed that among some 4,000 agile IT projects surveyed, schedule overruns were in excess of 37% while cost overruns came in more than 107%. Nearly 13% of all the projects were twice as expensive and behind schedule.
Jungmann asserts that myopia is to blame. In a literal sense, myopia is a physical condition we also know as nearsightedness. Someone who is myopic sees very clearly up close, but anything beyond a certain distance is blurry. Myopia in software development doesn’t inhibit the ability of agile teams to see what’s going on right in front of them. Yet they cannot see outside of their own circles to get a broader picture of the project as a whole.[Not a valid template]
Reference Class Forecasting the Solution
Without going through Jungmann’s explanation in complete detail, we can summarize by saying he offers something known as reference class forecasting as a solution to agile team myopia. Reference class forecasting is an engineering solution often employed outside the IT arena to forecast predicted outcomes for the purposes of planning.
The crux of this sort of forecasting is comparing apples to apples, so to speak. Very few software development companies do this. Instead, their forecasting is based on their own past histories and the projects they have completed. But what if a brand-new project has very little in common with anything else the firm has done in the past? Those past projects do not offer any framework for forecasting because they are so completely unrelated.
Reference class forecasting requires finding other reference points that give agile teams and individual developers a clear understanding of the bigger picture. Yes, delays and budget overruns are part of software and mobile app development. And yes, agile app development is designed to mitigate them as much as possible. But agile teams and individual developers still have to forecast possible scenarios that could increase time spent or strain budgets.
Jungmann thoroughly explains how reference class forecasting can significantly reduce cost overruns and missed deadlines in agile software development. In fact, his own development team has proven that it works. For the purposes of this article, however, the first step in solving the problem is admitting the problem exists.
Agility for Its Own Sake Is Bad
For a software development firm to market itself as being masters of agile app development is not smart if agility doesn’t produce the kinds of results the company promises. Simply put, agility for its own sake is a bad business model. The software company whose agile teams can’t produce on time and within budget need to admit there’s something wrong – and that the problem might be myopia. Only when the firm recognizes its own myopic tendencies can those tendencies be addressed and corrected.