In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Ian Spence about improving software engineering practices using Essence as a pattern language
Key Takeaways
- Many practices are locked up inside methods to make them difficult to apply without adopting the whole method – method prisons
- Describing practices and frameworks using a common pattern language frees them from the specific methods and allows them to be in different approaches
- The first rule of scaling is do not scale
- Essence is trying to achieve a common ground, a vocabulary for talking about software development
- When practices become popular, most people will do them incorrectly
Subscribe on:
Transcript
Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down across the world with Ian Spence. Ian, welcome. Thanks for taking the time to talk to us.
Ian Spence: Thanks for having us, Shane. It's a pleasure.
Introductions [00:52]
Shane Hastie: So you are with Ivar Jacobson International, and you recently published an article on InfoQ around Better Scrum with Essence. What I'd like to do today is to explore that with you. Let's start off. Who's Ian?
Ian Spence: I'm clearly from the UK. I've been in the industry for a long time. I started off as a developer. I've done most jobs in my time. I was at Rational when the UML was taking off, which is how I met Ivar. That's how I met Dean Leffingwell, and many of those luminaries, I contributed to the rational unified process for my sense, and when IBM bought Rational, it looked like a good time to go and leave that fold so we set up a small consultancy company. And then Ivar also left Rational, so we joined forces a long time ago and we were looking at Agile was clearly the thing happening in the industry and what we wanted is we wanted people to be able to be agile with their way of working, not just about the people being agile with the people, not just about being agile with the products, but being agile with the way of working. How can you have, and to continually improve and inspect and adapt, the way you are doing things.
Method Prisons [00:52]02:06
Ian Spence: And Ivar likes to say, and from his recent article in InfoQ, quite popular one, escape the method prisons. So Ivar was the father of the Unified Process, which became UP, but he sees how these things become a trap, right, and you can see that possibly with some of the frameworks that are going about. How do you keep going? If you choose a framework, how do you keep it fresh? How do you empower teams to be agile with their way of working at the same time as all the other stuff? Because if you don't, that's often the trap that people fall in. The process zombies and the frameworks on bees and all that kind of stuff. So Essence was something that started when we wanted to do an Agile version. We actually did a thing called The Essential Unified Process a long time ago, but we made a mistake of not freely revealing it to the world.
Ivar thought, at the time, you could still charge people to read process because that was his background. But the ideas for that, the way we did it by turning it into practices so you could plug and play, so the unified process was iterative and had Use Cases in it. But if you want to use Scrum, why can't you take out that iterative bit and plug Scrum in? I know many people have used Use Cases with Scrum, including Mike Cone and Jeff Sutherland, I know, personally told me they've both done Scrum with Use Cases. And Scrum is a well-formed example of something that stands the test of time, right? Because it keeps itself to itself. It doesn't need you to do user stories or anything other than the Scrum bit, and you plug it in. So we wanted to basically free the practices, right. Ivar's big contribution is Use Cases, and Use Cases are still incredibly popular and as a practice can help.
Freeing practices from methods [03:46]
Ian Spence: Many Agile teams recently did a meet up online and there was me and Mike Cone talking about Use Cases and user stories and how they could work together. So if we can get the practices out of these traps so that you can use them, and that when you use them you are actually connected back to the source and not to someone's reworking of it. They're rebranding, rebadging, and things like that. We should be able to achieve great things. We can have global communities of practice. We can reward the people who actually created them in the first place. We can keep them up to date, keep them moving with the times. It's all about that kind of stuff, so you don't have to pick up a whole method. You can build things out of practices. Frameworks still have a role.
Well, I am a SAFe fellow and SAFe is a fabulous framework full of guidelines. I also do Scrum at Scale with Jeff Sutherland, another good framework. One of them tries to give you an answer to every question, because asking you to do things and not giving you a way of doing them can be quite difficult, and that's what SAFe tries to do. Whereas Scrum at Scale leaves it for you to decide what backlog items you're going to have and lots of other things in there, and it's great. Some of the Agile fallacies and hypocrisies you see are, are amazing. People blame SAFe because people don't do what it says, right? How SAFe leads you to waterfall, it clearly doesn't say that, right? I've read every article that has been dismissive of SAFe and I've yet to see one that's factually correct. I'm not going to tell you where you could attack it, but no one's spotted them yet because they never go that deep. But yeah so, this idea that if you didn't give them the guidance, they would naturally do the right thing. No, they did the wrong thing then as well, right, so there's all kinds of stuff. So we wanted to free this, make things easier to play with, more accessible, and all that stuff.
Shane Hastie: What is a more accessible, freed practice look like?
A language to describe practices [05:38]
Ian Spence: There's a couple of things going on in Essence. If we talk about this, there's a language, so there's a standard way of capturing practices. And that would be useful because everyone writes down an event in Scrum, an activity in one of the others and stuff, and it'd be nice to have a language. There's a language for doing those. There's a kernel, software engineering kernel, which defines basically the extent of software engineering. What you need to do software engineering, the essentials to software engineering, but in a way that's completely practice independent. And then there's the practices, and the practices like Scrum, Scrum comes with the Scrum guide. Scrum guide is good, but it's quite hard to interact with. It's something you read. I think I said, my favorite quote from the article was about this very problem.
Blaming the practice for bad implementations [06:28]
Ian Spence: Scrum is great. It's lightweight. It's simple to understand and difficult to master. That's what they've always said, and many teams that are using Scrum, I mean, Jeff has been quoted saying 58% of agile teams are not delivering on the promise of agility. And many of those will be using Scrum, so it's simple. It's easy to learn. It's difficult to master. So what most teams do when they adopt a new practice, is take two days to learn, two months to screw it up, two years to abandon it. And when it goes wrong, it won't be their fault. It'll be the practices fault, and they'll gayly move on to the next one. They'll swap Scrum for Kanban and then they'll do Kanban badly, and then they'll move on to whatever the flavor of the day is that they can get away with. So what we do at the practice, and here I have, well, I have in my hands, some Scrum cards that Shane can see, but the rest of you can't.
Describing practices as patterns [07:14]
Ian Spence: We put the items on the cards so there's succinct definitions, stuff of the connections. They are typed according to the language, and we can put these into people's hands and we can play games with them. And there are games for learning, right, and proving your understanding. There's games for tailoring and composing the practices. There's a lot with the Scrum practice, a lot of games for retrospectives, and we can have other practices. So in the Scrum scale family of practices, The Scrum Essentials, which is a literal translation of the Scrum guide. Everything is 100% with the Scrum guide, and Jeff uses the cards in his training courses and he uses it as a glossary as well. And you can play lots of games. You can challenge people to build their own Scrum. Here's the pieces, put it together. Interesting. Somebody once said they learned more in one hour doing that than they had in six years of doing Scrum.
So it gets people interactive. Very good for teaching from the back of the room. But there's loads of things you can do in retros, and there's decorative practices. There's two other practices. There's a Scrum foundation, which gives you a health check for the values, the pillars that underlie Scrum. A great way to bring those into people's focus because they forget those. And another practice we've done with Jeff is a Scrum accelerator, which are 15 patterns that Jeff believes lead to hyper-productive teams, right? And again, these are presented as cards, but you can play games. You can plus them in, you can select which ones you want to do, switch them on and off, have discussions about them. So this is a good way just to give you a different way of approaching Scrum and the Scrum guide. Now, without the Scrum guide, the cards wouldn't be very useful because they wouldn't have that theory and stuff, but as a compliment they're great. They make this an active thing, and in the Essence language, you can actually have executable practices. There's lots you could do if and when the tooling becomes available, but at the moment, mainly we're playing games with the physical cards. So that's great for Scrum teams, and that's what we were talking about. List is a lot of the games in the article, but have you read the Scrum at scale guide.
Shane Hastie: Personally, I have seen it. I have not read it yet.
Ian Spence: The first law of scaling is don't scale
Right, so if you like the Scrum guide, because it clearly tells you what values you're going to have, what events you're going to have, what artifacts you're going to have, you will find the Scrum at scale guide is very different. It provides a way of looking at scaling Scrum, and it says that if you scale Scrum, you will need scaled versions of the artifacts, the events, the accountabilities. It doesn't give them to you. So we've built two practices, one for Scrum of Scrums, and one for executive Scrum, for using Scrum to run a business or a business unit or your Agile bubble. And the reason these are two practices is that the first law of scaling is don't scale, right? So you might have a small business with half a dozen Scrum teams, all independent. Executive Scrum would help you run that business better.
And what those cards do is they give you the scaled versions. They give you the scaled versions of the events, the artifacts. They give you the ones that are missing when you scale, right? So Jeff would say, when you are scaling, you should have a vision. There's no vision in the Scrum guide, but there is a vision in Scrum at Scale, so it fills in some of those holes. So then you get different sets of cards so you can play games about, okay, Scrum at Scale, Scrum of Scrums. We need a shared backlog for the product. A shared product backlog and in Scrum, teams should have a product backlog. Okay. We've got two cards in play now. Well, are we going to have all the teams draw from the shared product backlog? I take away the product backlog, have the teams just draw from the shared product backlog, that's one pattern. And that's what less would do for example, or are we going to have a shared product backlog and each team has their own backlog, so they get their own stories.
What does scale? [11:01]
Ian Spence: That might be more useful if the teams are looking after microservices or something within the product, so they can connect directly with their users. If you like SAFe, for example, you might say, yeah, we'll have a shared product backlog and we'll put features in it. That's quite valued from the scale point of it. Oh, we'll call that our product backlog, so each team will have a team backlog and we'll put stories in it. So I did run a course this week, played a lot of these games, and in three hours we taught about scale Scrum using the cards, right? No preaching, just by, okay, here's Scrum. What would you have a scaled equivalent of if you were scaling? All the values, we'd hold onto them, but would we have scaled sprint planning or just sprint planning?
Would we have a sprint backlog? No, no. That's one of those fixed things that doesn't scale, but product backlog and things like that. And then we'd show them the components of Scrum at scale and they move the cards and the tokens onto that framework, the Scrum master cycled the product out of the cycle, and try and join up to the executive action team and the executive meta Scrum, which are the two hubs for the cycles in Scrum at scale. And then they can start to play the Scrum and Scrums factors if they want, or the executive Scrum go. I think we should have an enterprise backlog. Here's a card. So it brings it to life, and you have real, practical discussions about what you are doing, rather than bickering over what the name should be, for example.
Essence cards freely available [12:25]
Ian Spence: So those practices are available for free. All of the Scrum practices, they're available in what we call a little card websites. You can have the cards on your phone as a reference. You can get free PDFs, so you can make cards to play games. You can get templates for many of the games that we've uncovered already, all for free. And the idea is that then you can start playing around, being agile with your method. Ah, right. That should be a chief product donor. What do we want to call it? Well in SAFe, they call it product manager. What are we going to call it in our organization? And then, well, in our organization, we call it X. So if we use Scrum at scale, oh, the chief product owner is X. They can take on that accountability. If they're doing SAFe, then ah, that would be product manager.
Helping to identify a common vocabulary [13:08]
Ian Spence: But you can keep the commonality you have, to a minimum, right, and achieve some common ground. Because the other thing Essence is doing is trying to achieve a common ground, a vocabulary for talking about software development. Now each practice is its own name space. You'll never avoid that. There are practices that do completely different things but use the same words for those things. So we're not trying to set ourselves up as the police, vocabulary police, but there is a kernel and the kernel defines the essential things you have. It has checklists in it, so you can do health checks and things like that, and it allows you to plug things in and find that overlap. So there's not a lot going on here, but you could just practice individually or you could start to build them into a method, a software engineering method, or you could have other kernels for other kinds of endeavor, right?
And that then takes the practices and makes them more real. Connects them up. And you can do governance and compliance in a practice independent way, and really that's what I believe a lot of organizations need to do because you can then focus your governance on the outcome rather than the work product and stuff like that. We have checklists, but they're for the outcomes, right, so we look at stakeholders. Do you know who your stakeholders are? Are they in agreement? Have they got a clear need? Have you got an opportunity? One of the elements in the kernel is opportunity. Now I know many people who build software and they have no idea what the opportunities. Field of dreams Agile, you've seen the Kevin Costner field of dreams film, or know about it. That is the business plan for many Agile teams. If we build it, they will come, right.
Agnostic Agile [14:44]
Ian Spence: Well, if you look at what they're doing through the lens of the kernel, you might find, actually, we don't know what the opportunity is. Wow. How are we going to do that? Then as a coach, you could suggest some practices and there's many practices for doing that. But the kernel lets you see what's going on and see if what you are doing is sort of in balance and healthy, and if you want to, you can line them up. There's an interesting thing I've been thinking about, agnostic Agile. Are you familiar with that? They're very good friends of the Essence community and people keep telling me they're agnostic Agile, but they don't seem to understand agnostic. You see, shouldn't really talk about God, but there you go. I am agnostic. I do not believe in the existence of God or the non-existence of God. If there's some evidence for God I'll be fine, if there isn't there isn't, but I don't believe. I'm not an atheist.
I don't believe in the non-existence of God. Most people who call themselves Agile agnostic are actually framework atheists. They don't believe in SAFe, right? No, because if you've truly agnostic, you will realize it's a useful tool; very useful tool for organizations in certain stages of their Agile journey. And you will also know that frameworks are starting points, not end points. They kickstart your Agile journey. I don't think anyone has ever failed because they picked the wrong Agile framework. Picking the wrong Agile coach is a different matter, right? But if you pick the wrong Agile framework, it will shine a light on itself and you will inspect and adapt it.
Shane Hastie: Taking a truly Agile approach.
Taking an agile approach to adopting agile approaches [16:12]
Ian Spence: That's the truly Agile way, right? But lots of people who say they are agnostic, they're not. They believe in their own one, you know, stuff like that. But Essence is completely agnostic, so if we could get all the practices, people could assemble them into practice families, right, and give you frameworks and starting points and stuff like that. That would be cool, but we'd like those frameworks and starting points to be take out this practice, put in this practice, and so you can understand overlap and the relationships, and that would be good, but very hard to convince someone. So like Dean, there's a good idea for him to break SAFe up at the moment, a lot of economics in it for him. But over time, unless this has been going a long time, but there's a lot of hope out there. Jeff's contribution has been immense. His promotion and allowing us to put his name on these practices has been a huge help, and hopefully we'll get more of that going forward, and we'll have more practices. The person who is the moral owner of the practice can provide the training and certification whatever, we're not interested in that. We're just interested in them being freed so that they can prove themselves.
When practices become popular, most people will do them incorrectly [17:20]
Ian Spence: And we can understand when they're the right practice and when they're the wrong practice to use and market forces can, hopefully you can move away from faction and get a bit more towards evidence, right?
The Scrum thing is interesting. If any practice gets popular, Scrum, SAFe, RUP, any of these practices, any of these things, even little ones, when they get popular, most people will do them incorrectly, right? There's more bad Scrum out there than good Scrum. There's more bad SAFe out there than good SAFe, and there's more bad user stories than good user stories, more bad Use Cases than good Use Cases. Any practice that comes popular and goes beyond the innovators and the earlier adopters, who will typically do it by the letter and then move on to something else rather than persisting with it, they persist with some, it's going to end up hitting the similar numbers.
Most people not getting it right, and we firmly believe Essence is a tool to help people get better with the practices, better Scrum with the Essence cards. It's not just hype. It gives you tools that coaches can use and change how you track and hopefully get better Scrum, and if we had a Kanban practice, which there are some possibilities that that could be on its way, it would help as well. And then you could actually find out what the differences are between them and how they work together, and even went to use one over the other, if we can debate that, but it'd be nice to have the Essence of those practices from the sources, and then we could plug them into the kernel, see where they complement each other, see where they overlap, see where they have different names for the same things, that kind of stuff. And hopefully people would be able to be more successful and create new practices, which they can then feedback to the community. That's the overall picture.
Shane Hastie: Thinking of the audience who are listening to this. Software developers working in Scrum teams or working in some sort of an Agile team, because almost all software development is done using some form of Agile and I would pose it that a lot of it is tragile-
Ian Spence: Fragile, agile, tragile…
Shane Hastie: There's lot of that. But if I'm working inside a team and I'm hearing what you're saying here, and there is this concept of the Essence and we can look at cards, we can pull this out. How do I have the conversations within my team, and then outside of the team about, okay, let's look at what we're doing?
Essence as a tool for coaching and leading change [19:48]
Ian Spence: So at the moment, this stuff is really for Scrum masters, coaches, people who are trying to improve and change things, right? It's useful for developers because they don't have to read very much, but they're not upon the audience for Scrum taxes. They'd be more interested in DevOps and more technical stuff, but for Scrum masters, it gives you ways to engage with the team that are lightweight, quick, efficient. You don't have to preach. We had a phase where we named every game after a card game. So we have a game called practice patience where, basically, take the elements of the practice and say how valuable they are to you as a team and how well you think they're doing, and that then triggers ideas. Now, if you are a Scrum master and they don't like the key pieces of Scrum, well, you've got a challenge on your hands, right?
So if they see no value in that, okay, well what are we going to do? Maybe we should try a different practice, if they've really turned against it, but if you're a good Scrum master, you will say, we don't have sprint goals. Why don't we start having a sprint goal and look for things like that. We have the Scrum foundation with the values in, so maybe it's issues about courage and respect. They can self-assess so we can gamify a lot of those assessments and we have more patterns you can join, so they're a useful thing for a coach. People who've got hold of the cards, many of them, they carry them around. They make their own, they carry them around, and they use them to do interventions, retrospectives, and help teams, and it makes it much more interactive. We have neural templates people can use and things like that.
But process and practices, ways of working are not something that people look at every day, but it would be nice to be able to check whether they're doing the essential things and take a look. You can use the kernel to see if the overall endeavor is healthy, do we know the opportunity. And we use these things as great aids for coaching education and training, they’re brilliant for training courses. Jeff does exercises with the cards on all his courses and the exercises were transferable to the modern age of remote training, whereas lot of the exercises people use in our job, we all struggle. The Scrum ball game, it's not going to work over zoom so much. They could maybe make a funky video while we throw these. We look like we're throwing the balls around, so a lot of those things, I mean, Jeff used to like an airplane game to show how things, but we created exercises with the cards and game balls that gave that activity, got the discussions going in a different way and focused on the practicalities.
Using Essence on the Square Kilometer Array [22:13]
Ian Spence: What does it mean to do these things? How often should you do them? How are they connected? So it's very useful in those ways. Now there's a lot of potential for tooling and other stuff, but at the moment, it's really about getting the practice into the hands of the coaches and the trainers to do more teaching from the back of the room, more gamification, and help have a different way of getting that message across. That's it's real role at the moment. I am privileged to work on the Square Kilometer Array. Square Kilometer Array is the biggest science facility man has ever built. It's the huge radio telescope, and I love it because they're very open. Wikipedia, you can look them up. Normally when you are doing cutting edge technology, you're not allowed to talk about it.
I've been involved in some crazy medical things, but I can't tell you what they are, and because I can't talk about them, I've forgotten what they are now. It'd be dangerous to talk about, but this is in the public domain, Square Kilometer Array. It's a radio telescope. It's thousands of dishes in the South African desert, hundreds of thousands of antennae in the Australian desert, and it's going to let us find out things about the universe we've never known before. And it's a huge project. This is going to take them years to build, not just the physical, but the software. And they're building the software Agile. They're using SAFe. They knew they would have to scale and have lots of people, and they're bringing them in from different countries, different cultures, different backgrounds. They needed a framework to line up behind. It wasn't like they had hundreds of people, what would you like to do?
It's like, we're going to get hundreds of people. Let's get them lined up. And they've been doing SAFe. I've been involved with them three or four years now, so a long time. They're doing very well, but one of the problems you have when you are scaling is bad teams don't scale. You won't get good scaling. If the teams aren't good in Agile in the first place. So even in that environment, we've used the Scrum essentials, the Scrum accelerator, the Scrum foundation, to do a workshop with teams where they've self-assessed how they're doing Scrum, self-assessed the values, considered the patterns, and come out after. It's a very intensive kind of lecture, sort of three hours, but they come out, everyone's got a personal action. They've picked some patterns. They're going to try out. They've got some recommendations for things. Maybe everyone should be doing this pattern.
Application in different companies and domains [24:27]
Ian Spence: And they've been having good success with that workshop. And that has Essence cards in it and that's not part of their toolkit, so they lightweight touch. They haven't tried to build a model. Other companies are capturing their own practices. Often companies have practices to make a difference. One company we work with, it was security related. Very strong security practice that they want every team in their organization to follow this practice, so having that as an Essence practice that will play well with whatever else they're doing is very powerful for them. And a lot of companies now they want to have their own Agile framework, right? The Spotify method is a fascinating thing, given that it doesn't actually exist, so a lot of people adopting something that doesn't exist. But what Spotify actually gives you is basically an Agile kernel. It sort of builds on the idea of an Agile kernel, defines some things that you are all going to have, right?
Squads, tribes, guilds, chapters, but allows you to use any practice you like, right, so that's again, a very good fit for the whole Essence idea. We could have the Spotify model as your starting point, and then you would plug practices in and that would be very powerful. And again, we're exploring a lot of these things, but you don't want Ian's Spotify model, do you? You want one from people who've actually been at Spotify, things like that. And that's where the goal is, but at the moment, it's just a great way to make your Scrum better that's concrete, that's available today. You can do that now, and more and more practices, we hope, will come along. If people are interested in this idea, we're open to helping people create practices and making them available. We like to do a lot of charity work in IJI, but this is the legacy we'd like to leave behind.
There's a lot of use in academia as well. The last book Ivar was involved in was a textbook on the essentials of software engineering, written with many university professors, and he is used as the heart of quite a lot of curriculars for universities now. I don't know the numbers. I stayed out of that, so people are coming out knowing this stuff out of some good universities now, and things like that. And one of the university professors wrote a little article on LinkedIn, a little far fact, but he was saying if he was thinking hundreds of years into the future and saying, what out of all the things in my kit bag would we still be using? And the one he said was Essence, but what would the practices be? As we move into a world of 3D printing, of huge companies like Amazon and Google providing an on-demand infrastructure for incredibly secure high performing systems.
Making the ideas freely available [26:52]
Ian Spence: Now the world of software development could change very much. It could become much more of a cottage industry, and there were people now who built fabulous apps that would've taken 10 years to build 10 years ago because they've got maps available from- they've got transact, they've got credit card handling, they've got financial stuff available as services. So we don't know where the industry's going to go. Artificial intelligence is certainly going to make a big change, big data, but the ideas of Essence, of the kernel, are shining a lens on what you are doing, and having practices that you can plug and play with as things change is very powerful. That's what we'd like to see. And as you observed in our earlier conversation, Essence isn't a new thing. It's been around, the EMT standard, I think was 2013. The ideas have been around before that. Many of the ideas have come from people like Ivar, myself, but it was a conscious decision not to patent them or trademark them to make them freely available for people because that's the only way that vision would ever become true.
People don't want to pay to use a language. That would be a bit farfetched, but we hope a lot of very clever people, both in industry and academia, have looked at it and it stood the test of time. And what we are seeing now is a rise of interest, particularly from the Agile community, of the idea with freeing the practices. Some people can plug and play with practices and come up with new ones and share them. Very appealing to the Agile industry and hopefully we can ride on that and get these things coming from the source. And Jeff has been our trailblazer for that. We do have some practices of our own. If you want the Use Cases, we're still the people to go to. Ivar, well, he invented and is the moral owner of Use Cases. I wrote the best selling book on Use Cases, so we have some Use Case practices. Sadly, not as popular at the moment as user stories, but a lot of people still use and still got a role to play, particularly if you can mix and match with others as you go forward.
Shane Hastie: And that's what the Essence gives you, is that opportunity to mix and match. Yep. Thanks very much for telling us these stories today. If people want to continue the conversation, where do they find you and where do they find the Essence cards.
Ian Spence: You can find me on LinkedIn, if you want to find me personally. I'm one of the few people on LinkedIn who has a cartoon for an avatar, so I'm very easy to spot. Ian Spence. If you search me on LinkedIn, you will find me UK based so. And I'm the one with the car team, so if people want to ping me on LinkedIn, we are starting on LinkedIn to put together a bit more of an Essence community around the gaming and things like that. So I can connect you up with Simon who's now taking over kind of stuff because I'm old and winding down. And if you want to get hold of the cards and things like that, the ivarjacobson website has all the Scrum cards available. If you go there, you should better find the Scrum and then you can download all of the cards and you can download the kernel cards as well.
And there is some tooling you might want to have a look at, but you don't need that to use Essence. You don't need any training to use the cards. Go into a room with the cards, play the games, get some insight, and I did that back in the big Agile conference. The Agile Alliance one in the US 2013. I had 120 people in a room for an hour and they used the kernel to assess where a case study was, make some recommendations of what it should do next, and build a governance life cycle, all in an hour with no prior knowledge. And that worked very well and they were very nice because I thought I had trouble because there were cards everywhere, right? Paper, everywhere. I had giant cards. I had sort of A3 size cards up so I said, okay, it'd be really good if you could help me clear up, I said jokingly.
And I turned my back and by the time I've taken them down, the room was spotless. I'm like they were wonderful, cleared it all away and we got three lots of packs of cards, but that shows that you don't need to know about the language or know very much. You will recognize the things in the kernel. And if you do Scrum, you'll recognize the things in the Scrum practices and you will get guidance from the words on the cards and you can play the games. Makes it tactile. You can interact with it, which is the good bits. Now the Scrum guide is something you sit down and read, right? The Scrum practice is something you can stand up and play with. And that makes a huge difference.
Shane Hastie: Well, thank you so much.
Ian Spence: Well, thank you, Shane. Thank you for having me.
Mentioned:
