Fin Goulding

Our last speaker for the day is Fin Goulding.

As international CIO for Aviva, Fin Goulding oversees thousands of technologists across Europe and India. He was introduced to us by John Smart from Barclays, who is on our programming committee. And if you're familiar with Fin Goulding's work, you know that he has a long history with the lean software development community and the Agile community. And he's known for his provocative statements such as, "Agile is dead."

He's the author of a great book called Flow: A Handbook for Change-Makers, Mavericks, Innovation Activists and Leaders: Digital Transformation Simplified. I asked him to share with us his career journey, but also help us better understand how to get conservative leadership on board and give us advice about how to be effective leaders when we have new ideas and new ways of working in conservative, large enterprises.

Ladies and gentlemen, Mr. Fin Goulding.

All right. Good afternoon, everybody. How are we doing? Almost there. Nearly? Okay.

So yeah, I'm Fin Goulding, international CIO at Aviva, and I'm actually based in Ireland, and I'm from Ireland. And this is the wonderful stadium that you can see there.

Our organization is quite large. Got thousands of customers, thousands of engineers, thousands of systems. And we've got a structure whereby we've got CIOs across different regions. I'm the one that looks after international.

But I've been lucky enough to work for some really great brands in my career. I was in financial services for quite some time, and then I switched across to the dot-com world about 2006 with lastminute.com, Travelocity, and PaddyPower.com as well. And I came back into financial services in the last couple of years. But as I say, I've mostly been doing CTO, CIO-type roles, but also based in Europe, US, and I was in Argentina for three years as well.

So our organization is an old organization, like John's. We're in the 300-year mark as well, and it's an industry with a lot of challenges. And even our CEO talks about this being a Jurassic industry, which is really to kind of stimulate some work that can be done to try and improve things.

But I sometimes think to myself, why didn't I just take the blue pill and stay within the dot-com world? But the challenge of doing what I do at this scale is actually interesting and also quite fun.

Anyway, I love FinTech. That's the profile. It's the LinkedIn picture. There you go. I love FinTech, and that's really because it was named after me, and that's the only reason for it.

But I'm sure, like you guys, face some very similar challenges in the world of Agile, and that's what I'm really going to talk about. Potentially lots of complexity, working in silos, maybe a suboptimal culture, lacking agility. Maybe even this, this kind of deploy, like Scrum design, always backwards, forwards, whatever.

Legacy systems as well. Do you have archaeologists or architects? Technical debt actually is real debt and something that really needs to be repaid.

And also when you look at the way that you operate, there was some conversation about how you work with offshoring. If you're not treating your offshore organization as a partner and giving them something end-to-end, it's really not effective.

We have a security challenge, of course. That's affecting everything that we do at the moment. And of course, there's a fear of disruption in the industry, and that goes across many industries that have been around for a long time. Plus, there's a pressure to deliver digital transformation.

So if you have all those issues, you're not alone. I can assure you there are lots of companies in this situation. What we need is business agility actually coupled with technical agility.

So what I'm seeing is we're pretty good at tech agility, and we're broadening this out a little bit to our colleagues. And I say business because we're all in the business, but it's the people that are non-technicians, shall we say.

So today, I'm talking about my career, all the things that I've done, but I'm also talking about taking Agile forward because in my opinion, we heard Agile is dead.

Now, that might be a little bit controversial to some of you, and I did this in an Agile Lean conference recently, and you could have heard the gasps in the room. But it's not just me. Some of the founding fathers of Agile are also in the same situation where actually it's Agile with a big A that is actually getting a bad name rather than being agile.

So it's really something like, for instance, Agile is not a thing you buy. It really is a thing that you are. 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 do think it's become a bit of a rigid methodology instead of a philosophy, and that's something that needs to be looked at. But I think there's hope, and that hope is what I call flow. Really a minimalist Agile framework.

So a lot of people talk about flow at the moment, flow efficiency, flow in the way that they're actually building software. But I'm talking something a bit more end-to-end.

So what-- Bless you.

So what is flow? Really what we've done is try to extend Agile, and all the different elements of the ways that teams work, to actually bring in executives and customers. So I'm going to show you some of that as we go through the presentation.

The framework itself has at its core an adaptive portfolio, lean software development, Kanban, DevOps, continuous deployment, customer feedback loops. This is all designed to support the flow of work and make it as efficient as possible.

It's also powered by extreme transparency. I love Post-it Notes. There, I've said it. And I love them, and I like to see them all over our organization. They're on the walls everywhere.

And talking of walls, we have lots of walls within our flow. What's interesting is that when you start visualizing your flow, stupid can look stupid. So it's worth doing it to see where there are things that should be changed.

For us, we feed in customer segmentation, say, business strategy. We follow that all the way down through some really what I would call pull mechanisms, actually taking work from the very highest level with execs all the way down to continuous deployment.

