Increased throughput, reduced code complexity, less production incidents, shorter deployment cycles and higher happiness in teams; these are some of the benefits that the agile transformation at Barclays has delivered. Within the first year of the transformation, which is based on the Disciplined Agile approach, more than 800 teams adopted agile making this one of the largest agile implementations.
InfoQ interviewed Jonathan Smart, Agility Capability Lead across Barclays, and Ian Dugmore, product owner for the central agile adoption team, about the agile transformation at Barclays. We asked them why Barclays decided to implement agile, how they selected which agile framework to use, how targets where impacted by agile, how they dealt with different ways in which teams are doing agile, what Barclays has done to increase their agility, and the benefits that agile has brought to Barclays.
InfoQ: Why did the agile transformation start at Barclays- what led up to it?
Jonathan Smart: Barclays is over 325 years old with a long history of innovation. There is a recognition that an agile and lean approach is a better way of working than the historical waterfall approach. As with most large firms, there were islands of agile excellence. The agile transformation at Barclays which started at the beginning of last year is holistic, it’s not just a technology thing. It’s taking the islands of agile and joining them up, removing the impedance mismatch. It’s everyone involved in the value stream, from concept to cash. It’s focused on delighting customers first and foremost (from which shareholder value will follow).
Within the first year, we have the equivalent of 800+ teams working with an agile approach, who weren’t 12 months previously. We’re pleased with the scale and pace of adoption and at the same time we are well aware that this is just the beginning, that lasting culture change takes years.
InfoQ: You considered several agile scaling frameworks. Which one did you select, and why?
Smart: We looked at Disciplined Agile, SAFe and LeSS. Scaling across a large enterprise is not scaling more of the same. It is not a cookie-cutter pattern. Scaling across a large heterogeneous enterprise is about breadth, diversity and complexity. We have 130,000 employees, thousands of internal teams and many different business lines. For us, our approach is based on Disciplined Agile (DA) as it is not one-size-fits-all, it is a goal-based, risk & value focused framework and is enterprise aware. It allows practices to vary as the context differs, with recommendations. In a large organisation, in the real world, there are many different combinations of product:team cardinality, teams who are iteration based or flow based, variations in team Shu Ha Ri level and so on, which DA supports. The Barclays Agile Change Lifecycle, our Roles (for example, AO role) and our approaches are based on DA. The thought leadership from Scott and Mark provides a frame of reference and guidance for the organisation.
SAFe and LeSS are patterns that suit certain contexts and there is a lot to learn from both. Under the umbrella of DA, teams are welcome to adopt a SAFe pattern or a LeSS pattern, if that suits their context. In my opinion I would not apply either as a blanket across a large enterprise, as they don’t or are not intended to cater to the broad diversity of a large organisation. We like the enterprise awareness of DA and the not-one-size-fits-all approach. Teams are empowered to experiment, learn and adopt the practices that work best for their unique context, within our agile control framework which we need in a heavily regulated industry.
InfoQ: With agile, teams become more important. How did this impact targets that are used to manage results?
Ian Dugmore: For Agile to be adopted in a large part of the organization you need to change both the funding and measurement of results, for change initiatives. Most of the tracking and measurement in traditional waterfall style delivery is driven by the long lead time between project initiation and delivery. Changing to an iterative delivery methodology where success is primarily measured by the delivery of a working product with tangible results negates this.
InfoQ: Can you share some of your learnings from using targets when you transitioned to agile?
Dugmore: For adoption itself, the vital thing here is maintaining the separation between management targets and team measures. It is vital to have targets to help senior leaders understand the vision for agile adoption in the organization. There are very different things that need to be done if you are targeting 90% of teams using agile practices from 10% of teams doing so. Teams need to be trusted to measure themselves and for these measures to be rolled up, where it is applicable to do so. Keeping the two things separated is hard but not impossible.
It is also worth noting that teams who are just beginning their agile journey need some guidance to what practices they should implement first. Experienced agile practitioners understand that the practices you use are dependent on your context; however, for beginners this just leaves them feeling lost and confused. We use a 4 level scale for teams to measure themselves against where level 1 is more prescriptive and practice based, moving towards output/outcome measures as teams move to levels 3 and 4. These levels are a lagging indicator of agility and they aggregate things like reduced lead time, increased quality, automation, technical excellence and team structure. It is important that these are not framed as the reason as to why agile is being adopted. The reason why is separate, the levels are waypoints on the agility journey, useful for planning ahead (e.g. for test automation, continuous integration, limiting WIP, ways of working, and so on). The most important measures are the context-specific business outcomes, which are aligned to agile business cases.
InfoQ: Within a larger organization there often are different ways and levels of doing agile. How do you deal with this?
Smart: As previously mentioned, we use Disciplined Agile as the guiderails which are not one size fits all. Based on DA we have defined an Agile Change Lifecycle which works with either an iteration or flow based approach to work. As mentioned above, we’ve also defined Agility Levels 1 to 4, where 1 is beginner and 4 is expert which apply at the team or product level. The agility levels are an aggregate lagging indicator. They cover a range of topics, such as concept to cash, quality, team structure, technical excellence practices, continuous delivery, and so on. This allows us to understand which teams are beginning their agility journey and which teams are exhibiting agility without thinking about it and are able to coach others. We can also compare metrics such as lead time, quality, engagement with teams agility levels and sure enough the data is positively correlated. In addition, via a self-assessment questionnaire, the agility levels help to provide an idea to teams of what good looks like, what they should focus on next. In a heavily regulated industry, it is very important that it’s agile with control. We’ve done a lot of work in this space, moving the control conversations to be early and often, not at the end as is often the case with a waterfall approach.
It is also important that we are taking a holistic agile approach, not islands of agile, aiming for the whole value stream to support business agility.
InfoQ: Can you give examples of things that Barclays has done to increase agility?
Smart: We have a range of enabler themes in progress. For example, we’ve changed the workspace in a number of locations, making the physical environment more collaborative and conducive to teams working together. We’ve provided extensive training and support including agile coaching. We’re also taking a holistic approach and are doing a lot of work to lean the end-to-end value stream, including business, technology, operations and all supporting functions.
InfoQ: What are the benefits that agile had brought to Barclays?
Smart: From a sample set of data, we’ve seen a 300% increase in throughput (average stories done per month per app). This is a combination of more work getting finished and more smaller stories, both of which are desirable. From mining static code analysis data we’ve seen code complexity drop by 50% on average across 80+ applications and test code coverage increase by 50%. This is evident in the production incident data where we can see a positive correlation with those areas who deploy all their applications with a cadence of at least every 0-4 weeks having the lowest level of production incidents on average per app.
More than half of all strategic applications now deploy business value to production at least every 0-4 weeks consistently for the past 6 months.
And from a survey we can see that happiness is higher for those teams who are working with an agile approach. In addition to this we have case studies where teams have articulated their beneficial business outcomes, often being first to market with a new product and then able to pivot quickly based on fast feedback.
Jonathan Smart and Ian Dugmore presented Culture Eats Principles for Breakfast at QCon London 2016 where they spoke about the agile transformation at Barclays, what they have done and how they’ve done it, not only in IT but beyond IT.