Agile methodology is widely accepted and has been adapted to many specific applications. The motivation to develop “lightweight” processes for accelerated production of software, lead to the formulation of the very ambitious Agile Manifesto in 2001. 1999 was a low point for the software development community, not only did revisiting old code to hunt for Y2K bugs seem like punishment at the peak of the .com boom, but more critically – the process exposed fundamental weaknesses of the documentation heavy processes in the past. It was time for a disruptive change; the pragmatism behind a general reluctance to adopt new approaches evidently failed us.
The appeal of Agile was by no means a discovery of new techniques, we've seen or done it all before, but this time a methodology was elegantly distilled into a few pages rather than a book. The Agile Manifesto offered a convincing vision of preferred values and principles focusing on collaboration, responsiveness, the individuals and their roles instead of a rigid processes and documentation. Other benefits ascribed to Agile include: satisfaction through rapid delivery and high ROI (return on investment).
______________________
more agile
The informal and often cuddly nature of the face-to-face workflow has at times been vulnerable to parody in its less successful applications, but the wide acceptance speaks for itself. The long emphasised focus on the user and the problem domain is finally an integral part of the process and not an 11th hour contractual necessity. From a design point of view, this aspect alone opens up the scope for exploration of truly creative solutions. Shifting from the closed shop research of the problem space towards stakeholder interaction, enables the developers to go beyond delivering 'what the client asked for' to gain the insights which increase the likelihood of discovering innovative and disruptive outcomes.
______________________
but still fragile
But isn't all this bonding and hugging amongst stakeholders just as fragile as other partnerships we form in everyday life. Well, yes it is and either party may shoulder the blame. On the developer side, the integrity of the routine daily progress/problem updates can be compromised for various reasons, including the reliance on interpersonal relationships. However, the client representative role is far more vulnerable to failure. The mantra and reality of the partnership and the sense of engagement will inevitably lead to emphatic attachment to the notion of validity and value in the project without the safety net of ongoing checks and balances from the peers. Further, the client-side stakeholder isn't necessarily representative of the end-user or worse - the prospective user may for now be just a speculative 'persona' profile.
The methodology falls short of full coverage in a number of key scenarios of the product development lifecycle and delivery situations. The Agile stereotype of client – developer relationships, typical of the last century e.g. building business process software, are not universal. The above-mentioned vendor as a commissioning party and the direct to public deployment paradigms are increasingly common in today's market yet neither seems to fit the magical stakeholder interaction scheme. My deliberations on those two examples revealed the most glaring omission. The inherent rush to produce application code, due to the value placed on software as a primary measure of progress, appears to overlook the need to integrate the critical early stages of the process; research, idea generation, design exploration and prototyping.
______________________
what about design?
It is one thing to declare catchy principles like openness to changing requirements and regular adaptation to changing circumstances and yet it is an absolute mistake to embark on code without a design and prototype validation. Under those circumstances, the unexpected manifestation of changes and the necessary adaptations are almost guaranteed and consequentially would compromise the expected delivery timeline, ROI and ultimately result in poorly designed and unmaintainable code. Yes, the core aspect of Agile – iterations and the prescribed code re-factoring may address the latter problem to some degree, but surely not without further compromises of the primary objectives.
I'd like to entertain the notion that Agile methodology can be readily mapped to the design and prototyping stages, just as it has been adapted to other processes. However, besides the strong appeal of the core values and user-centric principles, I fail to see further complementary features. Perhaps it is time for the early stages of development to be specified as additional steps extending the Agile iteration methodology at a cost of diminished elegance and simplicity.
______________________
is there a fix?
Many designers agree that, the correct way to accommodate design in Agile is to define “an initial phase zero that takes a long-term and holistic view of the project needs before moving into agile process” [Bernard C. Summers S., Dynamic Prototyping with Sketchflow in Expression Blend]. A common approach, in real-life application, is to embellish Agile with attributes of a familiar or industry recognised process, for example, see “Kanban Development Oversimplified” or “How Scrum Induced Sub-Optimization Kills Productivity (And How To Fix It With Kanban)”. However, none of those exaples cover the User Centric Design model. Unfortunately, all attempts at pimping up Agile with 'process' simply water down and often compromise its core principles and create a patchwork of less appealing prescriptions rather than a crisp well defined methodology.
No comments:
Post a Comment