Those product or project walls, actually what they do drive is great social interaction, which I like. People getting together. I'm a big fan of stand-ups, all people around discussing how to improve what we're doing.

Let's say it starts with that adaptive PMO. It was great to see that the PMO is dead this morning. And I kind of agree in a funny sort of way that sometimes those PMOs are inflexible and a bit ineffective. There's that kind of thing around being tied to an end date, which is sometimes not a real end date.

And what you also find is that actually they do love red status, not really great fans of test and learn, and prefer projects over products. So it's one of the challenges of this, is actually how do you change it?

So 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 is actually going to be delivering at some point, from ideas through to the backlog, inception, et cetera.

But all these initial columns, you'll see where I've written the business, they can actually stay there for as long as you want. You don't pull the project in to start working on it until you have people to work on it. So 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 it needs to be something else to be prioritized or stopped.

A very simple idea, but the idea here is that it's visualizing the work for executives, getting them to come to stand-ups, getting them to be part of the actual ceremonies, and being part of... This is their work, really.

We also have these lanes down the bottom, which I kind of really like, which is pause and do not resuscitate projects that you kill. A lot of projects get killed by execs quite early in the stage because they kind of say, "Why the hell are we doing that?" Don't normally see it when it's hidden away in a report.

And you can use the wall for other actual events in terms of reviews, working with other teams to see what's going on, capacity planning, et cetera.

But the nice thing about Flow is that whilst I put this together last year, what's happened is the team has actually changed it in the last few weeks. So there's not a prescriptive framework. It allows for the team to co-design and collaborate, and they've added in some extra columns along the way.

They decided they actually want to see more visibility around what projects are going towards keeping the lights on, as opposed to being real change. And what will happen is it will change again, and I really celebrate that. I think it's great.

So you can actually look at it, decide, "Actually, we shouldn't do that anymore." What I like, though, is the use of real English here, taking out from Agile some of the words which actually switch people off. So understanding value, these are great words, and they should be actually celebrated.

Then from a lean software development point of view, I'm going to talk about Kanban a little bit.

With the evolution of methodologies, what I've been seeing is that with some of these, what we're trying to do is how quickly can we actually determine what value we're getting? How quickly can we see from what we build that we're actually going to be delivering for our customers? Is it going to be of value? And you can see from the older methodologies, it took a really long time.

So, and this kind of pulls it for me, I'm not really a fan of Scrum. I kind of call it mini Waterfall, and this doesn't go down very well with a room full of Scrum Masters. But I kind of say, well, maybe it's Wagile at best. These two-week iterations or three-week iterations, it's delivering code too slowly.

Hence, I like good old Kanban. And also, I'm very sorry that some Scrum Masters are not that great. It's a very badly described job. In fact, in some ways, they're ex-project managers, glorified administrators, I'm sorry. Two days certification. That, for me, is like, I'm glad they're not pilots.

They're not technical, some of these guys. And actually, what I want them to do is unblock issues, not report on them. And sometimes the best Scrum Masters are actually from a software development or QA background. But there are some good ones out there, believe me.

The product owners as well, that's a role that can also be very badly defined. They get very obsessed with iterations and actually keeping the team busy, being really obsessed with the backlog and not really seeing technical debt as value, something that can be fixed to improve the way that you work.

And quite often, they don't give enough time for the team to interact with customers and actually get out there, understand what the customer wants, what they need. But some of the best product owners do come from a business analysis background, and actually, they're the ones that can drive the team in the way that we break down work and the way that we deliver stuff.

And so I'm going to stop ranting about that now. Sorry, I do go on a bit about it, but I'm currently a fan of Kanban, so it's a very simple way of working, okay, from my perspective. But what I say within Flow, if something better comes along, we just get rid of this and we use something else. It's not prescribed at all.

Of course, it's just another pull system. I enjoy the way that pull brings work into the teams at any level. And the big thing about it is just limiting the work in progress. That's kind of key. When you get to that point where you're actually jammed up with too much work, you cannot get anything done. So limiting the work in progress is very, very important.

Plus, if you read this sort of information around queuing theories, you can see why the actual traffic on the other side is moving much faster, obviously, and that's how you'll deliver value.

But I'm also obsessed with the key metrics. So I know there are lots of other metrics out there, but the ones I really care about are lead time and cycle time.

So where this comes from, the minute a task is created to the minute it's actually 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 context switching, which is not great. And what you're looking for is 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 didn't actually get round to it. So killing that wait time is fantastic, and getting your cycle time down as small as possible is also great. And some companies are getting it done within two days.

Even smaller, I've heard of some companies doing cycle time within a day, which is quite impressive.

Also, what you're doing there is delivering value in very small deployments, so small batch deployments. The key here is delivering things actually quite quickly increases the value and also reduces the risk. So these deployments that take weeks and weeks and weeks actually is a risky thing to do.

