When I first came across Agile it was 2007 and I was given a set of reasonably well-defined requirements and a team of developers and a mandate to create an app to solve a problem. Prior to this I was familiar with iterative methods like DSDM that date back to the 1990s, and I had responded to a few large requirements specifications in my role as Key Account. And now I was in new territory, one which I initially interpreted as “more power to the team” (sw developers) and less to the “bureaucrats”. I haven´t really changed my mind.
Agile can be seen as a reaction to the old paradigm of requirements, waterfall, and final testing, with all its cost-overruns and “failed” projects. Agile gives more power to the team, and what we have now is explicitly a running negotiation between the customer and the supplier. This may be a good thing. The realities of software development are what they are – we might as well face them square on, rather than pretend that all will be well if we apply sufficient amounts of old-school professional project management.
So what seems to be the problem? Software is a the same time malleable and rigid. If you apply a little pressure, it yields, and you can often see small changes. But if you apply large pressure to effect large changes, you find that this takes a lot of time and effort. Key design assumptions permeate the system. A key element, often given little attention, is the information model. Often when we change a “system”, we are actually changing the information model. Moving an attribute up or down in a hierarchy can be extremely costly, because so much logic may depend on it.
The waterfall model was ditched because it is so hard to get the requirements right up front, and because they may change, and because there was too little focus on user involvement during the construction phase. But did we go to the other extreme, and get lazy? The danger in laziness is obvious: construction starts without sufficient probing of the difficult topics; as the project progresses you have to face them, and realize that you started to build the system on foundations or assumptions that turn out to be plain wrong. You have travelled far in the wrong direction.
So when the developer teams says “we don´t know what this will look like in the end so we will start here and refine it as we go along”, my response will be “why don´t you know? How hard have you looked? What effort would it take to improve your understanding before you start designing?”.
As for “agile business” , that looks to me like “retrofitting” or induction from agile as a software development approach. We are told that companies like Adobe and Apple are agile (!), and Spotify. I find this a sterile discussion, where inevitably “agile” ends up being applied as a label on anything that you want to applaud or promote. Agile ends up a victim of its own success – the other day agile was touted as the means to achieve security in software development. I rest my case.
So by all means, let´s work in 3-week periods and get feedback regularly and learn from each other. But let´s not get lazy. Many problems yield to a bit of determined analysis.