Are you struggling to reap the much-hyped benefits of Agile?

Listening to Ciar??n Hanway and Ian Johnson's webinar 'Becoming Agile Building better, delivering sooner' (a recording of which can be found here) it made me reflect on a number of my experiences working in both agile, waterfall and hybrid environments, and the common challenges that organisations from all sectors and sizes run into. At Kainos, we genuinely strive to make ourselves redundant in every engagement, be it advisory or delivery of a complex software system. We work with clients in both public and private sector organisations to either identify and enable improvements in how digital transformation is delivered, or by accelerating that transformation through the provision of highly experienced teams that embed themselves within these organisations to tackle difficult digital challenges. The true success of our work, however, is measured through our clients' ability to drive continuous improvement long after we've left the building. This can only happen if everyone understands what the aim of agile practices are, and if they are agile, rather than simply doing it. Ciar??n and Ian referenced the brilliant cargo-cult tale from the South Pacific Island of Melanesia in demonstrating this point, and I've seen this pattern of thinking on many occasions in organisations struggling to reap the much-hyped benefits of Agile. The most recurring example I've come across is in the application of ceremonies, a key part of the SCRUM methodology and usually the first thing that an organisation does when it wants to 'go agile'. Starting with the daily stand-up; does the team report to themselves? Do the teams truly self-organise, help to alleviate others' blockers and balance workload across the team? Or do they list the meetings they've attended in the previous day and hope their scrum master won't ask too many questions about the state of their JIRA tickets? At the end of a sprint show and tell; something considered sacrosanct to delivery managers and seniors within the organisation, and a ceremony that be an extremely powerful tool to learn, engage and motivate the team. However, without buy-in and understanding of its true purpose, this ceremony become an overheard in the team's diary, something that they dread coming up at the end of every sprint. An ill-attentive audience, one way communication and too much focus on story-point output are habits that many programmes can fall into. The end of sprint retrospective exemplifies one of the core tenants of the Agile Framework^[1] when done well. But how often are actions from the retrospective actually carried forward? Are new things trialed? Measured? Assessed and adapted? See^[2] for more information on how to run a good retrospective. If ceremonies aren't done right they can actually cause more inefficiency, demotivation and prevent the organisation from moving forward, both from a process and tangible output perspective. Enabling all individuals within your organisation to understand the 'why' over the 'what' is paramount in creating and maintaining this agile culture. It can be quite easy to go into an organisation and identify things that it could do better; it's much harder to self-inspect, adapt and constantly drive positive change. As Ciar??n and Ian reflected, the most organic form of continuous improvement, and true empowerment cannot be taken away- it is inherent in the team and comes from an understanding and buy-in to what the organisation is trying to achieve through its chosen delivery method and work culture. Agile is a destination-less journey, and we ourselves are always learning, adapting and trying new things. Do reach out though if any of these examples strike a familiar note, or if you'd like to further explore how to accelerate digital transformation within your business. And a final gentle nudge in the direction of the webinar- it covers a huge range of topics in just over half an hour and has hopefully generated some interesting debate and conversation. [1] http://agilemanifesto.org/iso/en/principles.html [2] http://agileforeveryone.com/2013/03/20/17/