Agile is predominantly about process innovation - what about product innovation?

To a great extent, the agile way of working is focussed on flexibility and speed in the upstream process of conceiving, designing and implementing software systems. Agility is commonly associated with the adaptive response to new (unexpected) information that becomes available during system development. My observation is that many agilists believe that uncertainties during development (such as ambiguities in customer requirements and the viability of new technologies) can be dealt with by using agile methods. In other words: the promise of the agile body of thought is that it will resolve these uncertainties before the system is shipped. Although I'm a fervent adherent of the agile approach, I don't think this assertion is tenable.

I believe agile is more than just process innovation. I would welcome the expansion of the agile body of thought to product innovation as well. In my humble opinion, the next step in agile software/system development is to adopt practices for the realization of agile systems, by which I mean systems that can respond rapidly to changed requirements after initial fielding of the system.

What are indicators of agility in systems? For instance, it is scalable in the sense that it can change the capacity rapidly to adapt to actual market demand. Or it is flexible in terms of functions and performance levels, to allow for modification after initial deployment by addition of modules or modification of performance levels.

As we all know, an overwhelming part of the total cost of software systems is due to maintenance activities and dealing with legacy issues. An agile way of working will certainly drive back these the sources of waste. However, the uncertainty doesn't stop after the release of the system - so agility in systems is needed as much as agility in the process.

And as a side-issue: would (or should?) there be any relationship betwee agility in system development and the delevery of agile systems?

Agile & Architecting: Friends or Foes?

Architecture has always been controversial in the agile community. Should design be done up front, how much, and when does architecture turn into BDUF, the big bad wolf of agile programming? I guess the agilists are right to some extend: most traditional architecture processes are heavy weight, long-winded and time-consuming. In circles of architects, however, agile methods are perceived as architecturally weak, disconnected from the realities of delivering large, multidisciplinary software-intensive systems in complex environments. I think it is possible and beneficial to combine the best of both worlds in a new breed of architects called Agile Architects.

Agilists sometimes caricature the role of the architect as an inhabitant of an ivory tower, surrounded by elaborated models and producing bulky architectural documentation that is subsequently assigned to the development team for realization. Although it is not surprising that the traditional architect is regarded by most agilists as a typical representative of the old paradigm in software engineering, I think we must beware of throwing the child out with the bath-water. To dispose of architecture as the basis for the realization of sizeable and complicated software-intensive systems is short-sighted and would certainly move back the hands. On the other hand, the rise of the agile approach will inevitably force the traditional architecture community to reflect on a new interpretation of architecture.

Agile Architecting is aiming at an increased level of agility in architects themselves, the architecture process, the resulting architectures, and delivered systems alike. I am convinced that the agile approach represents an exciting opportunity for architects to establish a streamlined and profitable development process for the realization of adaptable products based on an agile architecture.

---