Recently we invited 5 speakers to address 110 attendees on the topic; If agile concepts are simple, why is it so difficult to implement? Here is a brief summary and access to video content.
In general most of our speakers addressed this topic with war stories all of which illustrated that most organisations need to get out of their own way if they are to be agile.
Overcoming individual and collective scepticism about what Agility and DevOps actually are were called out as initial blockers. Misalignment with supporting business functions, such as finance or procurement slows down progress but is not fatal. By finding a common language with the business (numbers and money work well) business functions such as marketing or sales can be brought on the journey.
Historical business decisions to outsource parts of the SDLC make it more difficult to get an end to end picture. You can, however, bring Agility and DevOps practices to the parts of the SDLC that are within your autonomy.
Legacy systems are often cited as DevOps inhibitors, but most speakers were keen to point out that this is more reflective of a state of mind than any technical reason. Legacy systems come with legacy process and this is more often the blocker, but it is important that individuals come to realise this for themselves rather than have it used as a stick to beat people with.
We tried to create a sharing atmosphere at this event by providing name badges with just a Christian name. This meant individuals could solicit advice or share an opinion without revealing their corporate identity. Feedback from our post event survey was universally positive.
Paul Whelan, Head of Development at FBD
Paul spoke about FBD’s journey since 2016. One of the first surprises for FBD was that their first insurance application, which was built over 22 sprints actually worked. Staying ahead of this skepticism is always a challenge.
Paul continues to push the boundaries of agile and has recently attempted Mob programming where teams of 8 people share one computer. Paul was inspired by JP Morgan to attempt this unique way of working.
Claire Drummond Product Marketing DevOps and Agile at Atlassian
Claire heads up business teams at Atlassian. She spoke about how lack of trust, ownership and process fatigue undermined agility on a project she ran recently. She advocates the use of health monitors to measure trust in teams and these tools are available for download as pdfs or Confluence templates. Ownership for projects can benefit from using the DACI framework. The best way to avoid process fatigue are high quality retrospectives.
Claire recommends a board for projects where the following categories are made available for all to contribute ‘ I like (what do you like about the way you practice agile) I wish (what do you want to improve about your agile practice) and What if? (If anything was possible what would you like to see in your agile practice?)
Paddy Benson CTO at Utmost
Paddy spoke on the theme of ownership, as he outlined why shifting left on your definition of done means culture change. This means, handing engineers more autonomy and treating success and failure as learning opportunities. Celebrate success and analyse failures.
Paddy illustrated his points with case studies at organisations, where his teams have implemented an ever improving ‘edition’ of DevOps, that amounted to shifting further and further left.
In particular where dev and ops were not aligned on definition of done, the ensuing lack of trust led to unplanned downtime that significantly impacted customer quality. Paddy can see how sales tasks are now becoming part of the ongoing evolution of done as APM tools reflect ongoing customer usage patterns.
John Hurley, CTO at Ryanair
John spoke about how empowered teams can sometimes lose direction. However a visit to Paddy Benson (when he was at Groupon), led to the use of Operational Readiness dashboards at Ryanair and John learned that providing transparency between teams helped all parties to remain focussed.
More recently, Ryanair Labs commenced a new way of starting projects by having a 6-week Inception sprint. The self organising team within this new way of working, decided to remove test and release thereby saving 4.5 days from their 30 allocated days. However, quality and deployment cadence took a step backwards – this was in effect a waterfall. The real issue behind the 4.5 days was manual testing which need to be automated.
In addition, pipelines needed to be provided to delivery teams on a self-service basis.
John put in place a new team and set up a project called 45. This team set its own goals and stated they will reduce the 4.5 days to 4.5 hours and then 4.5 minutes. Empowered teams work if you let them set their own goals.
Alan Molloy, Incoming CIO at a large Insurance Company
Alan likened his various employers to aging trees. Older larger organisations were less flexible and required significantly more effort to bend! War stories revealed companies that had to be cajoled into deploying software that was completed early and started earning money before its target ship date.
Another company’s marketing department had built 87 wire frames for their new mobile application and sought a ship date from IT. By asking customers in a nearby Starbucks for their thoughts (on video) about the wire-frames, the Agile team was able to bring a focus on MVP and the end user. The first 4 or 5 frames were then tested with end users, and by abandoning the 87 wire-frames money was saved until the team could articulate features and an associated value.
Alan encouraged attendees to ship more often, forecast with data, minimise WIP, be excellent (with all software artefacts not just code) and concentrate value.
Dean Caron, Program Manager Engineering Excellence from Unum
Dean spoke about how his organisation has used Comparative Agility to deliver metrical data on speed and quality to guide best DevOps practices. Dean used the State of DevOps report for industry standards on speed and quality.
Dean emphasised the need to ensure the cause and effect of DevOps practices such as automation were aligned. This approach allows teams to use data to drive their own change. Summary data for management (and drill down if required). Detail for the teams themselves.
Speed metrics are change frequency, lead time, change fail rate and MTTR. Quality metrics are security compliance, unit test code coverage and performance risk. Continuous improvement starts with the first measurements – start early advised Dean.
Subscribe here to gain access to the video recording of these talks, including panel session.