But also delivering in small batches, you can start to see the value quite quickly. You can actually see what's happening with your proposition, and maybe we should not carry on. Maybe we should actually pivot.

The other thing is that of the things that you build, which is quite impressive, so 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 that is to start thinking about value-based decision making. So you have a project with, say, 10 requirements. You could actually deliver the first few features in the dark, the most valuable ones, followed by what's required to switch it on. But do you actually need 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 actually prioritize it that way, you will stop doing low-priority stuff. But you do need to do that analysis. You actually start delivering value and not quantity. Quantity is not great.

Now, from a DevOps point of view, within the overall framework, I started to get involved in it, say, when I first heard in 2009 about the DevOpsDays. I thought it was fantastic, a lot of common sense. And actually, in a smaller organization, with lastminute.com, for instance, a lot easier to actually implement some of these things.

Much harder as you get to bigger organizations. In fact, at Paddy Power, and I think there's some Paddy Power people here, it was pretty tough as well. But what's interesting, if you go and look at LinkedIn, you see all those people with DevOps profiles now. So I'm quite pleased that eventually they saw the light.

I do think it's really a mindset, not necessarily a set of tools, a way of working with teams together, and I still think that the Venn diagram, which shows how these teams overlap and work together, is really, really powerful. I haven't seen anything better than this, to be honest with you.

And of course, you've seen the Puppet Labs reports, which talk about how high-performing organizations are actually just far better.

So why is it difficult to do this on the enterprise level? It's one of those questions that perplexes me. Maybe it's because you've got too many ticket systems. Was having a debate about this the other day. Is the ultimate having no ticket systems, where teams are working together, there's no inefficient handoffs?

But you will find that some companies have four, five, six ticket systems, and that's where you'll find information or projects get stuck. Also, there's a difference in work styles. You probably know that developers tend to be more change happy, and then the operations team are more change averse. But we kind of know all that.

But when you try and bring the teams together, you end up having endless negotiations. And I feel sometimes like I'm Kofi Annan trying to sort out this. Plus, you also get leaders that don't understand DevOps. A bit of a lack of understanding.

Plus, change within large organizations can be quite slow. And there's nothing new there. Adopting things like this does take time.

This is one of my favorite slides. This shows where I think DevOps is in terms of enterprise adoption. So enterprise organizations say, "No, no, no," till the very last minute, and they go, "Oh, actually, I think I need one of those DevOps things. Can we go out and get them?" And I think that's where we are within DevOps at the moment. We're actually out here where actually enterprise IT needs these work practices.

I apologize for the swear word. Should've done that in advance, but anyway.

Anyway, 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.

Continuous deployment is part of the framework also. This is something that you're probably far more technical than me. But I do like the fact that when you start to break work down into small units, once you start to look at how you put your metrics together, if you're using a pipeline technology and infrastructure as code, with all that automation, it really does speed things along.

And breaking that work down into frequent, small, reversible changes whilst anticipating failure is one of the most important things. Plus, software engineering for quality, building the test into what you're actually building as a deliverable.

Plus, if you're working in small batches, you don't need to do merging, code branching. Feed the mainline as soon as you can, getting it all back into the mainline. And what happens then is you can scale. That's tricky because the work breakdown needs to be small, but it can be done.

Plus, one of the sneaky things you can do is actually 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's actually requesting too much stuff that is never used. It becomes technical debt.

So why not show that this code was never exercised? We need to rip it out. And we need teams that can focus then on real technical debt, real major technical debt. So 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.

Plus, with infrastructure as code and continuous engineering, as I call it, you get all this wonderful stuff of patching with every single deploy, which is fantastic. Big organizations spend a lot of time going back patching.

So deploying your code and building the service at the same time, I'm a big fan of, because all the technology around it gets even better once it's all in the cloud.

So customer feedback loops. Customers are definitely changing. I think that's why Agile is so important, because we do need to be able to explore new opportunities really, really quickly.

Actually 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 is a great idea.

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 fantastic, but it's the customer experience piece that actually I think a lot of organizations are missing out on.

And we heard about design thinking or design sprinting just a while ago, and I'm a big fan of that as well. So doing quick iterations to see if a concept is going to work with customers without actually launching a big product is a great thing to do.

And this is actually the same website with three skins, and you talk to the customers: which one do you prefer? It's quite straightforward. You actually build it with them.

Plus, responding to customer feedback when something goes wrong is really important. So we have a wall for that. The wall actually has, for instance, a backlog of issues which have come from social media or from contact centers.

And what you can actually do is prioritize those complaints or those issues and start to feed them through, where maybe there's nothing to do in terms of any changes, or you need to feed it back to a particular team to fix something. And at the end, what you want to do is let the customer know, which is great.

