Flow : The new world of business agility - Fin Goulding at FlowCon France 2019

[00:00:01] Hi everybody. So I'm Finn Golding, um, I'm going to talk to you a little bit about, um, business agility, um, and the, and the wider world that we see ourselves in right now in organizations. Um, a little bit about myself, I've been a CIO or a CTO in many big branded companies, um, worked in different parts of the world in, um, in Europe, of course, and, uh, and the Americas. Uh, very much working in financial services and then in dot-coms and all sorts of industries. And now I'm in my own startup, which is The Flow Academy. We specialize in fixing transformations, starting transformations, we do workshops, we help executives. We also do this thing which is called a craft beer chat. So you buy the beer, you can chat to me, and I'll give you some advice and that's all it costs is just a beer. Um, in my experience, I see many organizations have very similar challenges. They there's lots of complexity, um, we see external threats, of course, particularly on the security side. Um, also seeing with uh, organizations that have large regulatory demands, particularly in some of the banking insurance world. Um, organizational silos are still the norm in large companies and number of perhaps sort of inefficient offshore models and the way that teams are set up. Um, maybe too many projects or too much product development in play. Um, also, you know, work not delivering value. You see this quite a lot actually, so lots of things that which are delivered no value associated with it. Legacy systems are still out there, some systems from the 70s still working. Um, I did annoy some people recently, some architects by calling them archaeologists, but I mean really, you do need a lot of of knowledge to manage some of these older systems. Anyway, then you'll get ever increasing technical debt, which I consider to be real debt. At some point you have to pay that, you can't get away from it. And you also see organizations with slow delivery, which is uh, one of the biggest issues that management are always complaining about. Also outages, problems caused by speeding up the delivery, so you get initial problems and then that gets you unhappy customers. There's a fear of disruption in a lot of organizations right now. Um, and there's pressure to deliver digital transformation or agile transformation or some form of transformation. Anyway, if that all sounds familiar to you, or some of those things sound familiar, then you're not alone at all, at all. Um, the answer is usually let's get agile. That's it. We'll we'll do agile and everything will be fine. We'll sort all this stuff out. And I get into trouble because I kind of say that agile is dead, or agile as we know it is dead. Um, and now this does really annoy a number of the the kind of like people that are invested heavily in some of these methodologies and processes. But, you know, at first it does sort of like annoy you, but, you know, what I say is that, you know, it's becoming more of a rigid methodology rather than a philosophy, something that allows continual improvement and change. Um, it's usually confined to IT, and this comes from Barry O'Reilly's book, um, where you get this kind of agile really in the middle of an organization and everything else is still, uh, you know, in the old-fashioned way of working. And what you end up with that is really I call it fake agile, and it's not really agile at all. It can't be if it's not really end-to-end. And then I've I get into trouble also for talking about some of the complex frameworks which are out there. Uh for me, I call this a Ponzi scheme driven by consultants where there's no finishing line. Really, companies that invest in some of these large-scale agile frameworks will spend a lot of money, really not actually delivering anything faster. And I also find that the teams working within those frameworks are not that happy. So it's it's a bit of a shame and I wish there was a way that we could change that. I don't know what it will be, but, you know, maybe in the future we'll find something. Um, so agile really is a thing, you know, that uh, you don't buy, it's a thing that you are. It's quite straightforward, shouldn't be any more than that, you know? So there is hope to this world and and for us, um, in my little organization, we talk about flow really as a toolkit for business agility. Um, initially we talked about a framework, but then everybody hates frameworks these days because frameworks tend to be a little bit rigid. And like the last talk, we actually like picking things from best practices and inventing stuff ourselves to create a toolkit that can really help you in your organization. So my definition of business agility is really around discovering the most valuable things to do, building them quickly and visibly, and delivering them really with with quality. I mean, that really is a thing via great social interactions. So, you know, this is a way I think that companies should be adopting business agility, but it's getting a little bit confused by all different types of techniques. What you need to do is ensure that work flows efficiently across the entire business, just not in the technology team on its own. It's everything. So what we tried to do is extend flow out a little bit more to involve executives and customers with some of the traditional teams that you'd see in a in a technology space. And that really is something that can be missing in a number of companies. And the focus really is on the flow of work, so really having an adaptive portfolio of work. Using some of the lean software development techniques and Kanban of course, but and continuous delivery, but bringing in more customer feedback loops and actually involving customers in some of the innovation or people within organizations to come up with innovation targeted towards customers. That's how we see it. So we have lots of visualizations within, um, the what what's the wider framework for flow, starting with customer innovation. I'll talk a little bit about that, how you start to gather information and feed that into your your flow of work. We have an executive portfolio wall, which is essentially basically a big Kanban for execs. We don't call it that, but it's that's what it is. Visualizing the work that you have and then splitting out into different types of walls depending on the types of work that you're doing. Some of it's around customer journeys or feature development, some of it's around projects, projects still exist, but they ought to be done in an agile way. And carving out time for test and learn and for the future of business. And then moving in if you are building software is to use, you know, team Kanban approach, DevOps, etc. And that also, the reason I like Kanban so much is that we're able to split this out into a number of teams, go away from actually creating sprints. Go away from, you know, code branching and stuff like that and delivering small batches very fast straight through into automated pipelines, but I'm not going to go too much into that today. That's all the sort of stuff that we do. Anyway, there are many things that break the flow, unfortunately. That's quite a shame. The things that break the flow, number one for me is upstream value. Or it's really looking at what causes waste, why aren't we delivering value? And what you'll see is that a lot of companies don't actually look at the work that they've got in terms of is this really connected to our strategy, is this really our product and development portfolio really targeted at the people we're serving? And sometimes it isn't. When you look at that work, there's some stuff in there which is really quite a lot of waste. Some of it's from poor decision-making, some of it's from CEOs that have pet projects. Or execs that come up with these ideas which actually you spend a lot of time building and they don't go anywhere. The work's not related to customers, we see that quite often. And as I said, a lack of focus on value discovery. But the thing is that you do need to serve customers, but you need to analyze markets to find out where those customers are. That's the key. I mean, obviously your portfolio of work will have strategic things, you'll have tactical work, but also it really should be looking at where are the markets where these where our future customers could be. So we use a technique around market segmentation, a little bit what I'd say a little bit more ahead of what other organizations are doing. But it's using a lot of information, a lot of statistics, a lot of information that's in the outside world, going through ideation and data analytics. But actually doing this in a very, very agile way with with teams to try and come up with a a look at what work could be defined and brought forward, um, to actually become something valuable and groundbreaking hopefully for your organization. So for instance, this is what looks like uh from an insurance perspective, a customer innovation wall. Lots of new markets that they may not be focused on. In this industry, they're focused on very traditional markets, very much aged demographics. But there are lots of new markets appearing and then you can target your products and services at these new micro segments or markets themselves. Um, this is another one for an imaging company, actually trying to help them move out of their offline world into an online world and looking at where their customers in the future might be. A lot of that's obviously online, um, and actually quite fascinating when you do this with a team of people, which is this is one that we did, uh, last month in the US, it really is very collaborative and people have great ideas. We just guide them along towards coming up with these ideas and solutions, but it's very, very interactive and it's very powerful when you come up with some great ideas that you hadn't had before you went into the room.
[00:09:25] So we use this kind of model here where we we say, well, what does customer success look like? Can you define what it looks like? And do you already have some assets in your company? There are things that that that were created that have gone quiet, people don't actually, maybe they were a prototype that didn't actually get developed quite further, but those assets could be used and brought to bear and not actually build something new. But what you're trying to do is target your innovation at these markets and these customers and you're looking for ecosystem opportunities, so a wider world of other organizations which are adjacent plugging into you. So, what is an ecosystem? Well, this is Airbnb, it's quite quite straightforward. Where you have room guests and room hosts, but lots of businesses have grown up around it. So lots of organizations that helping you to market your room, actually how to make more money from it, um, training you in that particular way of working. There are companies which will do remote key management, open the doors for you. Lots of businesses have grown up around the outside. So if you can create an ecosystem around your company, you can really extend your value. That's what it's all about. It's spending some time in value discovery to ensure the teams are working on the right things. We often find that teams are not working on the right things. Okay. Things that break the flow, number two, project management offices, PMOs. Um, sometimes they can be very inflexible and ineffective in my opinion. This is where the PMO managers walk out of the room by the way, like they usually leave here. And they don't really challenge end dates. They kind of look at this from a perspective of, you know, we love red status, we love calling that out, we hate test and learn, we really prefer projects over product development. And that's something that's not very good in an agile world. It's not very adaptive. So we definitely need something better, more collaborative, much more adaptive. Something with extreme transparency that you can't hide away in reports that people don't read. From that perspective, we like to get people to bring out their dead. So you're probably wondering what the hell this is. This is actually bringing out every single thing that the company is working on, every single project initiative and putting it on a wall so you can see what it looks like. So that's our executive portfolio wall. We call it executive portfolio wall because we want executives to come. So if it's called executives, they say, oh, that must be for me, so I'm going to come to this. If you call it a Kanban wall, they say that's for those techy guys, they don't care about that stuff. And we we really just visualize all the work that's going on in an organization and we try and get it into a structure whereby we can take take it through some sort of challenge process. You can have a number of swim lanes, which might be split out by different initiatives in your organization. Um, this is an actual one from an insurance company and it has a lot of stuff on it. This is after they cleaned it up. But initially they had about 500 projects and only 100 people. So it's quite easy to say to the executives, there are 500 things you're asking the team to do and you only have this 100 people. Something has to stop. So you have to take stuff off the wall. That's what it's all, that's what it's about, really. There's another smaller one, so they don't have to be the same, they're slightly different swim lanes, slightly different way of focusing on. This one has a lot more focus on transformation and regulatory work, you give them their own lanes. But the same principle applies, let's get everything on the wall, let's look at what's there, can we account for it in terms of customer or strategy or keeping the lights on? And therefore it's a valid piece of work. Okay, it gets to stay on the wall. Otherwise it gets taken off and thrown away. Even risks and issues in an adaptive way can be visualized and actually dealt with in real time. Again, this is from a from a bank whereby they visualize the risks and issues and a photograph of this wall is accepted by audit teams because it's time-stamped. It's not rocket science. It really is a case of looking at this from a perspective of can I visualize these risks and issues and can I have a conversation with important people around that wall and make decisions. That's why I like about walls. They are really a venue for business teams and technical teams to interact. And if you can get a corridor, it's even better. That sort of like people have to walk through it all the time and they see this stuff. I've even known executives and CEOs late at night coming along and looking at everything on the wall, what's that? And actually taking stuff off the wall when they disagree with it. They never do that in reports, but they do it in a visual way for some reason. Okay, the thing, number three, that breaks the flow, methodologies. Sorry, I apologize about this. I've stopped talking about waterfall and Scrum and stuff like that in terms of how inefficient they could be. So I'm not a big fan of Scrum. I've said that quite often, but I talk about it now in terms of getting value. So, actually, some of them these methodologies just take longer to get value out to customers. So, this actually resonates much better with leadership teams. Because what I said before is, really, agility needs to be end-to-end. And we often you'll see stuff as isolated agile practices just in software development and and testing, upstream is really annual, you know, quite quite traditional in its methods. And downstream, of course, the the DevOps challenge, which some organizations still haven't implemented that kind of way of working, we hand over to another group to deploy. And there are too many methods. I think it was mentioned earlier. Somebody called this the Agile industrial complex, maybe 40 plus. Even even flow is considered to be one of those. I wouldn't say it is, but anyway. Um, 40 of these things is just way too much. I just think from my point of view, flow, I always say currently prefers Kanban because if something better comes along, I think it should be replaced.
[00:15:28] If if something is going to be more productive, more fun to use, more logical, it should replace what we are using right now within flow. But at the moment, I love it because I love the limiting work in progress.
[00:15:39] I love using pull mechanisms. Technical teams really should do this more often. But if you do it in a portfolio way, you can say to your business colleagues, we can't accept this work in. We don't have the people. So using this whip limit kind of concept at a portfolio level is quite something else.
[00:15:55] I mean, we do it as teams building software. But try and do it at a larger scale. It makes a lot more sense. And it does allow business teams to actually change their mind before you actually start working. So anything that's not been pulled into the technology team can actually be replaced by something else of more importance.
[00:16:19] And there are metrics I think which are key. So flow efficiency is important and particularly around lead time, cycle time and wait time. These are things that should be measured. And actually to allow you to make your teams be consistent, not necessarily to say they're doing anything bad. I hate this when it's used to say, oh, this person is slow or that team is slow. Well, that's not the that's not really what you should be saying. These teams need some help. I need to give them some resources, I need to give them some education. We're going to make them uniform like everybody else. And killing that wait time is important. The wait time usually happens between silos, between teams. That's why bringing them together is important. So anyway, if you can get your cycle times down to two days, this is the ultimate in my opinion. I think it was said this morning by Elizabeth, small batches, the smaller you can do your work, the better. And this is the beauty of why you need to actually deploy functionality or change in small batches. I apologize for the artwork, PowerPoint and Google Slides are not that great for doing this kind of diagram, but in fact, what it looks what you'll see here is quite obvious, the smaller the work, you're actually reducing the risk. And you're actually getting value much faster. Plus you can see value as well. You actually start seeing it quite quickly, um, as it's hopefully returning on your investment. And some teams have got quite sophisticated around value-based decision-making on features or on requirements. In other words, if you can put a value against every single thing that you're actually working on, you know, you may not go ahead and develop everything that you've been asked to do because there are more valuable things in another project waiting to start. If you use that kind of way of working, it's a little bit advanced, but I've seen some teams do this.
[00:18:07] We actually what you're doing is only building 20% because 80% of your customers are going to actually use it. So you don't need to build the other stuff. So why build all those things, those widgets, those, you know, interesting things that are not going to get you any value back?
[00:18:24] And with those metrics and that feedback, you can get to that situation. Plus I love this, if you're into these small cycle times and it's very uniform, your estimating is really easy. Just count the freaking cards. That's all you need to do. Count the cards and how many people have I got? Okay. I think I stole this actually from, uh, David Anderson, but anyway, it is a quite straightforward thing to do once you get to uniform cycle times. The trouble is I find that when you're looking at the way that people define work, it's not done like that. I mean if you're using stories, some stories are huge, some are really small, very hard to do this kind of estimating, that's why I think it's important. And get delivering value, not quantity. Because quantity is not really going to be moving the dial.
[00:19:13] Okay, number four, things that break the flow. So we're getting more controversial now, now we're talking about people. So people can make stupid decisions, right? I mean that's we've seen that and we're seeing it right now even today. And changing mindsets is really tough. I mean, it really is tough. People don't like talking about emotions, about feelings. This is something that is like, oh, let's keep that under the carpet. Um, what you see is that a lot of companies will adopt the Spotify model, which doesn't exist by the way. I just thought I'd point that out. And it won't change your customer your culture at all. You can't buy culture change. And this is what, the way that they work fits their culture. It's not going to fit everybody else's. It really isn't that easy. What you find is organizations start with a set of processes and tools to try and get a culture change. They write their values and principles down, they put them on the wall. Those 10 things which are values that nobody can remember because 10 is too many. I mean it could be one or two might help. But, um, really starting to unlearn the way you work is pretty key. And if you read Barry O'Reilly's latest book around that, you'll get some pointers because that's what you need to do is change the way of working. just just thought I'd point that out. Um and it won't change your custom your your culture at all. You can't buy a culture change. unless it's what the way that they work fits their culture. It's not going to fit everybody else's.
[00:20:01] It really isn't that easy. What you find is organizations start with a set of processes and tools to try and get a culture change. They write their values and principles down, they put them on the wall. Those 10 things which are values that nobody can remember because 10 is too many, maybe it could be one or two might help. But um, really starting to unlearn the way you work is pretty key. And if you read Barry O'Reilly's latest book around that, you'll get some pointers, because that's what you need to do is change the way of working. leaders and managers can be the worst in this situation. The frozen middle as you've probably heard before, people that are scared to not admit they know something. Uh maybe they're cruising to retirement and resistant to change. And they they have this thing which is the corporate immune system. Any new idea is like, oh no, before you've actually presented it. And that's for me is quite sad.
[00:20:55] And some leaders prefer command and control in their organizations. What that leads to is actually all the power being sucked up to the top, so that you're all all trying to provide information to the leadership, not trying to help and serve customers. So it's all this pyramid of information and reports and control. It's just another Ponzi scheme in my opinion. So what about servant leadership? This is quite derigueur. But the trouble is I'm not sure that's the right expression. I think what it should be is more about team coaches. I actually think that the people that manage teams should be coaches, whatever size of team.
[00:21:33] Actually learning, excuse me, learning coaching skills can really propel your career. I mean and all you need to do is start using open-ended questions. not telling people, just keep asking questions, they'll eventually get there. Coaching is really easy. There's no myth what you're doing is trying to get that information out of the person that already has it. Anyway, but at a minimum what leaders should do is remove blockers for the team. So whatever role you have, that's your job is to help the team keep the flow. Because you know, what happens is leaders don't build the products or systems, the teams do. So that's where the focus needs to be, not in committee meetings, not locked away writing reports, spending all weekend working on your emails. That's just not the right thing to do. And also hire the right people. That's why I always say, interview everybody yourself. Whoever you are, as a CIO or a CTO. I always interview everybody, even if it was 10 or 15 minutes. I didn't need to know what they did. I wanted to know what they were like. And what you need to do is move toxic people on. Anybody toxic in your team or your organization will disrupt the flow. And this is the mistake I've made in the past, not taking action in this space, giving people six or seven chances. It's one of those things you really sometimes have to do for the betterment of them.
[00:22:51] And a toxic leader can have a much wider sphere of influence, which is a challenge. So again, this is sort of the thing that can disrupt the flow. That goes kind of behaviors are really not acceptable. I like to connect with my teams. I always suggest a good way of working. You're all too young to know Monty Python, but anyway, this is something that I normally do. I sit down with teams and say to them, what do we do which is stupid in our organization? And you get great feedback because we do stupid things in organizations and you need to get that feedback that's not filtered through the hierarchy.
[00:23:23] And what you're looking for is to promote improvement in your own space.
[00:23:28] And I advocate forming flow teams. For me, this is like, I'd say this is probably the most important thing and also one of the most hardest things to do in an organization. Really having full holistic teams, no inefficient handoffs, going beyond the DevOps or SRE, actually having people in the teams who are not necessarily technical, dedicated to those teams, structured in that way. And some people are calling this DevOps 2.0. Um, for me, I've kind of been in this situation where I've been arguing with Jean Kim about this, but in a in a nice way, because this thing is that you know, DevOps needs to get wider, needs to actually include more roles. And I'm not sure that 2.0 is the right expression. I obviously I think flow teams is better. But you know, I've been an advocate of this kind of way of working for 10 years. It really is a, you know, a mindset and a way of working. It's not a set of tools or roles DevOps. If you have a DevOps team, it's really just an ops team. I'm sorry for all of you in the DevOps team right now, but that's all you're doing. You're not developing stuff. And if you've got a team that actually is developing new features and functionalities, a holistic team, then you have a flow team. Now, what you can do is also people always say to me, well, I can't put all the people in the teams. I understand that, but you can allocate people. And I use this W to show, you've got three core teams, predominantly dev, test, and ops. But what you're doing is supporting them with people from the wider organization. Not just business analysts or prep people, but security, UI UX, marketing, risk, finance, even HR. HR needs to be a part of this. And they're often missing and off the pitch as far as I'm concerned.
[00:25:11] So flow teams are really like a collection of startups with people from the entire business. But you don't have to have the barista, you know, the foosball and the free food that you'll find in startups, um, or even some of the larger organizations that give you free food to keep you working as many hours as possible. But really what you're looking to is have holistic teams essentially. But I said, where is HR in all of this? Where are they when you need them, you know? Um, what I'm seeing is there are very much a whole bunch of missing roles in HR these days. And really around most of them are coaching type roles, coaching for performance, coaching for leadership. Coaching mindsets, cultural champions, people in their organization that understand Agile. If Agile is a way of working, why isn't the expertise in an HR team? It's going to baffle me. Why is it always in the tech team? It doesn't make sense. And in some companies HR has just become really administration, which is a shame. I've got a lot of good friends who work in that discipline, who are not allowed to do some of these things. They actually learn how to do organizational design, they even learn about organizational psychology, but they're never put into practice.
[00:26:17] Why do you need those roles? Well, I think traditional hierarchies are very outdated. The structures, we all talk about silos, but no one does anything about it.
[00:26:25] Um, we are working in new paradigms. the way that people work together, you know, peer programming, etcetera. No job is for life anymore. So there's something about change that's happening. And I think jobs have become too constrained. Like when I was a developer back in the day, I would do everything. I would do design, development, test, deploy, screw it up, get told off. That was me. So I kind of again advise companies to work outside of the job description.
[00:26:55] You know, I don't know if you've seen this T-shaped, pie-shaped, comb-shaped. Essentially, adding more specialist skills to yourself, is at the core of flow. Why should you just do one thing? If you can do more, great. And a startup has that or a smaller organization. People don't get hung up on the job description. They'll actually pitch in and do the work. I've sat next to CEOs in for instance in lastminute.com, who are doing testing, user acceptance testing. Because we're trying to get this out the door. It's not saying I'm the CEO and we haven't got any testers, okay, what are we going to do? Just roll up your sleeves and get involved.
[00:27:32] Okay, number five. Now I will annoy a few people with some of this, I'm afraid, so. Um, number five, things that break the flow.
[00:27:40] Adding more platforms really does increase complexity. I'm seeing this more and more and more, even in transformations, people are adding more platforms, not taking things away. decommissioning or technical minimalism, I call it, isn't common. People don't throw stuff away, they keep it, they hoard it. We should hire this lady, you know, in in an IT space, because this is what's happening.
[00:28:06] And then people start to look at replatforming their legacy or heritage systems. I prefer heritage because a lot of investments gone into these things. They're not actually broken.
[00:28:15] They just taking, they're just a little bit taking a little bit longer to get value out of them, but they they can. But when you start replatforming, then you end up paralyzing a company with that thing for two or three years while you're trying to change. So keep explaining to people, stop working in your systems of record. You know, start hollowing them out, start lifting functionality up. into a middle space or even to the front end. And where systems are not core like finance or HR or email, use a SaaS platform. You know, really outsource that stuff to a software as a service.
[00:28:51] Get focused on your systems of engagement. That's really where you're going to make your your mark and stop doing the systems of record work.
[00:29:00] Anyway, tools, this is the other thing. So I don't think tools are necessarily an issue. I think it's how they're used and and and really the way that people use them. So Slack, teams, email and Jira are just curing systems. They break the flow. In fact, I would love an organization that didn't use any of these. That don't don't get me wrong. I've I've actually sat down with the Slack of CEO and had a conversation with with the CEO Slack and stuff like that. But yeah, the idea around some of these tools is that I'm I'm concerned that information gets blocked or queued. And anytime something is stuck in a weight space, then it actually is an issue for the flow. Like for email for instance, you get you send out an email, you get four back. So there's four things I need to deal with. And this is not really helping organizations to get stuff done. I think we are social animals, we should visualize more. We should share, we should collaborate. I'm a huge fan of visualization. And actually I'm not the only one, the the police are also fans of this. And if you've ever seen when they do their crime analysis, trying to find out who done it. They visualize everything, they put connections between suspects and people that are not suspects and locations, etcetera. They're trying to work it out and connect everything. So they've they've been visualizing for a long time, so. I've only stolen some of these ideas really. But I advocate, this is a leadership standup for instance where to replace monthly meetings to meet 15 minutes a day. You probably can't read it, you probably this is an easy one to take a photo of. So essentially what you have is this swim lanes are the goals of this particular team. So their their goals are around people, transformation, engineering, etcetera. And a very simple Kanban, a backlog to do in progress, done. The only difference I added was a bin. The the bin is if your little your ticket has been on the board for too many days, you get into the bin. Some people don't like to be. Some people love to be in the bin by the way, but. But if you take your leadership meeting or team meeting from once a month and do it 15 minutes per day, it really allows you to focus on the key issues and not have to have reports.
[00:31:10] actions to follow up on, people come to meetings, they don't come to meetings. It's very visual. People say, well, what about my remote teams? Well, you can use Cisco Webex, you can use, you can take a photo of the wall and send it to everybody. It's quite straightforward. But I do believe that that's what you should be doing.
[00:31:28] Um, of course team canban walls are quite normal. And I don't know whether people really actually look at these that that often, but really good ones have got a lot of the technical debt in one of the lanes as well. So in this one, all along the bottom are things that need to be fixed in this particular application. I better move quickly in case anybody recognizes what it is. Um, but also teams don't visualize dependencies.
[00:31:47] I've been working with one organizations looking at in a transformation program. The actual dependencies between the the the big pieces of the work they're doing and the platforms that are actually going to be modified. And that's quite visual. It shows you that there's a structural issue with delivery. And I'm a big fan of of taking stuff like this and getting it out.
[00:32:09] customer feedback as well. So visualizing customer feedback. Those feedback loops I mentioned in the middle of the start actually of the presentation around customers. When you can get information back from your social media or from contact centers, you can also start to address this as units of work prioritizing the backlog of issues. Some things actually, um, don't require any change whatsoever. This is where your customers are complaining about stuff, then perhaps it's price. And you're willing to take that, you're not not going to address it, it doesn't require a system change. But some customer feedback from these areas do actually need to be addressed. Sometimes they need to go to a front-end team or a back-end team, um, or they actually become a a portfolio item on the wall. The key thing is though, what I like is that if you fix something that the customer's complained about, is to get that person to call the customer. What you'll get then is the customer becomes a big fan because you've called him and said, I fixed the issue that you complained about. It's very, very powerful.
[00:33:10] I mentioned risk decisions already. But this is really underplayed. We actually think agile risk management is a thing. And we've been writing some papers, myself and Hayden Shaughnessy, the co-author of our book. We've done this together, and we think there's something in here actually people that work in risk and audit departments do want to be more agile. They're not against this type of way of working.
[00:33:32] For teams also like to visualize the history of blockers. So anything that's blocked a team and then flow of work, you can capture it, you can see what kind of impact it had, what work around was used and what the the resolution was, but somebody new joining the team can see what blockers you've had in the past. This you quite often get a theme here of blockers, they tend to be environments or security.
[00:33:57] stuff like that, which um, shows you where you're going to be having to make some effort to keep things moving. I couldn't show you the actual wall because it's got confidential stuff on it.
[00:34:07] I also use, um, this is our sort of cool wall. So this is to get feedback from the team. We've changed subzero down the end, we've changed it to awesome. So we get teams to tell us what's not so great, um, in their world at the moment and what is good. It's quite interesting. You do get quite a varied view. It's not just technical things. We get teams saying, I'm not very happy about the cold water in the showers every time I come in and cycle in on my bike, I have to have a cold shower, it sucks. Or there's a problem with cracked cups. Leaders don't know there's a problem with cracked cups. Because they just don't see that, they're not out on the floor every day. But this is where they'll get a visual representation of issues that teams face. But also teams saying, I really want to get involved in using new things. So it's a venue for that. This is a big bank in um, Scotland, who are using this now in Scotland, they're using it in uh, London, they use it also in India. So what they do is they go through this process with the teams to work out what's good and what isn't good, and then they create action plans to address it. So let's say for instance, the team says, I'm not getting enough training. Well, say, well, let's train each other. Let's actually help each other to gain those skills, rather than going to speak to the boss to get 2,000 euros and the boss says no. So it's a really powerful way of working, so teams can actually self-heal as well.
[00:35:29] Some teams like to visualize their goals. And so you can see why a person is motivated in a certain way. I really advocate doing this, so create the goals, stick them on the wall and let people see what people are doing.
[00:35:42] It's not hidden away. I've spoken to a number of organizations where the their goal information is hidden in in systems that they don't have access to. These walls, you have access to. And if you can't put it on the wall, then why are you even bothering to capture it?
[00:35:59] And thank you walls as well. I like the fact that teams thank each other. Thank you for helping me with this. Thank you for helping me learn a new skill. Thank you for unblocking this issue. I know it sounds a bit strange, but this is a wall that one team. What they do is they thank each other once a month, they take a photo, they clean it down and they start again. You start to use the same technique in workshops. I should have put one here actually, put it on the side there. So you could thank people that maybe helped you or somebody that gave you some advice or you learned something from a presenter today. Just thanking each other is something that we just don't do enough of and actually we enjoy it. It's quite simple, it's just this is just a piece of paper. with comments from individuals.
[00:36:40] And jobs wall as well. So my my campaign to try and make HR more agile. It's to put the jobs that are actually that people are looking for vacancies on a wall. Like again, I couldn't show you the actual wall because it had confidential stuff on it in one particular company, but. putting out here what the vacancies are, what opportunities there are in terms of maybe being added to a project. People wanted to swap. I'd like to swap my job with somebody else. It's quite often people do that, you know?
[00:37:07] And maybe some announcement about stuff that's coming up. Again, visualizing the opportunities to move to another team and do something else. We just don't do enough of it. In fact, quite often you hear, a job came up and it was on a system, you didn't get to see that system, you missed the opportunity. But if it's on the wall, you can.
[00:37:25] Anyway, you're probably getting the idea that visual collaborative ways of working for me are really at the center of flow. And I think that's what's more important is that kind of social interaction. Trying to get stuff out of systems, out onto the walls and people to share. I really believe that organizations can succeed via a great culture driven by this social interaction. And what people end up doing when in this kind of positive mindset is they continually improve, they create new things. I get visualization sent to me nearly every week from a particular organization we've worked at, saying, oh look, we've created this, what do you think? And I just add it to my toolkit.
[00:38:02] Fantastic. Thank you very much. I'll help them tweak it. Um, and it's not necessarily rocket science, but what teams are trying to do is help each other to keep work flowing. What you're really trying to do is get to this point where your teams you know, they feel trusted, they themselves become loyal, in fact, they become advocates of your organization. What I find fascinating, what I've seen in some companies is that when a when this organization has or an organization has great advocacy where people love working there, they start to wear the colors of the company.
[00:38:32] of the company. So if you work in a company that has colors which are green, you'll see people wearing green shirts. Or I worked in lastminute.com which was pink and everybody wore pink shirts. You might be surprised but you can take a look around your office, you'll start to see and if they're not wearing the colors of the company, then maybe you have an issue somewhere in this particular line of uh, of this goal.
[00:38:55] Anyway, so why is trust really important? I talk about this quite a lot actually. When you have an environment where trust is high, where there is team safety, where you can make mistakes, you can make issues. I was working with a a tax organization for a country last week, they had a major issue and they learned from it. They didn't blame each other. What happened? How can we not see that again? Fantastic. They moved on. But if and if you have that kind of high trust and you allow people to be bold and brave, you allow them to do test and learn, etcetera, you will get innovation.
[00:39:27] More often than not, I see organizations with low trust, um, and very and won't allow people to make any bold or brave moves. Then you'll have this fear culture. What you're trying to do is foster innovation. And it's again, one of these techniques you can use to try and discover where you are hopefully and not in the bottom of the left-hand corner. Anyway, so key takeaways from this conversation.
[00:39:52] the key to successful flow. It's really to challenge yourself to fight for simplicity. Flow shouldn't be complex. I mean, if you think about it, flow should be flow. Why do things go like this? Why do they get stuck? And it's because of potentially processes or issues or um, structures or traditional ways of doing things, and trying to get things simple for me is pretty important.
[00:40:18] is pretty important. Leading in a visual environment where team members can be really social, interact in a creative and a supportive way is fantastic. I didn't even show you half the kind of pictures and and screens I have, I've got lots and lots of them where they are. Um, for me, some great sort of venues for people to work together. And some of the techniques have been evolving and changing. I've now seen around about about 20 different portfolio walls, all structured differently. All designed by the teams themselves. And what happens is people say to me, can I have a portfolio wall template, please? Well, there isn't one. It's your context, it needs to fit your context and the way that you work, not the way that I think you should work. That's why I find frameworks and methodologies a bit too rigid.
[00:41:05] creating simple pathways to allow teams to take small steps to delivery. This is fundamental, I'd say. Small steps to success, it really is the way to do it. So some people say to me, well, how do we get this big transformation in our organization? What should we do? And often you see people rush off and create a big transformation program office or they get millions to spend on projects and to change stuff. I say, no, no, no, start really small.
[00:41:32] Start with what we call a lighthouse project. Pick one thing of value that you want to do for one team. You get that team to actually work together and learn these techniques, let them evolve, let them find out what the challenges are. Once you've sorted that out, then start to scale from there.
[00:41:50] Even though, you know, you see companies putting in, you know, automated pipelines, they're sticking in cloud. They're doing it at such a scale that it overwhelms the entire organization. And what happens is that people start to push back. It has to be done in small steps and in the same for software delivery, the smaller, the better, the easier to consume, the easier to fix, the easier to change.
[00:42:13] And focus on trust to engage the your team. providing safety and actually does drive innovation. But that's not easy to do. I often see people not really being able to attempt this without some guidance and some assistance. So I'm a big fan of having coaches in the organization that can actually do real time retrospective. How did you feel about that? What did you think about this? Why did that happen? Or calling out bad behaviors from leaders.
[00:42:43] Are leaders making, you know, maybe overriding the conversation, stopping people coming into the the conversation itself. That kind of stuff has to be done by somebody being kind of like slightly away from it and empowered to give that feedback real time. For me, I think if you can get to that level, you really will start to make your organization actually flow a lot better.
[00:43:06] Anyway, feel free to contact me. I I love to speak to individuals. I do like to find out how organizations are dealing with their um their challenges in transformation. or methodologies or frameworks or Spotify models or whatever. It's great. I'm talking to a company at the moment that's um in the middle of a massive safe implementation and it's not going well, they want some advice and guidance. I'm not sure I'll be able to help that patient, but we'll we'll give it a go, you never know. Maybe I'll be here next year telling you how great Safe 5.0 is.
[00:43:41] you know, and it's changed the name to Flow 5.0, you never know. Um, not sure that's going to happen, but anyway. Um, but you can you can find me on on LinkedIn or or or Twitter. Um, but I also do I do encourage people to just reach out. Because I think we're all trying to help each other. I mean, it is a should be a collaborative world. And that's it. So, thank you very much.
[00:44:12] If you have any questions, that was 138 slides by the way. In no doubt. Didn't feel like it, did it? Were you feeling hungry? Yeah, hopefully I took your mind off lunch, right? There's a question at the back.
[00:44:26] Well, thank you for the prediction. Um, I will just have one question. How would you summarize the difference between your vision of the flow and the pyramid 5.0 that just focus on business agility and use exactly the same vocabulary as you are.
[00:44:42] Who's that? I would that's what the safe teams are. Oh, yeah. Well, that's because you know, plagiarism is alive and well, you know, so, um. I we for instance, a lot of what we do in terms of visualizations, we open source them, we we let people use them. We've they're all yours, you know? Uh, we both Hayden and I, we write nearly every week or or been a bit lazy recently.
[00:45:03] But we write about our ideas and our thoughts. And you'll find this popping up in other people's work. So I'm not surprised about that to be honest with you. I do find that flow itself has not really been grounded in terms of what it really means. And business agility is the same. I see people saying that, right, we must do business agility, but they really just focus on putting agile for an IT perspective in place, not this wider scope. And I do know that the scaled frameworks do need to really, um, try and bring leaders and senior people on this journey. And what they're seeing is that the teams themselves are not as happy as they could be. The teams can't be self-managing, self-organizing. They can't have their own charters, they're forced into a way of working. And that's not really what agile's all about. So I think there's a struggle going on. And and it's good that they're looking at this. Whether they'll be successful or not, I don't know. But uh, but anything we talk about or write, we share with everybody. And we've seen people out there copyrighting flow. Like copyrighting the flow framework, copyrighting they they're trying to steal the ground and I think it's it's a way of working for the people. It's not I would hate there if it all turns into being something that you have to be certified.
[00:46:15] I took a number of slides out about certification and stuff like that. So I shouldn't get on to that hobby horse, but you know, I find having to pay to be in this space.
[00:46:23] is not really the best way to be. That was a very long answer, wasn't it? You probably wasn't expecting that. Any other questions?
[00:46:34] Nobody else? No.
[00:46:39] Great. Well, you're going to get lunch before anybody else if you're quick. Okay. Well, thanks very much.

Transcript