The following is an excerpt from a presentation by Fin Goulding, International CIO at Aviva, titled “Flow: Taking Agile Forward.”
You can watch the video of the presentation, which was originally delivered at the 2018 DevOps Enterprise Summit in London.
I’m Fin Goulding, International CIO at Aviva. Our organization is quite large, we’ve got thousands of customers, thousands of engineers, thousands of systems. We’ve got a structure whereby we’ve got CIOs across different regions, and I’m the one that looks after international.
Our organization is also an old organization. We’re in the 300-year mark, and it’s an industry with a lot of challenges. Even our CEO talks about this being a Jurassic industry. I sometimes think to myself, “Why didn’t I just take the blue pill and stay within the .com world?” But the challenge of doing what I do at this scale is interesting and quite fun.
I’m sure, I’ve faced some very similar challenges that you have working in the world of agile.
- Lots of complexity
- Working in silos
- A suboptimal culture
- Legacy systems (Do you have archeologists or architects?)
- Technical debt
- Security challenges, which are effective everything that we do at the moment.
- Plus, there’s a pressure to deliver digital transformation.
If you have all those issues, you’re not alone. I can assure you, there are a lot of companies in this situation. What we need is business agility coupled with technical agility. What I’m seeing is we’re pretty good at tech agility, but we need to broaden this out a bit to our colleagues who are ‘non-technicians’.
Today I’d like to share with you about my career, and all the things that I’ve done, but I’m also wanting to share about taking agile forward. Because in my opinion, agile is dead. Now, that might be a little bit controversial, but some of the founding fathers of agile are also in the same situation, where we’re it’s Agile, with a big A, that is getting a bad name, rather than being agile.
Agile is not a thing you buy.
It really is a thing that you are, or at least, that’s the way it should be, but it’s losing its way. The idea is that we need to resuscitate and take it forward. I think agile today has become a bit of a rigid methodology, instead of a philosophy. That’s something that needs to be looked at, but I think there’s hope. That hope is what I call Flow, which is really a minimalist agile framework. A lot of people talk about ‘flow’ at the moment, flow efficiency, flow in the way that they’re building software, but I’m talking about something a bit more end to end.
So what is Flow?
What I’ve done is try to extend agile and all the different elements of the ways that teams work, to bring in executives and customers.
The framework itself, at its core, has:
- An adaptive portfolio
- Lean software development
- Continuous deployment
- Customer feedback loops
Which all support the flow of work and make it as efficient as possible.
It’s also powered by extreme transparency. I love post-it notes, I like to see them all over our organization, so, they’re on the walls everywhere.
Speaking of walls, we have lots of walls within our Flow. What’s interesting is when you start visualizing your Flow, you can see where there are things that should be changed.
For us, we feed in customer segmentation, business strategy. We follow that all the way down through some pull mechanisms, taking work from the very highest level, with execs, all the way down to continuous deployment.
These product or project walls drive great social interaction, which I like. I’m a big fan of stand-ups, people getting together, discussing how to improve what we’re doing.
1 — It starts with that adaptive PMO.
Unfortunately, sometimes PMOs are inflexible and a bit ineffective. Sometimes they’re tied to an end date, which is sometimes not a real end date. You’ll also find that they’re not really great fans of test and learn and prefer projects over products. Which means one of the challenges in this, is how do you change it?
We came up with what we call The Great Wall of Business, essentially aligning the strategic projects to the correct business outcomes. Effectively it’s a big, big wall with all the projects on it which our organization plans to deliver at some point, from ideas through the backlog, Inception, etc.
All these initial columns, that are marked as “the business” can stay there for as long as you want. You don’t pull the project in to start working on it until you have people for it. In other words, it can go on forever. If you want to pull that in to start work on and you haven’t got the resources, then you need more, or if it’s something needs to be prioritized or stopped.
It’s a very simple idea, but the idea here is visualizing the work for executives, getting them to come to stand-ups, and getting them to be part of the actual ceremonies.
We also have these lanes down at the bottom, labeled ‘pause’ and ‘do not resuscitate,’ projects that you killed. A lot of projects get killed by execs quite early in this stage, because they say, “Why the hell are we doing this?” But we don’t normally see it because it’s hidden away in a report.
You can also use the wall for other actual events, in terms of reviews, working with other teams to see what’s going on, capacity planning, etc.
The nice thing about Flow is that whilst I put this together last year, the team has changed it to fit them. There’s not a prescriptive framework. It allows for the team to co-design and collaborate.
They’ve added in some extra columns along the way. They decided they want to see more visibility around what projects are going towards keeping the lights on. What will continue to happen is that it will change again, and I really celebrate that.
But I like that there is a use of real English here, taking out from agile some of the words which switch people off. Understanding, value, these are great words, and they should be celebrated.
2 & 3 — Now, let’s look at Kanban From a lean software point of view.
With the evolution of methodologies, what I’ve been seeing is that what we’re trying to do is determine how quickly we can see the value we’re getting. You can see from the older methods, it takes a really long time.
I’m also, not really a fan of Scrum. I call it ‘mini-waterfall.’ I say, maybe it’s wagile at best, but these two or three-week iterations delivers code too slowly. Hence, I like good old Kanban.
Kanban is a very simple way of working, from my perspective. What I say within Flow, if something better comes along, we’ll just get rid of this and we’ll use that instead, since it’s not prescribed at all.
It’s just another pull system, but I enjoy the way that pull brings work into the teams at any level. The big advantage with it is that it can limit the work in progress. That’s key. When you get to that point where you’re jammed up with too much work, you cannot get anything done. So limiting the work in progress is very, very important.
But what I’m obsessed with the key metrics. I know there are lots of other metrics out there, but the ones I really care about are lead time and cycle time. Where this comes from, the minute a task is created to the minute it’s delivered is your lead time. The minute it’s given to somebody to do the work and then it’s delivered, is your cycle time.
The shorter these are, the better. Some companies have cycle times measured in months, which is kind of scary. It means they’re always contact switching, which is not great.
What you’re looking for is the wait time, where something is blocked. I think this is where DevOps came from, where one team was doing some work, gave it to another, and it sat in a queue and they didn’t get around to it. So killing that wait time is fantastic, and getting your cycle time down as small as possible is also great. Some companies are getting it done within two days. Even smaller. I’ve heard of some companies doing a cycle time within a day, which is quite impressive.
Also, what you’re doing there is delivering value in very small deployments. The key here is delivering things quite quickly increases the value, and reduces the risk. These deployments that take weeks and weeks and weeks, is a risky thing to do. When you are delivering in small batches, you can start to see the value quite quickly. You can see what’s happening with your proposition, ‘Maybe we should not maybe carry on. Maybe we should pivot.’
Another thing is that, of the things that you build 20% of the functionality you build is used by 80% of the customers. So why not focus on that 20% instead of everything else?
One way to do this is to start thinking about value-based decision-making.
Let’s say you have a project with say 10 requirements, you can deliver the most valuable features in the dark, followed by what’s required to switch it on. What do you do then? Do you need it to continue on, or should you move the team onto something else?
When you understand the value of what you’re building and you can prioritize it that way, you will stop doing low priority stuff, but you do need that analysis. You can start delivering value and not quantity. Quantity is not great.
4— Now from a DevOps point of view.
I started to get involved in 2009 when I first heard about the DevOps Days. I thought it was fantastic. The smaller organizations I worked with, like lastminute.com for instance, had an easier time in implementing some of these things. It gets to be much harder as you get to be a bigger organization. In fact, at Paddy Power, it was pretty tough. But what’s interesting, if you go and look at LinkedIn, you’ll see all those people with DevOps profiles now. So I’m quite pleased that eventually, they saw the light.
Ultimately, I think it’s a mindset, not necessarily a set of tools, but a way of working with teams together. And I think this Venn diagram, which shows how these teams overlap and work together, is really powerful.
I haven’t seen anything better than this, to be honest with you.
But, why is it difficult to do this on an enterprise level?
It’s one of those questions that perplexes me. Maybe it’s because you’ve got too many ticket systems. I was having a debate about this the other day. Is the ultimate having no ticket systems, where teams are working together, where there are no inefficient handoffs? But you really find are some companies have four, five, six ticket systems, and that’s where information or projects get stuck.
There’s also a difference in work styles, as you probably know, developers tend to be more change happy, while operations teams are more change-averse. We know that. When you try and bring the teams together, you end up having endless negotiations.
Plus you also get leaders that don’t understand DevOps. So, change within large organizations can be quite slow. There’s nothing new there. Adopting things like this does take time.
This is one of my favorite slides.
It shows where I think DevOps is, in terms of enterprise adoption. Enterprise organizations kind of say ‘no, no, no, no….’ until the very last minute, and they go, “Oh, I think I need one of those DevOps things. Can we go out and get them?” I think that’s where we are, within DevOps at the moment. We’re out here, where enterprise IT needs these work practices.
From my perspective, just get over yourself. DevOps is common sense. There’s nothing else to worry about. That’s all it is, just common sense.
5 — Continuous deployment is also part of this framework.
I like the fact that it really does speed things along when you start to break work down into smaller units, if you’re using a pipeline technology and infrastructure as code, with all that automation, etc. Breaking that work down into frequent, small, reversible changes, whilst anticipating failure is one of the most important things.
While also considering software engineering for quality. Building the test into what you’re building as a deliverable. If you’re working in small batches, you don’t need to do merging, code branching. Feed the mainline as soon as you can. What happens then is you can scale. It’s tricky because the work breakdown needs to be small, but it can be done.
Another one of the sneaky things you can do is put in the code itself, switches, to see whether it was used or not. This is kind of handy if you’ve got a product manager that requesting too much stuff that is never used. It becomes technical debt. So why not show that this code is never exercised, we need to rip it out?
We need teams that can focus, then, on real technical debt, real, major technical debt. That’s taking systems of record, some of the older systems, hollowing them out, and bringing actual functionality and code much higher up the stack.
With infrastructure as code and continuous engineering, as I call it, you get all this wonderful stuff like patching, with every single deploy. Which is fantastic. Big organizations spend a lot of time going back and patching. So I’m a big fan of deploying your code and building the service at the same time because all the technology around it gets even better once it’s all in the cloud.
6 — Customer feedback loops
Customers are definitely changing. I think that’s why agile is so important because we need to be able to explore new opportunities really quickly. Bringing customers in to talk to teams is a fantastic thing to do. In a customer lab, not focus groups, not any of that marketing stuff, just bringing customers in to talk with the people that build solutions.
I think it’s important, also, to focus on that customer experience because I think having a great brand, being good at UI, being fantastic at UX is all great, but it’s the customer experience piece that I think a lot of organizations are missing out on.
I’m a big fan of design thinking, or design sprinting as well. Like, doing quick iterations to see if a concept is going to work with customers, without launching a big product, I think that’s a great thing to do. For example, show them the same website with three skins. You talk to the customers, “Which one do you prefer?” It’s quite straightforward, build it with them.
Responding to customer feedback when something goes wrong is also very important. We have a wall for that.
The wall has, for instance, a backlog of issues which have come from social media or from contact centers. What you can do is prioritize those complaints or those issues and start to feed them through. In the end, what you want to do, is let the customer know. Which is great. Some members of our team who fix stuff call the customers back to tell them we fixed it. Which is quite impressive. While some things have to go back to being projects because they’re very big.
But, we need to address the culture.
This is all great, but there are still some things which impact delivery. That happens to be people. You kind of need to address the culture. That’s one of the key things that I try to focus on. It’s really more like hacking the culture. You have to do this to be able to move organizations along and be a little bit brave yourself.
But, culture change within an organization is tricky. A lot of the companies focus on the practices, the toolsets, and the processes. I think that’s quite easy.
Then when you mix in values and principles, it gets a little bit harder. Ultimately, if you get to the point where you can get mindset change, the true learning or un-learning organization, it’s fantastic. If you can unlearn the ways that you’ve done things, to do things in another way, in other words, if you can stop doing the stupid stuff. Start doing the good stuff. It is another holy grail.
But changing mindsets is very tough, very, very tough. In fact, it can be even worse when it comes to leaders. I find what happens a lot of the times is that leaders don’t understand what technical people are doing, and they’re too scared to admit it sometimes. Taking the time to tell a story and involving leaders in what you’re up to is a good thing. I think what leaders should be doing is just removing blockers, helping the team to be successful. That’s all they need to do. Because in my opinion, leaders don’t build systems. Our teams do. That’s our job.
Try and help our teams to act like a start-up.
Everybody together, collaborating, talking, working. it’s not about foosball and baristas, and all that kind of stuff. It’s about having a collaborative organization that works together, breaking down some of the silos, removing some toxic people who really don’t want this to be successful. If you look at it, a disengaged leader has a very wide sphere of influence. These are the people that do need to move on and do the best work of their career somewhere else. I think it’s because, from my point of view, that digital transformation comes via cultural transformation. That’s the big change.
What I do in my company is I have this thing called the Ministry of Silly Walks. I meet with about 10 to 12 employees every four to six weeks. I say to them, “What do we do that’s stupid? What’s on your mind? Tell me what’s going on.” I think I’ve met everybody on the team maybe twice now. It tends to disrupt the hierarchy a little bit, and it does promote improvement. You should really invest in the people that you have but also invest in yourself. Have a student mindset. Go to meetups. Attend webinars. Go to conferences. Start blogging. The blogging bit is important. I blog a lot and it tells my team what I’m interested in, what I care about, where I want us to go. It’s much easier to get that message out.
We also have ways of getting feedback from the team, like the “cool wall.”
It’s like a method for people to put on that what they think is not great at the moment and things that they would like us to do.
For example, on the “uncool side” there might be things like ‘the showers are not working’ or ‘the cups are cracked,’ right through to on the “cool side” there might be, ‘we want to use some new technology.’The leadership team looks at this once a week, and reviews the feedback from the teams. We’re trying to get people to be very engaged. We want them to care about where we’re going.
I also think HR itself is changing, along with their function. There are new paradigms at the moment, working in different ways of delivering functionality and value. There’s the ‘Gig Economy.’ In fact, no job is really for life anymore.
Talking about jobs, why do we have to be narrowed in what we’re doing? Why can’t we work outside of it, have multiple skills? I’d like to be a CIO, a CTO, and an architect. Why not? On the team, you need people with lots of different skills. People talk about DevOps 2.0 which I think could be like being a Flow team with holistic skillsets, no inefficient handoffs, all working together, building value, enjoying their jobs, happy days.
But most importantly, we need to pivot quickly.
Pivoting quickly is important because, with a team that can fail fast and pivots quickly, it will inevitably build trust. For me, trust is extremely important in a team, because when you’re in an environment where you have low trust and people are not bold and brave, you have a fear culture. When you have an organization where mistakes can be made, very supportively, you foster innovation, which is what we always want. You always hear about organizations saying, “How do we be more innovative?” It comes down to the culture.