And some of our team who actually fix stuff call customers back to tell them we fixed it, which is quite impressive actually. Some things have to go back to being projects because they're very big.

Anyway, so it's all great, isn't it? But there's still some things which impact delivery, and it happens to be people. Not you guys, of course. You're all fantastic here, I can tell from here. I can see it right now.

So you kind of need to address the culture. That's one of the key things that I try to focus on, and it's really more like hacking the culture. And you have to do this to be able to move organizations along and be a little bit brave yourself.

I kind of stole this from the Agile Onion. I had a version called the Agile Onion-- Sorry, the Wine Bottle, which didn't go down very well. So now I'm trying this new version.

But essentially, culture change within an organization is tricky because a lot of companies focus on the practices, the tool sets, and the processes. I actually think that's quite easy. Then when you mix in values and principles, it gets a little bit harder. It does require some cultural change.

But ultimately, if you get to the point where you can get mindset change, a true learning or unlearning organization is fantastic. And I get the unlearning from Barry O'Reilly. There's his new book. Unlearning the ways that you've done things to do things in another way. 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. This is the frozen middle, cruising to retirement, all those sort of issues you may have seen, or perpetuating the corporate immune system.

But the thing is, I find, is a lot of the times is that leaders don't understand what it is that technical people are doing, and they're too scared to admit it sometimes. So taking the time to tell a story and involving leaders in what you're up to is a good thing.

Because I actually think that leaders, what they should be doing, though, 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.

I try and help our teams to act like a startup, everybody together, collaborating, talking, working. Actually, it's not about foosball and baristas, that kind of stuff. It's actually 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.

But if you look at it, a disengaged leader has a very wide sphere of influence. So actually, 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 actually have this thing called the Ministry of Silly Walks. I meet with about 10 to 12 employees every four to six weeks. I just 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 in the team maybe twice now. It tends to disrupt the hierarchy a little bit, and it does promote improvement. And this improvement is something I like, which is also boosted really by learning.

So you should really invest in the people that you have, but also invest in yourself. Have a student mindset, go to meetups, attend webinars, come to conferences like this, start blogging.

The blogging bit's important because what I do is I blog a lot. It tells my team, therefore, what I'm interested in, what I care about, where I want us to go, and it's much easier to get that message out.

Plus, we do have ways of getting feedback from the team. So if you're a Top Gear fan, you'll probably recognize this, the Cool Wall. The Cool Wall is 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, which would be really, really cool.

So on the uncool side might be that the showers are not working or the cups are cracked. Right through to on the cool side might be, well, we want to use some new technology. And this is what the leadership team looks at once a week, 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, and they know where we're going. And this is a slide I stole from a marketing team, and it'll be in the pack.

So I think actually HR itself is actually changing, the people functions. I think we're going to have to. 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, I've kind of had this thing, which is stuff the job description. Why do we have to be narrowed in what we're doing? Why can't we work outside of it, have multiple skills?

I think the Disney guys talked about T-shaped. I've gone a bit farther, like pi-shaped, cone-shaped, whatever. I'd like to be a CIO, CTO, and an architect. Why not? Because in the team, you need people with lots of different skills.

And people talk about DevOps 2.0. I'm wondering whether it's actually being a flow team with holistic skill sets, no inefficient handoffs, all working together, building value, enjoying their jobs, happy days. And also so we can pivot quickly.

Pivoting quickly is important because with a team that actually can do fail fast, pivot quickly, it builds trust. For me, trust is extremely important in a team. The reason being that 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'll foster innovation. So actually, having high trust and bold and brave gives you innovation, which is what we always want. Always hear about organizations saying, "How do we be more innovative?" It comes down to the culture. So be bold and brave.

And don't be like me running the marathon in a pair of pants, but you have to sometimes get out of your comfort zone and tell people how you care.

And one more thing, I actually do a very mean Steve Jobs impersonation, by the way. I need to get some round glasses like that, which once they turn up from Kickstarter, I'll be ready.

What we're looking for within Flow is we're very passionate about what we do. We're trying to find some volunteers to help us road test some classroom training. So it's about, is this something that can be delivered to individuals in a way that makes sense so that they can have this very minimal framework and fill in the parts they need to themselves?

So if you're interested in that, you can actually reach out to me either via LinkedIn or Twitter, feel free.

Plus, we do have a book that's already out, and we've got a second one that came out last Friday. I actually haven't seen it yet. So many people have already got it before me, but the second book, 12 Steps, is out, and there's a promo code on the website if you'd like to get it for the bargain price of $199.

It's a great price, I think. But it's only for the next 24 hours if you use the code DOES18. But the books themselves are very graphical. They're good fun. They're not too technical. They have technical things in them which are explained in a nice consumable way, and I think you'll actually find that it's good fun to be in Flow.

Thank you.