This is the fifth and final post in a series that offers our management team's reflections on DCG's 20th anniversary and the state of the software industry. Previous posts here, here,here, and here.
I make no excuse for using a French expression, as it sums up things very succinctly. “The more things change, the more they stay the same” is something of a cliché, and of course it’s not completely true, but then again, it’s not completely false.
This year is DCG/DCG-SMS’ 20th anniversary. In thinking about how the industry has changed in the past 20 years, there’s no better way to describe it than the above expression.
The Need For Change
Who remembers SSADM –Structured Systems Analysis and Design Method? Developed by CCTA, who also developed ITIL, SSADM was (and is) a very structured 7-step waterfall process from Stage 0 – Feasibility to Stage 6 – Physical Design; oh, and then you had to build the application. SSADM is the culmination of the Big Process approach to application development; if all went to according to the huge WBS and GANTT chart plan, then you had a perfect system out of the sausage machine.
It didn’t work, of course. The problem with any process-heavy approach is that the base assumption is that the world stands still while you build the application. We all know that, even with small application builds, a lot of things change our view of the business needs while we’re working. SSADM was aimed at those government projects that would end up in the top one percent of the size range (5,000+ Function Points – FP), where change during the project is so huge that you can never get to the end point and “analysis paralysis” sets in.
Clearly there was a problem. One project I was on as a requirements manager delivered its first release at 0.5 FP/100 hrs, against industry expectations of about 6 FP/100 hrs. By the end, we were still only producing 1.5 FP/100 hrs and the application was nearly 8,000 FP. You do the math (at £400 per day base cost). The project team was huge and we were all working our socks off. We did deliver, of course, but with a lot of help from EDS, who became outsourcing partners during the project.
So now we have Agile. Large programmes are delivered through smaller applications, built incrementally by small teams, using continuous integration to deliver change quickly and much more effectively. There is process, of course, exemplified by SAFe and DSDM. to provide programme level support for scrum and the development methods at its heart.
In those organisations that become Agile throughout, a software development methodology has become a method for delivering business change. Hooray, the cavalry has come over the horizon and saved the day. Or has it?
Things Stay the Same
So now we’ve moved on. We do things so much better, but still projects fail. The 2014 PMI Pulse report shows that projects include IT waste totaling $109m of every $1bn spent. Highly Agile organisations are better at delivery, and crucially, such organisations tend to be more mature at change management, project management, and have active PMOs. They also have more visible and active project sponsors.
Sadly, in those organisations where effective agility has not been adopted, chaos reigns. Too often we hear the comment, “You don’t understand; we’re Agile, so we don’t need all that process.” Haven’t they heard of minimum marketable features? Where sponsors and teams have no idea of where their business is going, Agile becomes a mask for failure of strategy, and dreams and money get poured down the drain.
So what remains the same is that discipline, foresight, and adherence to Agile processes are key to successful delivery. People and organisations who were poor at applying waterfall principles tend to be poor at Agile too.
Agile is a disruptive game changer; it can and does increase the rate of delivery while reducing costs, but treating it as a carte blanche for anarchy does the concepts behind it, and the businesses hoping to reap the benefits, no favours.
DCG-SMS, Managing Director