Agile Software Development
The agile approach to software development as a concept, from a brief manifesto of fewer than 70 words published on a simple flat HTML page almost 20 years ago, has in recent years grown into one of the great buzzwords in project and business management. The agile methodology – perhaps better described as an approach or a philosophy, as there is no“standard” agile playbook which will fit all use-case scenarios– has proved its worth across a range of industries, although ithas adapted itself to application in some fields more than inothers. Due to their nature, agile and software developmentwere particularly well-suited to each other from the verybeginning, and it was the world of software development thatgave this descendant of concepts pioneered by industrialdesigners and engineers at Canon, Honda, and Fuji-Xerox itsname.
In software development, the problems to be solved arecomplex and multi-faceted; solutions and therefore productrequirements are likely to be initially unknown andspecifications to change rapidly during a project; incrementalimprovements to a product throughout its development cyclecan be pragmatically useful to the end user; and rapid, oftennear-instant end user feedback is taken for granted.
A tenet of the modern scientific method is that an experiment is successful when it fails. Similarly, two key definitions heard in descriptions of the agile method are that it seeks to create minimum viable products, and to fail fast.
The rapid, iterative development sequences of the agile method – so-called “sprints” of a month or less – and the instant end user feedback of modern software development dictate continual delivery of minimum viable products. The focus is on producing a constant stream of working software.Thus an unsuccessful or unpromising solution can be abandoned at an early stage, and development move ontosketching the next minimally viable prototype product.
Central to agile is an open-minded willingness to experiment based on a readiness – more, an imperative – to fail often and to fail fast, and to move on quickly and easily to a new solution. Meanwhile rapid incorporation of feedback and the fast looping pace of the developmentsequence allow further iterations of potential solutions to be produced and the final specifications and product to be evolved.
Using this approach successfully implies, compared to traditional organizational schemes and workflows, a focus on self-management and self-organization and a horizontally oriented structure. As with the responsive and rapidly iterative development sequence made possible by the combination of instant end user feedback loops and rapid development cycles, the flow of information and communication within the organization and the degree of flexibility granted team members is equally critical to the success of this approach.
Does the agile method and the importance it places on speed, seamless communication, and sharing of information necessarily imply keeping development teams and processes in-house? Must a software development house intent on implementing agile forego the many advantages – savings in costs and overheads, broadened skill sets and knowledge bases – of outsourcing?
Central to the agile method is, of course, agility. The central practical problem in implementing a “distributed agile” approach is essentially integrating inhouse teams and outsourcing partners – perhaps particularly when partners are based offshore - and integrating their work cultures, workflow, processes, and methods into an agile approach.
The advantages of this approach are many, but may require something of a paradigm shift for collaborators who are accustomed to a more “traditional” approach to development and outsourcing, and to a more vertically oriented organization. Indeed, the familiar modular structure of a traditional outsourced business relationship could be deployed to “destratify” the structure of a new offshore partner to integrate them with a “distributed agile” approach
Founder and CEO of Softaims