This is a guest post written for the Computer Weekly Developer Network blog by Johan Karlsson in his capacity as senior consultant at Perforce Software.
Perforce is known for its version control software, web-based repository management, developer collaboration tools, application lifecycle management and Agile planning software.
Karlsson contends that the spotlight on Agile is now widening to include ‘large-scale Agile’.
The problem, says Karlsson, is that while the ‘iterate often and embrace change early’ tenets of Agile have often worked well at a team level to boost innovation, motivation and delivery times, many still struggle to scale and create lasting change beyond team or department-level.
Karlsson writes as follows
Scaling the proven benefits of Agile beyond team-level brings many hurdles. First up is defining exactly what is meant by ‘large-scale’ Agile. For some organisations, that might be expanded Agile processes to software development teams in different departments or locations. For others, it can mean taking Agile beyond software, to collaborate with teams in non-technical job functions.
There are many hurdles to overcome here… as we look carefully at Agile outside software (and its methodology, principles and wider implementation) and ask how can Agile techniques be taken beyond the team-level?
This may be difficult if practices such as Scrum – intended for software engineering – are also implemented in hardware, marketing or operations teams. This is where DevOps has a role to play, helping teams to have visibility into everyone’s progress, while still using different practices.
As soon as a large-scale Agile transformation hits a roadblock, executives are too fast to press ‘stop’ and revert to earlier practices. Any new methodology is going to have teething problems. Rather than abandoning Agile, it is better to learn from other organisations, or use experienced Agile coaches and consultants to help as change agents.
We also need to ask whether legacy tools adaptable to large-scale Agile – for instance, to support distributed development and new job functions – or is it time to change?
It is harder for traditional companies to adopt Agile compared to those born in the digital age. Some of these organisations have turned to SAFe (the Scaled Agile Framework), because it provides the structure management seeks.
SAFe has its benefits, but it is important to remember that such frameworks provide a starting point, not the destination.
We see that many companies use SAFe as a good starting point but then discover that not everything SAFe prescribes is useful for them.
No two situations are identical, so it is vital to customise Agile to fit the context. That might mean hybrid approaches, such as using both Scrum and Kanban side-by-side. Another popular combination is to combine plan-driven approaches with adaptive practices.
By definition, Agile is not prescriptive — and that applies even more so to large-scale than for a single team. As a result, organisations need to decide what large-scale Agile means to them, then find the right tools, customised processes and remain open to continuous review and improvement.
That is important, because Agile is, without doubt, one of the most rapidly evolving areas of software development, particularly in large-scale Agile. What works now may need to be adapted in the future. Yes, that means a constant challenge, but after all, that is a fundamental part of Agile: embracing change and being flexible, whether team-level or enterprise-wide.