Enfuse Guide: Agile and Why it Matters
What is it?
Agile is an iterative approach and mindset to delivering change dating back to late 1990s/ early 2000s. Agile was originally intended for software development, with a view to addressing perceived limitations of waterfall approaches to development. It has been highly successful in this area, and is now the norm for most development teams.
In recent years Agile's success with software development has led to an increasing use of Agile for the delivery of other changes, not just software. Another recent trend is incorporating Agile thinking and approaches into the how companies operate end to end, with Agile models such as that of Spotify becoming highly popular.
The Agile Manifesto
In 2001 fourteen (numbers vary dependent on your source of information) prominent software developers came together and defined the Agile Manifesto. This has became the cornerstone of what is Agile. The Manifesto is underpinned by 12 guiding principles.
Agile Frameworks
Specific process frameworks (some say methodologies) have arisen over time to embody Agile thinking and provide further guidance on how to put it into practice. These include the likes of Scrum, Extreme Programming and Kanban. Scrum is the most common approach used by companies, particularly those first trialling Agile.
With the advent of large organisations wanting to use Agile at scale (i.e. not just a few teams but for 50+ developer environments) further frameworks have arisen for scaling Agile, such as SAFe and LESS. Many Agile practitioners are wary of scaled Agile frameworks, as these can be seen to implement controls and other overheads which seemingly conflict with the intentions behind Agile. The jury is still out in this regard.
As already noted, Agile is being used beyond software development. This isn’t too surprising, as Agile thinking shares much of its past with management concepts such as Lean and much of the Manifesto can be applied to all aspects of business delivery and operations, not just software development. Agile has also been heavily used by Silicon Valley tech companies for whom software development was almost all that they did, so within those companies it has naturally been expanded to cover their entire way of doing business. One tech giant of note is Spotify who have publicly shared the thinking behind their scaled Agile model. This has been very popular, with many non-tech organisations such as ING embracing and adapting the model which seen as ideal for achieving the responsiveness and customer focus needed for today’s digital age.
Why you should care
Agile is increasingly become the norm for delivering change. Whilst many organisations have struggled to initially get the full benefits from Agile, most of them are now at the point of having learnt what works and doesn’t work for them and so are starting to see the right results. Whilst Agile is not a silver bullet for success, studies do suggest that Agile is more effective than waterfall approaches.
Until relatively recently, waterfall projects were the norm. They are characterised by up front planning and requirements gathering, followed by design and then build and eventually release. The issue with waterfall is that projects could take months (even years) to get a design agreed and the build first started – by this time the requirements and / or design are likely to no longer no reflect what is needed as the world has moved on. The customers of the project are also left waiting a long time before they get to see any type of output. Waterfall has also tended to involve notable baggage in the form of excessive governance and bureaucracy - adding undue cost and time to delivery.
In contrast to waterfall, Agile seeks to deliver in small increments, delivering outputs early to the customers of the project. This addresses two needs – the need for early change and value delivered, and the need to sense check that the requirements are right. This last need is perhaps the most important. Agile is about continual improvement, so with each iteration learning can occur on what is really needed, enabling a better outcome overall.
Beyond being a delivery approach, Agile is also a way of thinking with value and customer focus at its core. It is increasingly seen as more of a business model than simply a delivery model, with companies looking to embrace Agile to give them competitive advantage in an increasingly digital world. With backing from the likes of McKinsey and Bain as the model for the future it certainly appears to be the right answer for most forward thinking companies wanting to compete.
Watch points with Agile
Agile is not easy to do well. It is not a silver bullet. When done well, it can achieve remarkable results, but even then it needs the right environment. Below are some watch points to beware of when adopting Agile.
Not always the right horse for some courses: There are many Agile evangelists out there who overstate the value of Agile. Too commonly when Agile works it is because Agile is great, and when it fails it is because you weren’t doing Agile well. The truth is that Agile is good for some things, and not others. For changes with specific known outcomes and deliveryagi deadlines, waterfall feels instinctively better.For changes where the requirements are unclear and early and frequent releases of outputs are needed, Agile is best.
Agile at Scale a challenge: Getting Agile to work in a team is very different to getting it to work at an enterprise wide level. Challenges in how to balance cross dependencies, high number of releases and managing the technical complexities of continuous delivery are high. Frameworks like SAFe and LESS exist to help guide large organisations on how to scale Agile, but these are difficult to apply without losing much of the benefits which Agile purports to bring. Careful planning and trialling are needed to scale Agile in the right way for each organisation
Too much change: Agile should be highly productive, producing a constant stream of change. Whilst this sounds great, in practice many organisations struggle to absorb the level of the change involved. It’s like a conveyer belt running too fast for the packing crew at the end of the line. This has led some organisations to actually delay and bundle up changes from Agile teams so that they can better manage the delivery and acceptance of those changes
Culture clash: Agile teams are typically autonomous, empowered to make their own decisions.This isn’t a new idea, particularly in military circles. For example, Napoleon’s decentralised military approach enabled him to conquer much of Europe. However, in many organisations a command and control culture persists where it is the people at the top who make the plans and the decisions, and those below simply follow. In such organisations it can be very difficult to pass responsibilities from management to those in the Agile teams, especially if it potentially can mean making certain layers of management obsolete.
Agile jigsaw piece doesn’t fit: A sensible starting point with Agile is to use it for particular business areas or teams, and let the rest of the organisation carryon as before. This makes sense but does cause issues in terms of integration. For example, finance departments not accustomed to Agile will struggle with the idea of funding Agile teams who whom there are not detailed requirements and timescales outlined up front. In IT, IT operations teams struggle with Agile software development teams who want to release little and often as this poses challenges to how the manage and protect the live systems (as any change to these is perceived as a risk and in need of extensive change). Acknowledgement of these potential conflicts should be made up front, with something like an AgileGuiding Coalition group being formed of senior people to support the Agile teams and help smooth the way when needed.
Documentation is still needed: The manifesto states that it values working software over comprehensive documentation. This does NOT mean that documentation is not needed. There are too many horror stories from the early Agile adoption days of people using Agile as a way of cutting corners and avoiding necessary documentation. Keep documentation to a minimum, but also be clear on what is still needed.
Planning is still needed: If anything, Agile involves more planning than waterfall delivery. If you look at the Scrum approach, there is extensive planning for every sprint, with every feature carefully planned out for delivery. It is a different level and type of planning to Waterfall, but planning still occurs. Watch out for Agile teams with no roadmaps or sense of how their delivery will be prioritised - these are needed!
