By: Steven Winter, Columnist, International Director
Projects in general and information-technology (IT) projects in particular are often associated with some level of complexity. And the bigger the project, the higher the probability that it will be more complex. To deal with that complexity, project managers often use iterative and flexible planning approaches so that they can incorporate any new information or knowledge into the plan as it unfolds. The process involves continuous learning and plan improvement. In software-development projects, the demand is even greater for such high frequency of iterations and change, while still being able to meet delivery deadlines. Hence, the agile-development methodology was introduced.
The agile manifesto
The independent software engineers who devised the agile methodology were focused on getting things done, rather than on time-consuming managerial and administrative activities. The agile manifesto acknowledges the value of structure but gives more emphasis to other elements— such as individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.
“Just do it” attitude
The term agile is an umbrella term for multiple approaches that can be used to tackle project challenges. Those approaches include: Scrum, Dynamic Systems Development Method (DSDM), Feature-Driven Development (FDD), Agile Unified Process (AUP), Extreme Programming (XP) and others. Both agile methodology and Kanban methodology are considered to be lean methodologies (there is intersection between agile and Kanban), which means that they both attempt to eliminate waste and generate optimal value from project activities. The main promise of agile is added efficiency, enabling the realization of desired outcomes faster.
Managers can benefit from the flexibility of agile methodology. They can choose from many lifecycles for their projects. The available lifecycles are predictive, iterative, incremental and agile. In software-development projects, requirements can change quickly, and there is a need for a suitable lifecycle, even if it’s a hybrid at times.
The right approach depends on the degree of change and the frequency of delivery. With more change, there is a need for more iterations; and with high frequency of delivery, the project lifecycle tends to be incremental. Predictive lifecycle is more suitable for a low degree of change and low frequency of delivery.
Agile comes with a lot of tools and approaches designed specifically to help technology projects achieve rapid progress, and it has indeed succeeded in many cases.
When agile goes right.
Companies such as Lego, Cisco and British Telecom have managed to realize the benefits of applying agile methodology for large-scale projects. Lego managed to get a collaboration of self-organized teams at the program level, using the Scaled Agile Framework to deliver it. The results were better communication through face-to-face meetings, and more accurate estimates. Cisco switched from the traditional methodology to the Scaled Agile Framework. The results included fewer defects by 40 percent and better performance in terms of time. British Telecom also transitioned from the traditional methodology to agile upon the arrival of its new chief executive officer in 2004. The results were that the delivery cycle was shortened from 12 months to 90 days, and the team’s morale and motivation improved.
When agile goes wrong.
Despite its many promised advantages and the flexibility it offers, agile methodology has drawn a lot of criticism. What’s more, critics of agile methodology are rather vehement about their stance. They believe that agile development is an “IT fad” and that implementing agile can lead to a sharp drop in a company’s share price.
A survey conducted by technology-services firm 6Point6 in the UK found that more than 50 percent of chief information officers (CIOs) no longer can defend agile development. CIOs believe that two out of every six projects carried out by using the agile methodology are likely to fail. The IT consultancy estimates that around £37 billion could have been wasted during the year from May 2017 to May 2018 on failed agile IT projects. This estimate focuses only on projects that failed completely and does not include the ones that failed partially. Including those could substantially increase the potential waste.
There are many reasons for failure. One of the main reasons is the geographical distribution of teams. Another reason is lack of documentation, given the emphasis on working software. Lack of documentation leads to handover problems and a chaotic transition of the product from one team to another. Lack of planning also contributes to failure, which leads to lack of knowledge about progress towards goals.
The 33-percent failure rate is alarming, and the causes for failure signify that agile development falls short in some areas. The answer, according to the study, is to have an IT architect. This person can fill the large gap that currently exists in the agile methodology.
Potential for conflict
Another challenge that comes with agile projects is the preparation of legal contracts. Contractual agreements typically entail two parties with assigned obligations to both. The software developers are assigned clear descriptions and specifications of the deliverables they should come up with at the end of the period. Yet, this is difficult to accomplish with projects in which requirements are dynamic and continuously unfolding. Also, it is the perfect environment to foster conflict between contracting parties, given that obligations are not clearly set from the beginning.
Conclusion
Agile is a catchy term. But there is serious criticism of agile-development methodology, despite the advantages it offers. Agile is a less linear method than the traditional (aka waterfall) approach, and it can offer efficiency gains if applied among self-driven teams. For example, identifying the feature that makes the biggest difference when every 100 features are introduced at once can be challenging, and agile can help in such cases. But agile projects are delicate, and they can go awry with the slightest deviation.
Agile methodology can be good to use with highly innovative projects that are not similar to previous projects that the organization undertook, and projects with high uncertainty that require iteration by necessity. This method is lean enough to improve the odds of success for such projects. But there remain risks related to lack of documentation and poor negotiations. Those risks may not materialize until late in the project, but they are worth considering and addressing proactively in early stages. Eventually, a balance needs to be struck between linear and non-linear methodologies to get the benefits of both and prevent the potential risks.