We thought with this article we might give our perspective on the move to “Agile”. Many organisations are adopting Agile approaches e.g. SCRUM or using elements of Agile in seeking to deliver better products in quicker timeframes in conjunction with a focus on strong customer engagement.
While some organizations are seeking to be truly Agile, i.e. software components are ready for production deployment at the end of a sprint, some are using elements of Agile in a build phase combined with an integration phase, often where legacy systems are involved. This is variously called Agile with Integration, Hybrid Agile, Spiral Agile. The Agile phase requires Agile Testing, the integration phase follows more traditional V Model discipline. Leading organisations are also evolving the agile approach into DevOps where continuous development and continuous testing flow into continuous deployment.
While Agile is seen as the latest “innovation” in models for software development and delivery, Agile development combines many elements that have been used in the past in RAD, DSDM etc.
These include:
It’s not straightforward
As with each successive software development innovation, Agile is not without its share of “war stories”. Stories and experiences vary, successes are balanced by experiences of chaotic process, poor communication, fraught decision making, poor quality, elongated overall delivery timelines and other problems.
Each of the innovations, RAD, CASE, DSDM etc. were seen as the “silver bullet” for software production and delivery problems addressing users real needs. As with other innovations, adopting Agile, particularly on a large scale basis is a major change for an overall organisation, not just the IT department. It has been suggested that it is easier for new organisations building web enabled software to adopt Agile than established organisations with legacy software and established practices. However, as greater numbers adopt agile practices and continue the journey into DevOps the cumulative experience built up results in greater success and even more widespread adoption. In today’s world is there any other way?
Still, a move to Agile needs to be considered carefully, and the degree and timing of the move may vary organisation to organisation. The rationale for the move to agile practices needs to be understood - development, process, management, and/or schedule problems will not be magically solved by “going Agile.” Teams who have grown up in a culture that is fundamentally different than Agile will not find it easy to “go Agile.”
Other views suggest that while the underlying philosophy and elements of Agile are sound some of the principles lead to dysfunctional behaviour e.g. using working software as a measure of progress leads to a rush by developers to write code leading to poor quality, defect backlogs and frequent rewriting of code.
These comments are balanced by success stories and indeed supporters of Agile suggest that virtually all of the problems, complaints, and negative experiences that companies attempting to use Agile have reported are due not to a problem with Agile itself, but with a failure to understand the approach and its limitations.
Is Agile “different”?
The major changes in consumer purchasing, mass customisation and the acceleration of web enabled everything have had a profound effect on all aspects of IT. Historically, when people shopped physically in stores cycle times and decisions were different. A waterfall-style production process seemed not only appropriate but also effective.
Fast forward to the present where online purchasing is ubiquitous, constant connectivity is the norm and software, particularly mobile apps, are constantly changing and rapidly available. Production processes had to become iterative, lightweight, context-dependent, and more responsive than ever to customer feedback. To many, there is no such thing as a software project which will be “finished”. Just look at the rapidity of app updates to fix bugs you didn’t even know were there—pushed to your device, from the cloud, by an Agile team that is used to refining new iterations of their software almost daily.
In parallel a generation has grown up with the internet and mobile connectivity and view software in a different light. They self-serve, are tech “savvy” and have high expectations in terms of service, quality, availability and personalisation. These people are also in increasing numbers in the general workforce, not just in IT. This is having an effect on the business IT relationship.
IT has always evolved, but what has happened in recent years is different. Mobility, cloud computing, social media and other 'consumerization' technologies have combined to change the very nature of IT in the enterprise.
Agile may not be different in that it uses many elements of other innovations but the project environment for going Agile is different due to the changes in technology and in the abilities and expectations of business users and customers.
Agile is also not different in that the problems experienced by some people delivering Agile projects are often put down to a failure to understand the approach and its limitations. This has been the experience with previous “innovations” – they are a significant change for an organisation and need to be considered as such and planned accordingly. If going Agile is considered as a change project then it is influenced by the same failure and success factors as other change initiatives. Sponsorship, budget, clarity on scope (proof of concept, pilot project, full roll out across organisation), broad involvement and commitment, calibre of resources involved, training and expertise etc. Agile is not a one size fits all approach, a good understanding of organisation capability and readiness and a proper strategy and plan are required.
“Once again, the survey responses indicate that organization cultural issues remain the leading impediments to adopting and scaling agile. General resistance to change, inadequate management support and sponsorship, and organizational culture that is at odds with agile values rank as the top three challenges.” (Version One State of Agile Report 2019)
However, there are many signs suggesting that despite its potential drawbacks, the rapid adoption and popularization of Agile is largely based on the pragmatic demands placed on software production and information technology in the early 21st century. When everything is changing so fast, some agility is simply required.
Trying to make sense of it all
So where does all that leave us? Agile is attractive, agility is needed and the environment (people and technology) is ready and receptive to it. Going fully Agile may not the best approach for everything – there is a danger - “if you only have a hammer then everything is treated as a nail”. Equally, if Agile is considered as a flexible and adaptive approach then consideration has to be given as how, where and when it is flexed.
However, Agile has already won a lot of the battle for mainstream acceptance, so it cannot be ignored when both business and IT see value in it and want to go “Agile”. The key to successful Agile implementation is to treat it as a change and look first at the organisational context for going Agile and, depending on the scale of Agile implementation, to understand the capability and readiness of the organisation to implement its vision of Agile.
Firstly, what is the driving force for Agile/DevOps in the organisation? Is it a senior business person who has heard Agile will deliver his needs and address all his/her frustrations with IT? Is it a new CIO who wants to implement it to regenerate IT and has promised the business a better service? Is it a group of IT development people frustrated with more traditional approaches and unhappy business people who believe it will free them from the grind of waterfall?
Equally, is the approach to implementing Agile to do a proof of concept project with a small team and “experience” your way to Agile or at the other extreme to bring in lots of consultants and seek to go “big bang” Agile across the organisation.
If we consider Agile as a change project then it needs sponsorship, business case, resourcing, funding etc. As an IT enabled change it affects both business and IT and both need to understand the impacts, commitment, training etc. It will also focus both parties on agreeing what will constitute success and in what timeframe. In all likelihood, there is an expectation that it will be implemented with no impact on current portfolio delivery timelines. So, no pressure then!
In understanding the drivers for the change to Agile, the scope and scale of what we are attempting, and the capability and readiness of the organisation we are more likely to construct a change project that will yield the necessary “quick wins” on the road to a successful organisational change to Agile. At the end of the day all parties want to achieve successful quality change, whether that is moving to Agile, or delivering the real IT enabled business changes needed for the organisation to thrive and prosper using Agile constructs.