Kit Friend is an Agile Coach, proud geek, and Atlassian Partnership lead for EMEA at Accenture (despite his enthusiasm, these views are currently officially only his own). In this special episode of the Voices of OKRs series, we discuss where it might make sense to apply the Waterfall model (and yes, in some cases this would be a reasonable approach), the many ways to be agile—from the “Seen more rarely currently approaches” like Lean to those we should “Approach with caution” like the “Spotify model,” and how organizations should be thinking about mapping work to value, data to strategy.
Kit Friend (00:00:00): So why I really like techniques, practices, and tools around things like OKRs is because it enables us as kind of hunter/gatherers who are looking for a visual interaction, to be able to go like, “Ah, okay, cool. I understand the link between what I am building, what the inspiration was at the beginning and what we’re doing there.” And then like, “How’s it going?” And it was just to form that link visually, and then to use the data and pull it together, which is really important. It’s a story. It’s a story that we’re trying to tell around value around how what we’ve built, then links to how it’s done and what we should do next, and what should we put in the sequel.
Jenny Herald (00:0:40): Hi, and welcome to Dreams with Deadlines, a podcast where you’ll hear real stories of trials and victories in business. I’m Jenny Herald, Chief Product Officer of Gtmhub. Gtmhub is the world’s most powerful platform for Objectives and Key Results, or OKRs. In concept, OKRs are easy to understand, but challenging to execute, until now. Check us out at gtmhub.com to learn more.
Jenny Herald (00:01:10): Kit Friend is an Agile Coach, proud geek, and Atlassian Partnership lead for EMEA at Accenture. And despite his enthusiasm, these views are currently officially only his own. In this special episode of the Voices of OKRs series, we discuss where it might make sense to apply the Waterfall model. And yes, in some cases this would be a reasonable approach, the many ways to be agile—from the “Seen more rarely currently” approaches like Lean to those we should “Approach with caution” like the “Spotify model,” and how organizations should be thinking about mapping work to value data to strategy. Let’s jump in. Hey, Kit, thanks for joining us on the show, Dreams with Deadlines. I’m super stoked to have you on the show today.
Kit Friend (00:2:02): Hey, Jenny. It’s lovely to be here.
Jenny Herald (00:2:04): All right. So let’s start with who are you? Who’s Kit?
Kit Friend (00:2:09): Well, I guess officially, so I work for Accenture in our technology strategy and advisory enterprise agility practice, which is a bit of a mouthful. I should caveat everything we say here by saying that the views are my own that I express here. But hopefully that will be valuable to your listeners anyway.
Jenny Herald (00:2:24): Oh, absolutely. Let’s jump into what it is that you do.
Kit Friend (00:02:28): So I’m an Agile coach and Atlassian practice lead for EMEA at Accenture. So I work with Agile teams and teams using Atlassian tooling, and over the counter stuff. I’m a bit of a tooling and Agile geek generally. In fact, I helped curate one of our communities of about 1800 Agile geeks globally. So we’ve got loads of Scrum masters, Agile coaches, people who would like to be one of those that are struggling with agility. So, I work in lots of those areas with our internal teams and with our clients.
Jenny Herald (00:02:55): How did you end up doing this?
Kit Friend (00:02:59): Yeah, it’s one of those... I always love hearing people’s stories when you go through. Everyone feels like a kind of cascade of accidents. So I started off in art design. So my parents were both at the BBC, the British Broadcasting Corporation in the UK. My mum was my dad’s boss in BBC Graphics back in the 1970s and 80s.
Jenny Herald (00:03:20): Your mom was your dad’s boss?
Kit Friend (00:03:22): Yeah.
Jenny Herald (00:03:23): Okay.
Kit Friend (00:03:24): Dubious workplace practices at that point in time, clearly. So they were graphic designers. And then my dad went on to be a special effects designer with BBC. So he made things like Tinky Winkies handbag, various bits of the Daleks for Doctor Who, for any sci fi geeks, other stuff, so it was quite fun. So I ended up sort of falling into art college, because it sort of felt natural as a creative thing. So I went to St. Martin’s, which if anyone’s [inaudible 03:52] you have paid tribute to my education in some kind of small way. So, I was there for four years, so foundation, and then a degree. And I guess, like lots of people going into creative industries, you kind of start out with this, like, “I don’t know what sort of creator I want to be,” because the secondary school level, or high school level education in the arts is so narrow, and you don’t get to appreciate all the different disciplines.
Kit Friend (00:04:18): So after my first year, I thought I was going to be maybe a sort of jeweler, like silversmithing and that kind of stuff. And then I took a degree that no longer exists with the most amorphous title ever, I think prepared me for life in Agile and consulting, which is my full degree title is [inaudible 00:04:34] art design environment artifact pathway.
Jenny Herald (00:04:37): What is that?
Kit Friend (00:04:42): In retrospect, it was a lovely experiment. All those things sound like a good idea, they say, they put together a bunch of people who are trained to be architects, a bunch of people being trained to be spatial designers. So sort of interior design and spatially kind of things. And then artifact was like this third of the course who designs sort of objects, but were product designers, and I was one of those people. But in retrospect, it’s sort of lined up with what I’ve done now, because I increasingly worked on organizing groups of people to do things. I actually spoke to my university career service, which I never had talked about doing, despite the clear consensus there. And they were like, you should be a consultant. Like, you look...
Jenny Herald (00:05:25): You should be a consultant?
Kit Herald (00:05:26): You have no definite role, but you kind of like fixing problems.
Jenny Herald (00:05:31): Oh, no.
Kit Friend (00:05:31): Yeah. I can’t remember how many I applied to but thankfully, for my various bits of experience Accenture accepted me, and I went into the big kind of generic pool of graduates, what we call analysts. And then my first project was at UVU, which was an amazing experience. So building a, an online TV platform in the UK. I learned about Agile for the first time, so [inaudible 05:54] learning and things. had lots of local to learn from. I encountered JIRA for the first time. So like, right at the beginning, like JIRA has shaped my career and been a constant companion. And then I went through a series of mainly broadcasts kind of projects. And in each of those they will, I mean, I think the creative industries probably embraced our job before a lot of other sectors in my experience. So in each of those, I learned and evolved and was able to encounter other people with far more Agile knowledge than me that were able to learn from and do that. Yeah.
Kit Friend (00:06:28): And then, I guess, probably about two years ago, I sort of transitioned from being deployed on mainly kind of single projects, delivering things and working on delivery stuff to coaching our teams and our clients. So I moved to being sort of more of a shared Agile coach and tooling specialist helping out people on a variety of the campus scenarios, which is kind of what got me to Gtmhub, meeting you, and all things like that, because I guess I’m always interested in ways that we can help people with tools, techniques, practices, whether it’s technology or just like helping people organize themselves better. I’m really, really interested in in doing that.
Jenny Herald (00:07:06): I mean, goodness, that’s quite a journey.
Kit Friend (00:7:09): Yeah, 10 years, right. So like, the...
Jenny Herald (00:7:13): Pretty amusing.
Kit Friend (00:7:14): And it comes summarized. And I guess along the way, I mean, you learn from everything else, as well in your life, right. But I’ve been a martial artist for almost 18 years now, something like that. So I did martial art called (Sanduro 00:07:29), which has a big influence on my practices. I always find it interesting. It’s really common, I found an Agilist to have a martial art on the side that they’re kind of doing.
Jenny Herald (00:7:36): Are you serious?
Kit Friend (00:7:37): Yeah, yeah.
Jenny Herald (00:7:38): I need to start asking people then. You’re an Agile person.
Kit Friend (00:7:41): And they’re like, overlaps with like, the whole like [inauidble] and all that kind of stuff.
Jenny Herald (00:7:46): That’s wild. Okay, that’s really cool.
Kit Friend (00:7:49): I think I feel kind of shapes and things as well. And then I’ve got two young sons, I live with my wife in West London. So my sons are four and six, which, being a dad shapes things a lot as well. I think it’s been interested in as trying to factor in good work life balance with my Agile actually, because I did a six-month parental leave at Accenture, which is one of the many amazing things about working there. But when I came back, I was like, “I can’t face going back full time, I can’t do five days a week, I want to be home with the boys.” So I have come to terms with being off on Fridays. I like trusting my team’s work by themselves without me as a Scrum master. And I think when you talk about like enabling your team to be self-organizing work without you. But having that enforcing function was really healthy for me to take my claws out and actually trust the team and stay true to what we said. So being a dad has been quite cool to my agility journey as well.
Jenny Herald (00:8:47): That’s pretty awesome. Well, let’s start talking through some of this Agile stuff, because you said you transitioned from being deployed to being on the coaching side. So we’re going to just launch into the first question. A lot of folks understand at least the more traditional way of managing projects, and in the industry, that’s becoming like, not cool, and not useful. And everyone’s like that’s parochial, why are you doing this? But certainly, we don’t want to be too dogmatic, so we’ll start here, under what conditions do you think it’s okay to manage a project in a traditional way, like Waterfall, as an example?
Kit Friend (00:9:26): Yeah, I’m really fortunate to be able to do lots of teaching at the moment, which is a great way of learning, as the cliche goes. But fundamentally, with traditional approaches to not just doing projects, but kind of anything like, I always talk about planning your holidays, or opening a bakery and loaves of bread. But really, with a traditional project, you’re relying on some things being stable for the duration of you doing that thing, whether that’s a project or your trip to go to Cornwall, whatever it may be.
Kit Friend (00:9:56): So I guess the first thing is that you’re saying that okay, I can reasonably say that what I want is pretty fixed. And with quite a level of granularity, right, you’re saying I definitely want to do this, if you’re planning a holiday, you’re picking the roads, you’re choosing stopping points, you’re being relatively definite there, may be a little bit of variation. But fundamentally, the whole bargain that was striking in the project is that you’re fixing it, you’re like, “know my scope. I know what I want to do, I know which roads I want to drive down?”
Kit Friend (00:10:26): The second to me is like you’re fixing the technology, you’re fixing for the method of doing the thing or the ingredients that you’re using for your bakery. Now, if you can say reasonably well, that you’re able to fix both of those, and not just wishful thinking fix, but actually commit to it for the duration of your thing, then, okay, then you’ve got the starting, the makings of maybe being appropriate to go about things in a Waterfall traditional way. And I guess the third aspect that we often say is like, and can you reasonably make the gamble, but non external factors are going to impact you?
Jenny Herald (00:11:04): That’s a tough one, right? Because I mean, how do you control for that?
Kit Friend (00:11:07): Yeah. Are you not going to change what you want? Are you not going to change...? Like, are you certain that the technology is not going to creep up on you and something a bit differently? And I mean technology in the broadest sense there of like, things you can use to make stuff so, like, when I do carpentry at home, my technology is my hammer and so on. But that third one is like, is the market stable enough that you’re happy to make that gamble for the duration of what you’re saying is going to happen. And those three questions, I think, are really fundamental to you saying like, “okay, we’re okay to manage this in a traditional way, and more willing to take the risk.” Because it is all about risk with these things, right? If you have a discussion with the procurement team, or finance or legal, or a team that manage risk, they’re coming to you and asking you to fix things. And it’s perception that you’re decreasing risk by fixing those things in place by making a promise, and that’s decreasing risk.
Kit Friend (00:11:58): And I think, really, if you think about the three questions like, I’ve rarely seen a project or program, a journey to Cornwall when driving on holidays, that stood the test of those three questions. I’d be really, really surprised if anyone had fixed in their plan that got rubber stamped last summer or in January, move entire workforce remotely in March, right?
Jenny Herald (00:12:24): Right.
Kit Friend (00:12:25): It just wasn’t there, right.
Jenny Herald (00:12:26): Right.
Kit Friend (00:12:26): So we can’t prepare for those kind of things. But I think with a traditional approach, what you’re saying is like, no, I don’t need to manage change; change is a surprise and it’s not common for us. So you’re treating change like this anomalous chaotic thing that comes in, and it’s an exception, and therefore you have a complex change request process if that happens, right?
Kit Friend (00:12:48): Anyway, let’s pretend for a moment that we have those three things and you’ve ticked all the boxes you like, Yes, I’ve got everyone to sign in blood, that this is what they want, and they’re not going to change their minds. Yes, we’ve picked technology that there is absolutely no chance of changing. And yes, we are certain that the external factors aren’t going to change during the duration of my project. And if you can answer all three of those, then it makes sense to put everything in a plan like and like commit everyone to that plan, socialize [inaudible] to make loads of decisions up front, which often lends itself to lots of governance and steering committee meetings.
Kit Friend (00:13:26): And at the end of all of that, if everything’s been ticked on that list of things, then the gamble that you’re striking is that if you follow all of those to the letter, then you will get out what you specified at the beginning. Now, areas where I’ve seen that that works okay are like really small things. And I don’t mean, like people want them to be small or hope that it’s small and simple.
Jenny Herald (00:13:46): They scope it small?
Kit Friend (00:13:47): Yeah, they scope it small. And there might be some practicalities. So my favorite example is from one of my friends. And he talks about digital advertising campaigns. With building a digital advertising campaign, and it’s kind of reasonable, actually, but you could fix it. Because you’re not going to spend years building it, right? Maybe you’re spending like four weeks on a build cycle. Now the technology, yes, it’s fast paced, and you’re using like Facebook ads or whatever, like things where there’s lots of change. But for the duration of those four weeks, and you’re relatively short-lived campaign afterwards, you can probably take the gamble, but it will stay relatively fixed. It is a gamble, you’re making a decision, but you’re kind of fixing these things there. And market conditions, well, you’re hoping to get it out quick enough that your market research, whether it’s from what’s now or you’re looking ahead to when you’re going to launch is accurate. There’s still a risk.
Kit Friend (00:14:40): Now, I think in that example, what I found really interesting is like so you said, Okay, so you can therefore Waterfall the bill for this digital advertising campaign of four weeks or six weeks sort of phrase. So your client comes in the beginning make their lunch soft drinks manufacturer or something like yeah, I want this kind of personalized campaign where you can put reindeer horns on your picture and post it or Facebook or something. At the end, we build it there.
Kit Friend (00:15:03): Now when you launch it, though you have this fundamental problem of people don’t behave as you want them t. And we know this to be true, this is a certainty. And so once you launch that product into live, you can’t waterfall the maintenance of it, you can’t maintain and enhance it by waterfall. And so you then have to dip into a more Agile approach, or a DevOps approach, or SRE or whatever you want to maintain that product and make it continually useful to people. So small things you can potentially watch for beginning whether they’re physical or digital, if you’re willing to make that fix.
Jenny Herald (00:15:37): Yeah, that makes sense. I mean, so what you’re saying is, like small projects may make sense if you can satisfy those three things that you’ve just gone through, right, basically saying that it’s predictable. If you can, predictably, understand what it is that you’re trying to do, what it is that you’re building with, and what it is that the market is trying to say. And if you can say that with some level of certainty that all of these things are predictable, and we can account for those as we’re planning, then sure, go for it. But after the fact, you release this thing, that’s no longer predictable, because people aren’t predictable. you’re releasing to humans, and we’re the most unpredictable things ever.
Kit Friend (00:16:18): Yeah, we kind of... Yeah, and in fact, we oversimplified the technology bit of that as well. Because of course, who builds using the tools? Well, loads of people as well. Can you read exactly how your team of bakers of software developers are going to behave? Like, really? Probably not. You don’t know whether your lead developer is going to fall out with the tester after four weeks and like, well, it’s your plan, right?
Jenny Herald (00:16:43): So then there’s obviously a very strong case, no matter if you start with a traditional model of when you’re doing that maintenance and that upkeep—I like to call it hygiene, I think it’s a similar flavor—that you need to be able to adopt some sort of agility in how you approach your work. So let’s talk about all the different frameworks that are out there. I feel like there’s a ton. And I remember, right?
Kit Friend (00:17:07): Could you ever have a comprehensive list? I wonder.
Jenny Herald (00:17:10): I wonder. But I remember you showing me once this wonderful PowerPoint slide. And I was like, woah, and I saw some of the more old school frameworks. And I was like, those are old school already?
Kit Friend (00:17:24): I try and use the phrase “see more rarely.”
Jenny Herald (00:17:28): Yeah, I saw that. So, let’s talk about the ones that aren’t used that much anymore. What’s the stuff that people used to know and are kind of seen rarely nowadays?
Kit Friend (00:17:39): Yeah. And I think what’s interesting when you go through this is it’s a kind of… you then kind of caveat it and come back and loop around, right, because there’s a lot of them where you don’t see them badged as that anymore, which we can let you know. But then you’re like, ah, but the techniques, the phrases, and things are becoming better and other stuff.
Jenny Herald (00:17:58): Totally.
Kit Friend (00:17:58): Which I guess is good, right? Because if we’re doing Agile right or working right, or being value centered, right, if something worked well, you shouldn’t dump that thing, right? There are bits of waterfall, which are great ideas, right? Involve your stakeholders, get everything, have a plan that is visible to people. There are things that work well in traditional project management and approaches, which you definitely shouldn’t dump. And the same would be with the Agile approaches, or things that we would retrospectively classify as Agile that are still true.
Kit Friend (00:18:29): So normally, the sort of ones that we have in that diagram, and I guess we don’t have visuals, maybe we’ll have it in the show notes, but for your listeners. If you imagine a big white umbrella with four columns under the umbrella’s careful perception. So this first column is the see more rarely. One that we like to introduce when I’m talking to teams here is lean because then you come back to it and invalidate your own classification later. But I see relatively infrequently, teams doing things that they would classify as lean, like six sigma kind of stuff now, especially in comparison to like if we look at large organizations in the 90s, or things are dangling. And I think it’s quite difficult to apply lean to like a single small, Scrum sized software team as well. The interesting thing, though, is of course, the principles of lean are definitely true.
Jenny Herald (00:19:20): They’re true.
Kit Friend (00:19:20): Yeah, there’s fundamental things that we’re talking about a part of lean, yes, totally apply. But using it as a framework on its own or an approach on its own is quite difficult to do at the moment. And we don’t hear many people… if you compare it to like how often you are asked to provide a scrum team or coach a scrum team, or you encounter a scrum team in organizations, you don’t see it as often. I then link it back normally when we’re talking teams to when we talk about scaled methods like safe where you’re like, aha, but as you grow, you definitely need… how are you going to manage this? Well, lean portfolio management. So lean comes back.
Kit Friend (00:19:53): But I think it’s always interesting to introduce people to the roots of that kind of way of thinking in the Toyota Way and like... I also like to use it to help dispel this myth that so much of Agile is only applicable to technical teams building software. Because of course, like the roots of Lean, and Toyota Way is physical supply chain manufacturer, right, it’s building things. And so that’s a really good one to kind of level set with people. And then we recommend the Phoenix project.
Kit Friend (00:20:18): So Lean’s in there. I like to talk about XP as something that I rarely see a pure XP team these days; you do get pockets of it, I’ve noticed. I often see people kind of putting XP in is like a test of whether you know what it means, and can kind of… They’re like, “Oh, what do you think of XP practices and stuff? So one of my one of my friends Lawrence Allen Moselle, I think he still works at Skyscanner in Scotland as an Agile coach. But I remember him talking to me about Scrum and XP from the trenches being like the first book you must read on your Agile journey.
Jenny Herald (00:20:53): Oh, wow.
Kit Friend (00:20:54): So I encountered the word XP relatively early. But we didn’t see it so much now. And I as isolated thing, we’re like, we’re just doing XP. I’m always interested in talking with developers in my team’s about how they would feel about things like pair programming as well, because it doesn’t tend to get a good reaction—that practice on its own doesn’t tend to get a good reaction from my developers, in terms of literally having someone workin…
Jenny Herald (00:21:18): Physically sit with you.
Kit Friend (00:21:20): Or virtually now. That’d be interesting. I haven’t spoken to a team doing XP during remote working and how they find that when you’re not able to be close to each other to see through them. And then a bundle of the other kind of three letter acronym ones, right? So like Rad, Evo, those kind of things. So seen more rarely, I just reinforced that, it doesn’t mean that they’re bad agile, though, right? I mean, you can definitely find a theme where they’re like, using one of those or a blend of those is the right answer for that team, but we see it come up less frequently in conversations in my experience.
Kit Friend (00:21:51): So I guess the second column that I normally talk about is single team frameworks or single team methods, approaches. We say like Agile is the mindset relatively free of debate, people using the mindset with agile. These frameworks or methods or processes and things though, that sort of generate bait. But in that column I talk about Scrum and Kanban as the first kind of areas for people to get some awareness of on their Agile journey. I think I wrote this in an article recently that you were commenting on in our chats previously. But for me, Scrum is a good place to start your Agile journey, even though it might not be the right destination. In that column it’s about Scrum. I recommend Scrum for beginners, trying to get to grips with our job because I think having something where there is a relatively consumable number of defined roles, practices and things is a good thing for when people are trying to get started.
Kit Friend (00:22:45): I think it’s kind of difficult because in agility, we naturally want to be agnostic, right? We want to say, you should grow and evolve and learn, adapt, pick things best for your team. But it’s kind of terrible advice to give to someone to not give them some direct advice on the journey. Okay, that’s all good. But if you want to start somewhere, because everyone has to start somewhere. I tell people to start with Scrum, because I think that simplicity, that breadth of adoption, the common currency in the industry is really welcome. And then I like to talk about Kanban in that column as well, because for me, it’s sort of... I don’t think it’s the opposite, but there’s a contrast there and like, okay, so Scrum, simple to understand, at least to start with, simple structures and things begin with. Kanban is like the most misinterpreted, confused kind of area in my experience of encountering teams. So if I encounter a team who say they’re a Kanban team, and I like, “are you really? Like, tell me what you think you’re doing.”
Jenny Herald (00:23:42): This is what I was so surprised about is most people would think that the Kanban, because there’s so many tools out there are, you know, this thing have to do. It’s in progress and we’re done. And if you use a board that has those three columns, you’re a Kanban team, right? That’s not true. Like that’s what…
Kit Friend (00:24:00): I’ve lost my honky horn around me in the room at the moment, I have allowed a rather comedy honk horn, and when we’re teaching, I go, “So who’s been on the Kanban team?” and then
Jenny Herald (00:24:11): Everyone raises their hand, I guess, everyone.
Kit Friend (00:24:14): “Oh, so what made you a Kanban team?” And the first person who says it’s the board gets a honky horn. Now, of course, you can be on a Kanban team or be using a board, of course. But there’s a big misconception that sticking a board with some columns up makes you agile. And of course, a tool does not make your team agile. I for a long time, felt super guilty that I hadn’t done enough underpinning combat training and learning to be able to genuinely do that. So one of my colleagues, Andrew Rizzo taught amazing first Kanban course stage for me a couple of weeks... Yeah, about six weeks ago. So I’m now on my Kanban journey to correct my lack of formal qualification in the area.
Kit Friend (00:24:54): I mean, there’s no recipe for like, this sort of team must use this approach to Agile right? But I particularly like to talk about Kanban with teams like legal teams or contact center teams, either whether it’s like, definitely a constant flow of work. And you look at the team, and you’re like, oh, would it be good to try and force you into sprints and like fixed time boxes and things? Probably not.
Jenny Herald (00:25:20): [Inaudible]
Kit Friend (00:25:20): Yeah, I like to talk about Kanban at the start the journey with those kinds of teams, but I think it’s good for people to have awareness of all of these things, right.
Jenny Herald (00:25:28): So then, like the third column, I think under that umbrella would be what everyone is like, whoa, that’s heavy, the scale frameworks, really big enterprise ones, the safe and the less of the world. If you were to pick apart what the differences are between that, because there’s like websites and entire conferences, and all kinds of people dedicated to this, if you were to kind of distill it, what would you say to an organization saying, we want to go Agile transformation, and we’re looking at safe, we’re looking at less, what do we do?
Kit Friend (00:25:59): Yeah, and I think what’s really nice is like, the first thing like read the websites, because none of those websites and scaled frameworks, say, take my scale framework and apply it verbatim to your organization as a top-down kind of like... 6000 people go safe, kind of thing. I feel really sorry for the safe implementation roadmap, because it’s super sensible, right? It says, start letting go teams, you’re going to scale, start a new experiment, then learn and grow, and all these kinds of things. But people get very excited by a definitely full featured, rich selection of stuff that like, “Right, I want to apply that to my organization, all in one go.” And there’s loads of organizations where safe definitely might be the right answer. But there’s loads of organizations where it’s not the right answer, as well. And you need to go on a journey to discover which is the case.
Kit Friend (00:26:50): So to get back to your question, though, when I’m trying to introduce people at the beginning of their Agile journey, so I guess the order of the columns under the umbrella of my Agile mindset umbrella, protecting us from the waterfall rain, is intentional, right? Because you want people to get an idea about the history of where we come from, like, the value of principles like Lean, and we’ve learned from there. And then you want them to start with single team frameworks, right? This is intentional, no one should go from scales down and go, ‘Okay, I want to establish a 600-person Agile team. Let me start with that, and then worry about the single teams later.” If we talk about the frameworks that I see most commonly. And I guess you’ve probably said that all my opinions on this podcast are my own rather than other organizations. So, safe is wonderful for provide tripwire, newly attempting to provide an answer to or guidance to every question in your Agile journey, and to be honest, like, even if someone’s not asking for safe guidance on something, but they’re like, “Oh, what is the product trying to do?” I’ll often go to the safe website and give them the article on that component of safe and go, “This is a really well thought out full feature description of this element of agility.” Yes, it’s coming from the safe framework. But I think there’s a hell of a lot of hard work that’s gone into that to build it out, to the extent where I’m kind of like, oh, I wish I had the time or the energy to invest in build the apps and things like that.
Kit Friend (00:28:16): So super powerful there, it does an amazing job at trying to answer a huge amount of questions, and putting in place a variety of levels of framework and configurations that can answer a lot of questions. The natural result of that is that it’s easy to get terrified by that amount of content.
Jenny Herald (00:28:33): I imagine it’s probably overwhelming. I read through it a little bit. And I was like, “Whoa,” that made me thought about almost everything. That’s what it feels like when you read through it.
Kit Friend (00:28:43): Yeah. And it’s intuitive, right, thankfully. So you say, 4.5, 4.6. I think either did 4.5. I’ve just done my upgrade to five to zero. So yeah, embrace the fact that they’re learning as they go. I think they’re running safe out safe to these things is that
Jenny Herald (00:29:01): That would totally makes sense. That’s interesting. Apply the framework on your framework evolution.
Kit Friend (00:29:06): Yeah. And to be honest about it, right? You’re like, okay, like, here’s what we think is the next version of this, what do you think? Did we change the wording wrong? And they tweak things, right. So they, they move from talking about stretch objectives, and stretch goals to uncommitted. So safe is wonderful, and you have that there. And it might be the right indentation for people. Or it might be the right starting point or the right kind of middle point before they then go and evolve and do something else, or they are verifying it and you end up there as well.
Kit Friend (00:29:35): So you shouldn’t ever end up with a static end state that looks like a copy and paste of an image from any of these websites, to be honest. So safe, wonderful there. I’ve done my certified large-scale Scrum less course where...and in fact, my Scrum at scale, Innovative Agile Center in London, they’re our lovely training provider. And I think both of those frameworks, try and offer a relatively lightweight approach to scaling agility, kind of to get a team able to go potentially a bit quicker or with fewer things there. I’ll just say compromise, right? Because if we’d say if I can go to the website and drill down into one single point and have specific advice on Lean budgeting guardrails and things like that, which is amazing, you won’t find that level of detail in less or Scrum at scale. And that’s intentional, right, they’re not trying to answer all of those questions.
Kit Friend (00:30:29): And so it’s one of those awkward answers right, where it’s like, which is the right framework for my organization to end up with? And it’s like, well, firstly, it depends. And secondly, but you shouldn’t end up with a fixed copy and paste version of any of those frameworks. But they are meant to be there as stepping stones and guidance and balance for you. And if a team, if a large organization’s like how do I do this thing? Well, there’s a bundle of answers. But one of the key and awkward bits, like we need some coaching from people who’ve got experience with a few of them, that can help you navigate and go like, awesome, like, the way of organizing things to make the implementation from right back from safe is great. But when you encounter something, maybe you need to go to Scrum at scale and look at the way they do something and use that as part of your inspect and adapt behaviors to see what’s happening. So a bit of all might be what’s the right answer?
Jenny Herald (00:31:20): And be pragmatic about what your organization needs and then what it will… even probably imagine, you probably have to gauge the culture of your staff, your teams, and what they would be willing to do, because ultimately, they’re the ones who are going to be inheriting all of that practice, all of those processes and keeping that disciplined order. But otherwise, if they don’t agree with her, it doesn’t make sense for them. I imagine that’d be very difficult. They might reject it.
Kit Friend (00:31:49): Yeah, you get the cultural rejection of tissue rejection, I often call it with things. I guess the common pattern with all of these, whether a single team or scale model is though, is like, you do not need to reinvent the wheel or start with a blank sheet of paper, right? We’ve got these recipes, you can start with one of those recipes. And just like when you’re cooking—and this was the crux of my article this week. So my colleagues have done talks about (inaudible 00:32:15), I talked about baking cakes. It is not a good idea to assemble a jumble of ingredients you think might be right, and then smoosh them together and see what happens. Use one of these recipes, at least as your starting point. So yeah, have a go at running your team in textbooks scrum for three to six sprints and see what works and then alter it and tweak.
Jenny Herald (00:32:36): (Inaudible)
Kit Friend (00:32:36): But starting fresh is just like, it’s a crazy waste of things. I mean, you might make up an Agile framework, or a scaled Agile framework that is amazing and works, but like how likely...? Probably unlikely that you’re able to make up something that is as good as the cumulative effort of huge amounts of people working together.
Kit Friend (00:32:57): Yeah, I mean, I can see that like if somebody had never cooked before, and then you put them in a kitchen and they just start throwing stuff in a pot. And they’re like, but their ingredients, it should be fine, you know?
Kit Friend (00:33:08): Yeah. I mean, it’s like the monkeys with typewriters thing, right, like, give them enough time and enough typewriters and enough paper. And yeah, you’ll complete works of Shakespeare. Like, do you want to make that gamble when you’ve got the complete works of Shakespeare? And you can be like, hey, maybe do a pre-see. Yeah,
Jenny Herald (00:33:23): Right. Yeah, I mean, so I think from a just a practical standpoint, that makes sense to just kind of trust the pros, people who spend their careers quite literally thinking through how to do this, and have documented and probably run multiple revisions on it, obviously, as we’ve seen with Safe that they have different even iterations of how to go about it. Yeah, I think that that makes sense to not try to piecemeal it from the get go and try to release stick to the script, so to speak, and then evolve from there to see what will land with your team. That make sense.
Kit Friend (00:33:56): And that neatly lands on the final fourth column of our Agile umbrella, which is the heavy monsters, the be really kind of full column. And like there’s two, there’s two bits that we normally put in there when I’m teaching courses. So one is the making it up as you go along or homegrown, kind of thing, which we’ve just spoken about. So like, don’t do that. You can totally iterate and improve upon and learn and adapt once you’ve put in place through one of the recipes. And the other one is the Spotify Model. The Spotify Model is two YouTube videos from 2014 that provide a beautiful visual articulation of a combination of things that the Spotify teams were doing, things that they quite wanted to do, ideas they had, and it’s really fascinating to read the statements from Henrik Nyberg and the other coaches involved around that because it’s really can take on... Henrik Nyberg and the other agilest forSpotify are amazing agilists, right? The body of work that they attend It is fantastic. But I mean, the summaries they provided like they did not intend for those YouTube videos to be taken verbatim, and applied to like an insurance company, or something that. If I turn to you to take like the technical architecture from a Swedish music app in 2014. and apply it to your insurance company in 2020. But you think I was insane, right? I’m like, “don’t change your thing, use these videos I produced in 2014,” at my lunchtime summary.
Jenny Herald (00:35:26): I mean, I get where you’re coming from, I’m not trying to advocate that the Spotify Model is good by any means. But when they look at it, they’re like, but Spotify is successful, they were looking at that outcome, like, well, Spotify is producing stuff that the world is paying attention to. And we used to have radio, and we used to have Apple Music. And we used to have all these other things. And Spotify came out of what felt like nowhere. And then they shared with the world, this is how we structure our organization with tribes and gills and chapters. And everyone’s like, we want to have that kind of disruption or success in our industry.
Jenny Herald (00:36:02): And so that’s what I think had happened is like a company or organizations that might have felt that they were stuck in the past or looking at what feels like a very modern company, and they’re hearing about Agile practices. And here’s somebody who posted information, which is rare, right, about the inner workings of our business and how we tried to do it. And then everyone else is like, well, maybe that would work, maybe we could apply that. And so maybe, I don’t know, I’m making a lot of assumptions here. But I think that that’s what had happened. And everyone all of a sudden said, maybe this new novel thing will help save us or trance, you know, push us forward as a business in a completely different industry. If we were to adopt it,
Kit Friend (00:36:47): Fundamentally, the problem with those YouTube videos is that they’re beautiful and engaging and compelling. And they kind of make it look easy to do what they were doing. And there’s some problems with that. So first of all, it’s that they don’t describe what they were doing, by the own account of Henrik and people there, they describe this mixture of what they were doing what they wanted to do what they thought would be there. Much as you or I might summarize things a little bit charitably and with artistic license when you were talking about your own work and to an audience, and you’re training some people. There is a mixture of do as I do, and there’s do as I say, and that kind of stuff there. So that’s the kind of first problem.
Kit Friend (00:37:29): Even if it was like a perfect capture, and it was possible to capture an entire organization’s detailed workings in a few minutes in YouTube, which like… and it’s not right, so let’s put that aside. If it was possible to do that, should you copy and paste...? And there’s not from Evan Campbell, I think “Don’t copy and paste the Spotify model.” But should you copy and paste that onto another organization and assume it will behave exactly the same way? No, you should not. And there is no accompanying book for like, here’s how to implement the Spotify model, the Spotify model implementation roadmap, which does the same thoroughness as the other frameworks to help you think about how to do that. It goes like, here’s how to establish your guild, think about whether people are here. These things don’t exist because they weren’t intended to. Maybe it could be but fundamentally, it’s not there. I was told there’s one interview where Henrik talks about how what they were doing at Spotify model was, in fact much closer to Scrum at scale. But it wasn’t called that when they were doing things there.
Kit Friend (00:38:37): Now, the other thing is, like, say, Amazon’s another successful company, right? If I went back to Amazon in my time traveling Agile machine to 2014. And I was like, “Ha-ha, I shall steal the technical blueprints for Amazon Web Services in 2014.” And then I came back to 2020. If I applied the technical blueprints from the way that Amazon works in 2014, to my new team members, like “Ta-dah, I now expect to achieve the same as this other company.” But it just wouldn’t work. So we can’t assume that going back to a set of now relatively antiquated, but still beautiful, videos can be applied without any adaptation and context. And then if you go like, oh, how am I adapt them and learn to apply them? The answer is use one of these other frameworks, right?
Jenny Herald (00:39:23): Like Scrum at Scale or something?
Kit Friend (00:39:25): Yeah. When you encounter a team, who are enthusiastically adopting Agile or enthusiastically saying that they’re doing the Spotify model. Now, obviously, you shouldn’t have the same kind of discussion that you and I have just had, right, where “you’re wrong, it doesn’t exist, just do YouTube videos.” But I think what is really important is to acknowledge what they found exciting and interesting and compelling, about that model. Is it that they find it scary to think about these formal frameworks? But what is the bit of Spotify model that made them compelling? And then you need to help them understand how to use properly, embedded frameworks, tools, practices, all this other family of stuff to try and serve those things that they wanted to achieve.
Kit Friend (00:40:10): And maybe talk about actual teams as well, “you know what, do your developers agree that that’s what they need? Do the people who are building your graphic design portfolios agree that that’s the way that they ought to work and help them on that journey.” Because fundamentally, like, it’s never as easy as watching a video and then saying, okay, cool, I can do it in my company, right? The difficult journeys that released the most value in enable people to do things are always difficult and take time, you can’t just copy and paste something and expect to be successful.
Jenny Herald (00:40:39): I feel the same way about OKRs, and the one video from Google trying to teach everyone, right, everyone’s watched that video, if you try to learn about OKRs. And if you watched it, I mean, it’s a great video. But trying to implement that across a company organization or enterprise is proving to be very difficult for similar reasons.
Kit Friend (00:41:00): Let’s move on, I guess to the topic at hand, I feel like because I would be remiss to pass over this because we’ve talked about this. So then we’ve got all of these teams, hopefully practicing some recipe of agility and a framework that exists that would be reasonable, whether it be for a single team, or they’re starting to scale it out via let’s say, Scrum at Scale less or safe, trying to connect the delivery of whatever it is that you’re trying to make, and the value stream and then the delivery of value to the customer and to the organization, trying to piece together that data story.
Jenny Herald (00:40:40): Can you talk about like, how that’s happening, like why this is super important, because we’re moving from a, hopefully, we’re all of us are really excited that we shipped something. That’s what we used to get super excited about to, we actually produced an outcome that’s really great and that needs to be measured and needs to be monitored. And all that stuff. We are seeing that transition, it’s super important. It’s showing up in Safe, where they start talking about OKRs, and how you need to build that out as part of something you’re going to think through as you’re aligning all of your delivery trains behind. Can you talk through about the importance of data and like, how teams should be thinking through this?
Kit Friend (00:42:22): Yeah. And in the team that I currently work with, that we support Allison’s coaching, we talk about five critical skills that everyone needs to have to be able to be successful in the modern digital world for things. So first one is design thinking. So like, are you sure that you’re building the right thing for that? You started the kind of problem solving there? I say we start with design thinking. But the thing is like there’s not a phase-based sequence of things that one should move through when you’re thinking about how to be successful, right. These are all complimentary skills and patterns. But the thinking and the and the disciplines that are really important, and significantly design thinking is now badged and part of the icons. In the latest iteration of the scaled Agile framework. crisis. Knowledge is a key part of doing that.
Kit Friend (00:43:10): Second one we always talk about is agile, and use a proper recipe and framework and what have you for that as possible. The third one for me is data fluency, so are using actual data to feed in the decisions that your team is making? And that data is important in various different ways. There’s kind of output-based data of like, how many features is my team delivering? How many story points are we delivering? How many bugs are we fixing me errors being created and low? There’s kind of things that.
Kit Friend (00:43:40): But the more thorny, difficult one that we’re going to come back to I’m sure is like the outcome related data, that the benefits and stuff. That feeds into a whole other scary thing, which about value creation is about being laser focused on value, and like working out that, should we really do this thing? And then once you’ve done the thing, like, did it achieve what you wanted? And so few teams are able to really answer those questions. They can answer the output related metrics of like, yeah, my team is fast and more predictable. I think that, but it is much more difficult to say, cool, we’ve launched this new recommendation engine, was it worth it? Like, six months later, did we achieve what we wanted? And then should we build v2? Or should we pivot and not do that anymore? So it’s more difficult, and that means that we all… no one argues that you should produce these benefits statements of varying degrees of granularity, right?
Kit Friend (00:44:32): In Waterfall, we argue, you need a benefits case at the beginning. In all of our Agile models, you say you need a value statement, clear value, but it’s still not simple to do, right? And OKRs can help with that structure we’ll come back to. And then the last area and championed in my kind of like her by the amazing [inaudible 44:50] is storytelling. So can you create a compelling story around what you’re doing to enable people to engage with it? And with the Spotify model, they did that amazingly, right? They did an incredible storytelling and made people engage with their model, but we need to think about how to use storytelling as part of what we’re doing on our teams as well to enable people to engage with that. And so those five areas are really, really important.
Kit Friend (00:45:12): Going back to the data lens on things, though, so cool, we’ve used our lovely design thinking skills, we’re able to ensure that we’re not building a faster horse rather than the car, we’re building the car now in the Ford Motor Company in 19, whatever it was. So we started on the right kind of approach for what we’re doing there. We’ve got our Agile framework, maybe we’ve picked Scrum from the beginning, we’re starting to do that, as we go through. We’ve got some data flowing in there. But we need to tie these things together to be able to tackle this nebulous value thing, right?
Kit Friend (00:45:44): Because everyone will agree that value is a sensible thing to do. But then everyone will kind of like quietly put away the value tree that they made at the beginning of their project and program; file it away, maybe as a PDF on the SharePoint somewhere. And then they’ll get on with doing their work and get distracted and not come back to it, because it’s difficult so tie those things back together, right.
Kit Friend (00:46:03): And when I talk to people about the critical role of a product owner on an Agile team, technical scrum team, I think being a good product owner and you’re a product owner so you can validate safely, is really difficult, right? Because we’re investing you with the accountability to anoint these ideas with a notional value, and guide the team towards the value. The team wants to build valuable things, of course, but people naturally want to get on with the thing that they’re good at. And kind of reverse, they need some help to be pointed towards that value and be able to achieve. And then to be able to, like work out whether it happened or not. Right? When you defined that feature, was it as good as you expected? If great, yes, let’s build more of that. If no, do we kill it off? Do we change it? What do we do with those things? And the thing is, it’s really simple to say let’s focus on value and let’s bring in data, it’s much more difficult to actually build that into the way that your team works in a maintainable fashion, where it’s easy for people to access. And we’re a visual species, right? People need to see compelling visuals to understand stuff.
Kit Friend (00:47:10): And so why I really like techniques, practices and tools around things like OKRs, is because it enables us as kind of hunter/gatherers who are looking for a visual interaction, to be able to go like, Ah, okay, cool, I understand the link between what I am building, what the aspiration was at the beginning that we’re doing there. And then like, how’s it going? And it was just a form that link visually, and then to use the data and pull it together, which is really important It’s a story. It’s a story that we’re trying to tell around value ,around how what we’ve built, then links to how it’s done, and what we should do next, what should we put in the sequel.
Kit Friend (00:47:47): So if we talk about like pragmatics, I guess the first and the easiest thing to say, but basic was like that, don’t try and do it yourself. Get an expert in to help you with things, whether it’s in your organization or someone externally, right. There are bundles of people who’ve done really hard thinking. Now, that thinking might not be directly applicable to your team, you might not be able to copy and paste it. But you can probably find a really good starter around things.
Kit Friend (00:48:13): So one of the key things I do when we’re trying to help a team start up is yeah, okay, cool. Have you got a product owner? Has that product owner been trained? And it’s distressing how frequently they can tick both of those boxes, right? Because like, if you were asking it around something else? Yeah, here’s a car. Have you done your driving test? Have you been things? There’s a fairly basic questions to answer. And if someone can’t take those, you wouldn’t let them drive that car, right? You’ve got potential for damage would be huge. So I think having a strong discipline of product ownership, product management in an area is really, really important at the start of that value center journey. And then enabling those people to access a body of thinking and guidance, whether it’s OKRs, or just like the whole area of value is really, really important.
Kit Friend (00:49:03): Now, I guess, various different areas are more or less formalized in how they approach things. There’s a lot of formalization certification badges around this Agile thing. I think that we’re still not there yet, in terms of OKRs and value, in it being crystallized so much in like a thing where I like, “Cool, I’ll go and do value course 101, and 102. And that kind of journey. I’ll take the OKR certification here.” But they probably are ones floating around, but it’s not quite as easy.
Kit Friend (00:49:40): I think I spoke to one of my friends. Greg is a data scientist. And he was saying there’s a similar kind of problem in Data Science at the moment, and that it’s not quite as crystallized as a discipline at the moment. So there’s bit more ambiguity, which makes it a bit more difficult if you’re trying to work out where you’re going to go. Yeah, Greg Detra, lovely data scientist.
Kit Friend (00:50:00): So I think the same is true with OKRs, but there’s definitely things you can start with, right. And like part of that is the thinking, like, there’s communities of people around OKRs, KPIs, value center thinking that you can engage with. And then part of it is, is using these tools and methods to help you to. And that means whether it’s a digital tool, or it’s a process, and practice speeding things.
Kit Friend (00:50:22): And there are companies that you can look at, whether it’s Google, as you referenced, or other places where you go, okay, cool. Let me start by looking at the way that they approach doing this and see if that’s applicable to my team or not. Again, don’t copy and paste it if it’s like Google’s approach to OKRs. But you can start with there is a basis and try and be influenced by it. And I think in fact, if we look at a good tool, whether it’s Gtmhub, or something else, and you’re like, Okay, we heard it, a good tool should help you formalize those questions, probably accompanied by a person to guide you, but it should help you phrase and go on that journey, so you can get towards it.
Kit Friend (00:50:54): One of the things I don’t like is when people try and do this in PowerPoint, or, or a whiteboard, kind of any sort of Whiteboard talk, like, you’re just going to lose the data, right? There’s no actual depth to that data, and it gets lost after the workshop. I think it’s absolutely fine to use something like a whiteboarding tool to do the initial engagement around like, what my OKRs be had this link up to our strategies and value, then you have to put it in something where you can bring the data in to go back to our last point, the last right, you have to link these aspirations, these strategies with data. And ideally, to have like a real source of data, right? Can you say we’ve got this OKR, that translates into this KPI that goes back and throwing the metric? And then can we tie that to the Google Analytics endpoint that we’ve got that gives us the unique page hits for this thing. So you don’t have this horrible scenario that we’ve all seen where teams commit to a benefits case of a story or a feature or an epic or project, they deliver the thing? And then everyone forgets to measure it, and then six months later you’re like, “That thing we launch, how did it do?” And you’re like, “Yeah, I’m sure it’s fine. Yeah, it’s great. It’s great. We delivered it slammed.” You want to make sure that you’re actually tracking stuff afterwards. And if you can put in place, a framework, a set of processes and tools to help people define that value, help people define the way that they’re going to measure it. And then actually make sure that you don’t have to remember to manually track it, you’ve put something in place, which just means that the metrics that you said you were going to measure against kind of fly through.
Kit Friend (00:52:29): Now, maybe you were wrong, as well about like, what was the meaningful thing to measure. But you know what, if you’ve put in place a proper Agile way of working, if you put in place one of these frameworks, one of these recipes, if you’ve got the Agile mindset nailed, that’s okay too, right? Because you can admit that you need to update the way that you’re measuring things, the way that you’re forming things. And then it’s right that I think the way that a lot of things using OKRs have a kind of quarterly cadence for refreshing them is really healthy because of that.
Kit Friend (00:52:55): Personally, I don’t think it’s massively practical to refresh all of your OKRs every two weeks, so like, quarterly definitely feels achievable. And like, whether it’s with safety program increments, or like, the natural quarterly cycle, and budgets and things; quarterly feels about right for teams, especially larger teams to do sort of strategic thinking refreshes. I think if we think about the contrast between like a Waterfall organizational approach where there’s this massive weight on an annual planning cycle, versus more of a rolling horizon, where people are kind of given a polite nudge every quarter to reflect on things and build that back further. I think it’s really important.
Jenny Herald (00:53:33): Thanks, Kit. So we’re going to switch to some quickfire questions. If that’s good with you.
Kit Friend (00:53:38): Yeah, let’s do it.
Jenny Herald (00:53:41): What do you appreciate most about your team?
Kit Friend (00:53:43): I think the ability to teach me. I love feedback from my team and being pleasantly surprised. I guess I shouldn’t be surprised. But I’m always pleasantly surprised when people teach me things that I didn’t know I’d be teaching about.
Jenny Herald (00:53:55): What was your greatest dream and it’s associated deadline?
Kit Friend (00:54:00): I always wanted to be a dad. So, I can’t remember not wanting to be a dad. So having little people to provide extra meaning to my world was always there. I didn’t think I had a fixed deadline in mind to things, to be honest, for that one. But I guess I kind of... I felt like I’d kind of done with being just me relatively early in my 20s. And so I yeah, I wanted little around with things. But greatest achievements, joint achievements, not done on my own fairly, obviously, was having little friends.
Jenny Herald (00:54:31): What’s your idea of the perfect company to work with as a consultant?
Kit Friend (00:54:35): I kind of think but it’s lots of. The bit i love about my job is being able to work with different organizations, a combination of organizations on a constant rolling basis. I never failed to get attached to my current client and be like, “Oh, I’d like to be there forever,” and then every time something new comes along, I’m reminded that I like to change and I like something fresh coming through. I always talk about like the greatest privilege, being able to take that knowledge and learning from one place to another and hopefully, provide a cumulative benefit by spreading that wealth.
Jenny Herald (00:55:08): And this is the last question. What would you say was the greatest experience you’ve had, as far as an Accenture deployment was concerned?
Kit Friend (00:55:19): So it’s really lovely when you launch actual things, right? So I think whenever we’ve launched something that I can go and show people, I worked on that. And like, weirdly, for me as a Scrum master, or an Agile coach, I never make the things. incredibly clever, talented people to do it. But launching products that people can then go and take joy from has been really, really amazing. So working on products for You View, for Channel 4, for the BBC. It was lovely to be able to like show people. Still when I’m training, I kind of put up the BBC website and I’m like, “My team made that bit. The dingly-dangly bell, I know the guy that deployed that thing.”
Jenny Herald (00:55:57): Very cool. Well, that’s it. That was it for this episode of Dreams with Deadlines. Thank you so much for joining us today. Kit, I learned a lot It was super fun talking about Agile about how to measure value and the really quickfire questions at the end. So thank you so much for your time.
Kit Friend (00:56:15): Thank you, Jenny. It was lovely to speak to you.
Jenny Herald (00:56:18): Well, that’s it for this episode of Dreams with Deadlines. Thanks for listening. If you liked today’s episode, please subscribe and share. The show notes can be found on gtmhub.com/radio. If you want to learn more about our product and services, head out to gtmhub.com. If you have questions that you’d like answered on the show, shoot us an email at [email protected] Tune in next time.