Business people often complain that IT projects take too long and deliver results that fall short of requirements. In their defence, developers point out that business people are poor at explaining their needs and change their mind too much.
Some believe such conflict is a consequence of the traditional ‘waterfall’ approach to software development, e.g. where the process sequentially moves through requirements gathering, business analysis, systems design, coding and testing. Just like in a relay race where there is no going back once the baton has been passed without destroying the team’s performance, revisiting earlier phases in a waterfall development can be costly and disruptive.
So you plan and document everything, strictly manage activity, and enforce rigorous change control along the way. The unwritten mantra is that change is the enemy and should be challenged hard wherever it is requested.
The snag, of course, is that things often do change legitimately over the course of a project, especially if the elapsed time is measured in months or years. This applies to requirements, constraints, technology, surrounding systems, and so on. Furthermore, once you show a stakeholder or user something running, it often sparks new ideas and requirements that they hadn’t previously thought of. If the first time they see working software is in the lead up to ‘go live’, with all the remaining time allocated to testing and remediation, this is far from ideal.
Those challenging the traditional waterfall approach assert that it should not be necessary to design, build and test everything before delivering anything. This in turn leads to the notion of ‘agile development’, characterised by rapid and frequent delivery based on a more collaborative approach. Advocates claim that this reduces time to value, copes better with change, and increases the chances of business needs being met.
In 2001, a number of these advocates came together to define the ‘Agile Manifesto’, within which it was stated that the group valued:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Many seasoned IT professionals might consider a project set up on this basis as an accident waiting to happen. The group, however, was careful to point out “while there is value in the items on the right, we value the items on the left more”. The manifesto should therefore not be interpreted as advocating an ill-disciplined ‘make it all up as you go along’ approach.
In practice, the term ‘agile development’ actually refers to a collection of well-defined methodologies such as DSDM, SCRUM, Adaptive Software Development, Extreme Programming, and others. Agile methods are grouped together because they are all based on the more incremental and iterative approach to designing and building software. In an agile development project, the overall objectives are still well-defined, but the way in which they will ultimately be met is deliberately kept fluid in case something changes over time. Work is conducted in discrete units of activity, each leading to the delivery of a set of fully working and tested features and functionality that can be reviewed, accepted and actually used by the business.
In contrast to traditional development organisations that group specialists such as analysts, architects, programmers and testers into separate functional units, agile development teams are generally small (less than 10 members), multi-functional, and self-contained. The principle of ‘self-organisation’ with flat team structures and continuous communication is an important ingredient in the mix. The idea is that in a close-knit group with a discrete common goal (i.e. meeting the objectives of the next software release), people will naturally figure out who needs to do what between themselves then collaborate to achieve the result.
Those who have been around the block a few times might be sceptical of this romantic notion. For many (if not most) of the developers working in mainstream IT departments, the work they do is a job, not a vocation. As in any profession, you have a spectrum of capability and attitude, with highly talented, motivated and naturally collaborative people at one end of the scale, and ‘nine to fivers’ with mediocre skills and an uncooperative mind-set at the other. While agile advocates claim the approach brings out the best in people, the success rate will be heavily influenced in reality by the make-up of teams and the environment in which they operate.
We must also be clear that adoption of the agile approach is not a licence to dispense with core skills and disciplines. Project management, coding standards, code documentation, configuration management and comprehensive testing are all still important. So too are horizontal functions that cut across software development projects such as business analysis, data modelling, technical architecture definition, and overall IT governance.
The reality is that agile methods can be useful for handling small to medium scope development projects (or smaller discrete parts of larger projects), where requirements are particularly dynamic or hard to pin down, and the right mix of people can be brought together. But before jumping to agile, it is important to recognise that many of the problems that arise during waterfall projects are not actually to do with the methodology per se, but a lack of discipline, control and effective communication. It may therefore be better to focus on fixing this first.
Considering agile development in the broader context, it can be a useful complement to traditional methods and a potential way of working around stakeholder reluctance to fund long-running monolithic developments. It is not, however, a magic bullet to neutralise all development woes.
CLICK HERE TO VIEW ORIGINAL PUBLISHED ON
Dale is a co-founder of Freeform Dynamics, and today runs the company. As part of this, he oversees the organisation’s industry coverage and research agenda, which tracks technology trends and developments, along with IT-related buying behaviour among mainstream enterprises, SMBs and public sector organisations.
Have You Read This?
From Barcode Scanning to Smart Data Capture
Beyond the Barcode: Smart Data Capture
The Evolving Role of Converged Infrastructure in Modern IT
Evaluating the Potential of Hyper-Converged Storage
Kubernetes as an enterprise multi-cloud enabler
A CX perspective on the Contact Centre
Automation of SAP Master Data Management
Tackling the software skills crunch