[Music]
And I think we’re live. Are we John? We are indeed. Well, welcome everybody. I hope there is somebody out there. If you are out there, drop us a message in the public chat and just let us know you’re there.
Today we’re going to be having a conversation, a discussion about the open guide to Kanban. A truly, and I do mean this most sincerely, although I sound like a movie actor now, but I do mean this truly when I say this has been a deeply collaborative effort amongst a great number of people who describe themselves as flow practitioners or people who care about the concepts around flow and the constructs around flow. I’m sorry they’re not all here today but different commitments mean they can’t all be online at the same time. They’re out earning a living. But I think this is going to be a nice conversation and I’m going to give an opportunity for my fellow colleagues who are on the call to say hello and just to let you know what their thoughts are and then we’ll get into a bit of a discussion about the guide that is now live folks. It is now live, kambanguides.org. Unless I’m wrong, you’ll see a banner going across the screen now. So, it is live. It’s a similar familiar interface you’ll find thanks to our friend Martin who’s done some mastery in the last 48 hours to get that up and it’s available to download currently in UK and US formatted documents, A4 and letter size in English and I’m sure as the community rallies around different translations will start to emerge so they’re more followable in your local language around the nuances of some of the linguistics we’ve had to play with to get a guide that we could reach consensus in the majority of the Kanban and flow communities.
I’m going to stop talking now guys and let you say something. So I could just say just a few words. I want to thank a lot of people who don’t want to be named and there’s a number of people who are happy to be named and so Jim Benson, famous for the lean coffee and personal kanban and also does a lot of work in Obe, Andy Carmichael, formerly from Kanban University, still very much stalwart in the Kanban community, Jose Cassal who’s been in Kanban University and ProKanban and the flight levels community, Magdalena Furlit in scrum.org from Poland, Michael Forny who’s here with us as well on this live stream and of course Martin Hinchelwood who is a wonderful reviewer but also enabled us as well to have open discussions. So on the website that we’ll look at later on, you can actually contribute to the discussion and Martin was basically the architect of that. We’ll talk more about that later.
In addition, we basically had Christian Neverdal as well. He’s a PKT, a ProKanban and someone who does this stuff all the time. So he doesn’t just train, he’s consulting all the time, just like a lot of the reviewers here. Nad Talai as well from Kanban University, also from the safe community. Steve Tendon from the Tameflow community, author of many books and of course here our wonderful Nigel Tuttler here on the screen as well. So really looking forward to sharing this document with you. Martin, I’m going to hand this over to you next if you want to say a few words.
Sure. I think one of the things that I, apart from doing reviewing the document which I was all very honored to do, I wanted to help leverage my technical skills. I think I’m the technical one in the group from a software perspective to help enable a greater community around the document. So we’re leveraging GitHub. Many of you might not be familiar with GitHub. It’s not as hard as it sounds, but it does give us a bunch of capabilities that are great. One is that all of the document is in markdown, in text, in source control. So if you want to fork the repo, it’s probably something that you will figure out how to do, but copy it, make changes, and send us requests for changes. That’s super easy to do.
Even better than that, it comes with a pretty leveraged discussion forum capability built in. So we can have discussions, we can debate over different topics and as other guides have done, maybe that results in meetings and live discussions as well when you need to hash things out and then somebody can make the changes and submit them and it’s not all on the people who were part of the original group. Anybody can go and fork that, create changes, specifically for new languages. So one of the things that we’re able to support is that the whole site is multi-language, not just the guide itself. So one of the common barriers is how do you find your language on a site that’s predominantly in English if you don’t speak English, right? So the whole site is translatable. And we also maintained all of the existing content from the previous Kanban guide documentation. So they’re all available on the site, including the translations from previous versions are in there already as PDFs at the moment. But if folks want to come along and turn them into markdown, we can have the whole site in French with all of the history of the Kanban guide as well as the new open Kanban guide.
And I think that that openness is really important. It’s kind of akin to open source. It’s not really open source because it’s a document. It’s creative commons. It’s more in that context. But the more community engagement we can have, the better I think the document will be as well.
Thank you Martin. Michael, could you say a few words as well, please?
Yeah. I find passionately the fact that not being a native speaker myself, I understand that a lot of community might struggle as Martin mentioned but what we’ve seen right in the when we were reviewing the documents and sharing we received an overwhelmingly number of requests of translations. So I think that that’s a very good symptom that the spirit of this initiative it’s already out there. So people want to participate, want to help or want to be helped finally in their own native language. So the fact that this is from the community to the community I think it’s really really powerful and we encourage everyone in attending the session today also to speak with others that couldn’t, spread the word and finally get a common ground to stop fighting about stuff and start understanding each other.
You know I’d like to say something on that. I think that’s a key point, this stop fighting with each other as yeah we all enjoy the echo chamber on LinkedIn and other sites to, you know, duke it out and have a bit of fun and give an opinion and stuff but the fact that you know the fact you could bring me, I said this earlier when we were chatting before we went live and saying that you know I could have sat on the sidelines and keep throwing rocks and calling BS on things that I had problems with in previous Kanban and Kanban discussions because of my Toyota roots and because of my training in the sort of TPS world. Or I could get involved and I could give an opinion and have a conversation and have a discussion. And the fact that the theory of constraints folks and some of the Kanban University folks and other people who see the world differently to Nigel and Nigel only sees the world Nigel sees it. It’s not that I’m right or it’s not that I’m wrong. Us to have a lens of perception is a huge achievement that we all managed to get together and we found language and there was some nuancing and people will look at the guide and say yeah but you could say this like that, you could say it like that but think about this is a huge amount of people that have come together, almost all the key proponents and actually have said we can find words we can live with.
And when I did my old Lego serious play stuff years ago, we make like shared models, you know, shared mental model type thing. And it was, you don’t have to agree with everything, but can you live with it? And that’s where I found myself. There’s some great words in there about Toyota and about lean thinking and some of the things I’m passionate about that everybody can live with because they don’t disagree. And we found words that expressed it. And it’s the same for me when I look at some of the measures and metrics that are sort of the same thing with different names. But that’s okay because if it’s familiar to you, use it. It means the same thing and you’re getting the same result and the same outcome and that’s okay.
And I think that, and you know John and I have had a lot of spats over the years, public as well as private, a lot more in private than in public. And this I’ve expressed opinions, you know, that eight out of 10 cat owners might express. Old English joke there. And but we managed to sit down and say there are things that we can discuss and agree on because it’s important for the general community and the practice. We’re practitioners and contributors. There’s people out there just are users of the system and they just want something they can use with utility to solve their challenges and help them in their what are often very complicated and sometimes complex environments. And we need to stop fighting and proving we’re the biggest guy in the room or the biggest mouth in the room. And we’ve done that. And I think that’s a huge achievement. And I thank John for doing that, which you know, I’m biting my tongue hard here now. I thank John for doing that. But and I think the fact that so many people have come together from so many different, you know, factions if you like or so many different views on the world of flow and created something that’s very practical, got great utility. The language is relatively easy to follow and when translations come we’ll get even easier and we made an appendix of stuff that everybody wanted to talk about which you can use if it’s useful to you and say I’m familiar with that and I’ll go use that because that’s valuable to me. It’s not a you must do all of this stuff. And I think overall that’s a huge achievement for us all to come together and do that.
Indeed. Yeah. It was it was a pleasure really to build bridges, wasn’t it, between these communities and we tried to use language that feels a bit awkward but also more straightforward at the same time. For example, people talk about work in progress or work in process depending on your community. And we had a comment a few days ago, well, isn’t that work that started that’s not finished? People kind of understand that a bit more, you know, there’s different language about how things take, you know, is it flow time, is it lead time, is it cycle time, and all sorts of arguments about that. And so, well, it’s elapse time from started to finished. Everybody understands that. So, when’s your started point and when’s your finish point? And of course, you could have more than one starter point and more than one finish point. And there’s a lot of good stuff in Kanban Guide. We built on that. But also what we did as well was we tried to achieve more coherence as well. And yeah I’d love to hear more about that Nigel from you like in terms of like some of the things that would have bothered you before about Kanban guide and maybe I wouldn’t say they’d be resolved but like as in you’re feeling a bit more comfortable maybe about what we have in this document now.
Look, you know, you mentioned started, finished, which is a really important thing because people add things into a backlog, an intake, a queue, whatever, wherever you receive your requests for doing work from, whatever you call that. And the thing is this, once it’s received, once it’s known to you, it’s work in progress. Work in process. So, progress and process for most people is synonymous nowadays. The manufacturing world tend to talk about process and I talk about progress. It’s just so just to take that as it is. But the starting and finish concept is because one of the big bug bears for me is that and Little’s law talks about this and other clever people out there that once the work enters the queue, enters the line for Americans that don’t get the word queue but once you enter, sorry I live in Texas folks, once work is actually in the queue to be done it’s in process, it’s now work in the system and you count it from that point and as work transitions from step to step, stage to stage, I don’t know, column to column, whatever language works for you, there is a queue at each step and you know, even on back in the Toyota days, you know, said Kanban is a compromise and the effort here is to remove kanbans because kanban is a signaling card. It’s a signal for work or for inventory or even for transportation. But the more of them you have, the more inefficient your process is. So the idea is to reduce the number of process steps so things flow more quickly. Ideally to do, doing and done, you know, to coin a phrase, but there is more than one doing column. And if there’s more than one doing column because of the linear nature of your process, then there is more than one waiting state, more than one queueing state. And it’s important to measure all of those if you want to find where the constraints are in the system and to deal with those. So I think that that for me was a huge clarification in this work and I think you know that’s one of the big things that stands out for me. I have a whole list here but I want to yield to some of my colleagues who may tell me the things that stand out for them.
Yeah. So Michael what’s done what stood out for you actually? You were one of the reviewers of this document and what did you notice actually the first time you saw it for example and maybe what you think about it now.
I think that something that wasn’t stressed enough before was value, measuring actual value delivered. There was, probably I got it wrong myself, but it was too much about the process of optimizing the flow and not enough focus on the value delivered thanks to these optimization. So when we talk about, and it’s more on the why we do this, right, the how is very important but the why and the feedback loop that we can trigger is essential because otherwise we will be, as we say in my country, very good in driving a sport car, right, on the wall, right, and we need to drive it safely. So the value, the clarification of the metrics about value, the fact that we’re there to bring value to our customer, I think that’s an additional part that also could break some of those misunderstandings for those who say, oh, you know, I don’t like Kanban because it’s not focused enough on value. I think it always been but it was not so evident and clear to everyone else. So in the appendix where, on top of the, let’s call it traditional or standard metrics, there’s more focus on these additional metrics that can be useful or not, depends. So your context will tell you if that makes sense in your context and maybe could be an invitation. Oh, have you ever thought about it, maybe you should consider them, right? And another point, you know, very contagious if you want is, previously you cannot even mention lead time, right, as if it was a bad word and my understanding was, oh, you know, nobody gets a common agreement or what we mean by that so instead of deep diving and try to investigate what we should mean about, I’ll just, we don’t just mention it, it’s not a metric, but the end to end is essential, right? So the level of detail I think that we are providing to the readers to choose the best definition that suits with them, with their situation, where they want to achieve it, it’s giving this guide in my opinion more an holistic view.
I would agree Michael. I think it’s given it huge value and you know I was just scanning down as you were talking and because of that appendix which has a lot of conventions and additional measurements in there that as you say people can use in their context whatever works for them. But the whole definition, we found ways to make things that people argue about simple to understand and one of them for me, favorite one was stable system because we talk about system stability and we can all argue about what is a stable system, what is a cause of instability and how to measure that and this then, trust me, I got loads of opinions on that, but as we said in the guide, put simply, a system that can consistently meet the demand placed upon it, I mean to me, that’s a stable system. I mean in Toyota people would agree with that and most other people would agree if we’re meeting the demand and the systems function, it’s stable. Can it be improved? Probably 100%. But it is stable and so things like that really really help me to support this. And of course as John’s showing on screen now, tact time is in there and I pushed for that and you guys all said this was okay and the language was consensed. I’m not going to beat this in this webinar, but the fact that that was there so people who are familiar with that or people who are unfamiliar with it can go look, probably I want to learn a bit more about this, but it gives them an opportunity now to do other independent research and be introduced to terms that might be useful or people who know them and choose not to use them, that’s okay too because it may not fit their definition of workflow and I think that’s a key thing. John, I might invite you to mention that, talk about the definition of workflow.
Yeah. Because I think, and like the definition of value and the definition of workflow, I think they’re two really important concepts irrespective of the rest of the content that everybody really needs in a working environment.
Yeah, I can certainly talk about that. So, let me just share the section. So, very much in keeping with Kanban guide, we just, we thinking in this guide, we talk about not just coherence with what was happening before with Toyota and so on but also everybody talks about, you know, outcomes and all that kind of stuff and of course a lot of people would say, well, the quicker you deliver outputs, the quicker you get outcomes and there’s truth in that and actually there’s a kind of a thinking error in assuming that it’s all about outcomes but because if you’re too slow with those outcomes, you’re dead, right? So, this guide is trying to get that balance right about how do you optimize your flow and how do you get that balance right between efficiency, effectiveness, and predictability and so in your definition of workflow when it’s visualized, that’s essentially your Kanban board. And you could have more than one definition workflow on your board as well, which is fine. You might have multi-level systems or you might even have different item types that have different workflows. And so that’s okay. You can visualize that if you want to. And so we’re saying, well, you know, what are the units that go across the board? If you’re in a software world, you might be using new stories or something like that or bugs or tech debt, things like that. If you’re in a marketing world, you might have different types of campaign going on and so on. And then depending on the item type, you’ll have a started point and a finish point. So, when does the clock start and when does the clock finish? And for some teams, it’s like when I took the work in. For other teams, it’s not when I took the work in, it’s when I actually started doing the work. And I don’t personally like that because that’s not very customer oriented because maybe you’ve been thinking that you were only working on for three days. Yeah. But we told the customer two months ago we started, they think it’s already started. So, you could have different clocks running, you know, doing different elapse time clocks, start to finish and so on. And so, we tried to use different language. Yes, we appreciate a lot of people are using work in process, work in progress and so on, but essentially we’re talking about work that’s started but not finished. Started according to your started point and finished according to your finish point and that can be wherever you want it to be basically.
You need to say how work in progress is controlled and we were very nuanced about this subject actually. We had lots of debates about this because in essence if you think about it when you’re using work in progress limits, essentially you’re just trying to contain the deluge of work coming in to the system and are there other ways where we can really genuinely create pull, you know, where when people ask for stuff we actually do the work and when people actually start work when they’ve actually got the capacity to start it. I often see people saying, oh, I’m going to start that today boss and they put into in progress but they can’t start it because they’re working on something else. So like bring it in when you’re ready, you know, when you’ve actually got capacity to work on. So little things like that. We talk about that. We talk about different ways that you can control WIP as well. Also we give some examples as well about some policies. I love the little bit we brought in kind of going back to where this all came from. You know, why would you let bad work go downstream or as Nigel would said into the next process. You know, why would you do that? But we’re being explicit about that. It’s not just about optimizing the flow, but also can we, I’m not saying get it right first time or anything like that. I’m not saying that at all, but can we do a good professional job? So we’re feeling confident it’s not going to come straight back on us.
And we still think that you should have a service level expectation. It can be based on the history of your system. It can be based on a selection of the history. It can also be based on a guess if you don’t have enough data. And it’s based on your previous history. So like if you do have history you would know how much the previous work took but we can’t really say that what happened in the past is going to happen in the future. So some health warnings around that as well. Okay. And then of course you need to visualize that as well. So this is probably the most important part of the guide I would say. It’s like this is kind of like, you know, what you, you don’t really have a workflow unless you’ve got these properties and we have some recommendations on metrics and measures as well and there’s courses and practices that we want you to follow just like in Kanban guide. We want you to control the amount of work in the system. We want you to ensure that you don’t let work rot on the board. You should have a rotting in progress limit, you know, of zero. Nothing should be rotting on the board. And you need to kind of resolve impediments as well that cause block work to move on you. So you need to actively manage the work, make sure work doesn’t get, and then of course you need to improve the flow as well. You need to not just improve the workflow, improve the flow of value and so we define value in this as well. We define stakeholder, define lots of things but remember lots of Kanban system members, they can only do so much. So people who demonstrate leadership we call leaders, not necessarily managers, it could be leaders and teams as well. But we like to see managers if they exist doing what Nigel will call Genchi Genbutsu, go to the source, collect the facts to, you know, get the right information so you can make some good decisions and do it so often that the truth actually emerges. Don’t do like a what I call a royal tour, visiting once a year and everybody’s putting on their makeup and they’re, you know, I’m brushing my hair unusually and all that kind of stuff, you know, trying to make sure that it’s real, that actually people find out what’s going on.
So I don’t want to break your flow there, pun intended, but I think this is a very important section for leaders or people who are in senior executive or management roles and may call themselves leaders to think about because this is their active participation. This is where they get involved in their phrase, they lean in to go figure out how to improve the system because a lot of us in senior roles will complain that the system isn’t functioning optimally, whatever that means, and it isn’t delivering the outcomes and outputs we want. But they do very little about really getting involved to understand how we do what we do, how the work actually gets done. Which brings me to the other points that I’m really pleased about in this is that first of all we declare that Kanban is a strategy for optimizing the flow of value through a system and we say it is a signaling system to call for work or inventory which is the basic concepts or constructs behind the way Toyota used this but it’s, we want to optimize the flow of value so that we’re making a clear statement on that and in the appendix in the conventions you’ll see that the definition of kanban from Japanese means signboard or billboard and is a visual cue that triggers one to select i.e. start or move a work item. Nothing should be produced or move without a kanban signal. Now it’s not, the Toyota folks will tell me yeah but there’s a few nuances missing there. But the idea is this is to show that this is ostensibly a visualization approach. It’s a way to signal and also to see. You can see the work and if you make your boards effective you can see how the work flows through a system, good, bad or indifferent and leaders who choose to come and look at that will actually be able to see where the challenges are, the constraints are, all the opportunities for improvement are. So at its heart that’s what it is, we’re signaling how work gets done, we’re focused on the flow of value and I think these are just the key aspects that most of us who are in this flow sort of centric industry are trying to achieve most of the time. So I’m really really happy with a lot of the work that’s been put into this.
Thank you very much Nigel and I’d like to have a chat with Martin actually about a question that popped in if that’s okay. So it was a scrum question, and maybe Martin you can have a go as well. So I would like to add a perspective from scrum and kanban. When I pull an item into the sprint during sprint planning to forecast I’ll be working during the sprint, I consider not started items as items not pulled into the system on WIP. Now it depends. So we mentioned earlier that you can have more than one starter point and more than one finish point, right? So if you’re using scrum, you’ll probably have a started point for like you brought it into your sprint backlog maybe and your finish point might be, well, you met your definition of done and heaven forbid you don’t, I hope you, when your definition of done is releasable but if it wasn’t, there was something else going on in a downstream process, you might have another finish point for when we really actually released it and got feedback and so on. But actually, I think people miss a trick when they use scrum and kanban when they just use kanban for the sprint backlog piece. You can really be looking upstream and downstream is the kind of way I kind of like to describe it. Martin, I’d love to get your perspective on this. What are your thoughts on it?
I think it’s quite a common issue to run into, especially as a lot of the tools that provide metrics around this don’t really, they’re not really adequate. My background is Azure DevOps. I’m a Microsoft MVP of Azure DevOps and it doesn’t do this part very well out of the box. All the data is there but getting it out is a little bit difficult. You’re into PowerBI realms or third party tools there. You want to, as Nigel talked about this earlier, as soon as it hits your backlog at all, it’s started work, right? So you want to have the timer start there, but you also want to consider the wait time that it’s sitting in your sprint backlog waiting to come into that sprint itself, but you also want to consider that you might not do. Right. Your sprint backlog is a list of opportunity. I’m going to phrase it that way just for fun. It’s not no guarantee that something you put in your sprint backlog is actually going to get delivered at all. So there’s perhaps a started finished moment for a particular team where they’re looking at, we want to understand the stuff that actually goes through our system versus things that wait there, but Nigel will pull me up for, you can’t ignore that wait time. Right. So I’ve been channeling Nigel a lot recently and things I’ve been waiting for. Yeah. Martin’s even built a Nigel bot I believe. But I don’t know why you would do such a thing. I have a chat GTP Nigel bot that allows me to ask it questions.
It’s a really good point and this is where the design of your workflow, i.e. your board, your visualization becomes important because is this prioritized work we’re expected to work on in the near term and if it is, it’s started, it’s in the queue, we start the time because you got item age as one of the measures in the kanban approaches so it’s aging, somebody said do this and it’s in an order to be done, well you haven’t started activity on it but it is waiting to be done, it’s in the system, so Little’s law, that it means it’s being measured from a throughput perspective. But so we need a way to distinguish this from all this other stuff. Now in the old days and days of Y, I used to have, I still have a column on my board behind me says ice box. It’s stuff I had an idea about that I’m not actively working on. It’s not really in a queue. It’s not been processed or prioritized, but I don’t want to forget I thought about it. So I put it in this cold storage so I can go look at it occasionally. Go, am I going to move? Am I going to prioritize that? Is that going to become a thing? So I think it becomes the decision of the people in the system to, and that’s what it says in the guide anyway, to determine how best to handle that and how best to measure the work. The problem with an ever growing backlog, and a backlog is never ending, it’s always growing, it’s, you know, people can add to it as scrum will tell you, is that when you know it just start, you get to a point where you just got this infinite queue of work and thing and if you look at the Kingman equation, and again theoretical mathematics and stuff and I’m no expert genuinely on that, but it says, you know, if you start to add things to the queue and you start to overutilize the people, which is another thing we deal with in the guide about WIP limits and what they’re actually meant to do, is meant to prevent overburden. So not meant to max out your capacity because if you max out your capacity, the queue eventually becomes infinite. So new things coming into the queue will just never see the light of day or will take eons to see the light of day. So people who start to practice these things need to look a bit about queuing theory. Think about the designs of the boards. Think about where, how things are categorized and then measure the things that make sense in your context.
Yeah. I just wanted to add to that, that the way the system is also a lens that you look at the work through, right? So there’s the system from the perspective of potentially this group of people doing the work, that might be your scrum team, and what they care about is when they actually bring it into their sprint backlog and they’re going to start it. That’s what they care about. But then you’ve got product management who are looking at the wider system, looking at, well, the customer asked for it here and we’re delivering it to them to production all the way over, oh I’m not in the view, all the way over here and they care about that time but the scrum team’s time is only this small piece of that. Ideally you want to broaden their story so that it’s part of the better story but you’ve got the realities of where you are, right? So I think it’s a great question and I don’t think it’s just a kanban for scrum teams thing. It’s just a kanban thing. It’s the holistic flow thing and all the kanban guide for scrum teams is really trying to do is take these ideas around flow and give you perspective on them within the context of scrum.
And scrum itself has that narrower focus in general, right? From a guide perspective, it has that narrower focus on just the scrum team, not the wider organization, although we do often widen it out. You know, there’s a question from Tom. I’ll put it on screen. And Tom’s a stalwart in this industry and a big influencer to a lot of us in this and this work indeed. How can we track the quantity of a particular value like usability or security? And we, it’s not an easy one to answer. John will probably find something relevant in there, but you’ve got to be careful because you’ve got quantification measures and quality measures. So a lot of the approaches are used are quantitative, these probability forecasts and things which are discussed in the guide without using any particular naming. But the quantification is what most people are doing. But we need qualitative metrics. I was speaking to some doctors and surgeons this week on a different broadcast and it’ll be out in some weeks time about the fact that a lot of measurements in the health care system are quantification. You know, number of patients seen, number of this, number of that and that’s great but it talks nothing about the quality, the quality, the value that’s coming out of the system. So we do need to start to look at, you know, if something like usability is a quality measure, security you can go both ways on that, it’s risk mitigation, it’s risk avoidance so it’s qualitative but what about the quantitative side, there’s different measures. So I’m not going to profer an answer because I’m not the world’s expert on this but again depending on your context and what it means to you in your definition of value, which we talk about in the guide, understanding what value means to you and what value means to your stakeholders, your consumers, your clients, your customers, whoever they are in your context because it will vary, the whole internal external sort of discussion about who’s receiving the value. You need to look at how you define that and then find the appropriate ways to measure that. The guide gives you some suggestions. It’s not a mandatory list of things you must do. Nor is it a comprehensive list of things that you can do. So this is where people need to understand their workflow, understand their context, understand what makes sense in their world, use the guide as what it’s intended to be, a guide, not a recipe, not a prescription.
Yeah, thank you very much, Nigel. So I’m a big fan of Tom’s work and I was telling the story about this only yesterday when Tom was consulting up to about 10 years ago, I believe. He went into a CEO and he asked the CEO like, “What’s your most important project?” And Michael, you were there. You heard me talking about this. And the CEO would say, “Well, this is my most important project, you see.” And so then Tom asked the CEO what’s so important about that project and so the CEO wrote down what was so important about it, you see, and so Tom asked the CEO to bring in the chief whatever officers, you know, marketing officer, finance officer, all these officer people and they came into the room, it was like we were in person and so on and I think it was Tom asked so what’s so important about this project and could you write down please what’s so important about it and they all wrote down something different, they use words like better, you know, weasel words, you know, and I give people a little prompt actually you can use on any LLM, you just say if anybody tells you that you’ve got a clear objective or a clear goal or a clear requirement just write in your favorite LLM, tell me the ambiguities in the following text, colon, or sorry, using Tom Gilb style SQC specification quality control and then you put in your text and it will drive a lorry through your requirements, or truck, what you call it in Texas, truck, a semi, semi is another word. So I’m a big fan of quantification for that reason so you need to have a will to try but we talk about both quantitative and qualitative because there are some things that are difficult, like for example cooperation is difficult to, when you have a relay race, who gets the credit if you win the race? Is it the person who passed the baton or the person who received it or it’s like, there’s no mathematical equation to tell you that. So, but it doesn’t stop us from trying Tom. So, I hope that answers that one.
Got a few other questions as well. One of them is from Mike Levian just going back to here. And so, the Kanban guide 2025 was also released recently. Yes, I was involved in that myself. Would you see any contention between the two guides? No, actually, what we’ve done is we just built on it really. There are some things that are a bit different maybe, different perspective because you’ve got different voices and this is an open guide so for lots of communities whereas maybe there was a slightly narrower view in Kanban guide but it’s building on it. In fact on the site open guide to kanban you can actually see in the history section you can see the previous versions of the current version of kanban guide 2025, you can see the translations as well for the previous versions like December 2020, July 2020 and I have offered actually to the translators if they want to put their translations and some translators saying yes they want to so we’re opening our arms to people in prokanban as well to use the site as well and contribute to this as well and all communities actually.
So yeah the next question is a bit more prickly I think. I’m curious to know if you’ve had any feedback from Dan Vacanti and Pratik Singh beyond simply citing them in the guide. All I can say is I communicated with Daniel on the 10th of June what I was doing, that I was going to fork, but it’s not just me. It is a collaboration. It is a collaboration amongst multiple people. So, and you can do that. It’s open source and all that. So, hopefully we did a good job with the creative common notice. And by the way, because this is going to be an open document, it means if you spot bugs in terms of how we did things or what we said or no, I don’t agree with that formula, I don’t agree with that description, you can log a bug. It’s completely fine. It’s open source. It’s a little competition. How many bugs can you find per page? Because we kept finding bugs on it this morning. So, I’m sure you’ll find something. So, this will be updated more frequently as well. So hopefully that helps. Mike, thank you for the question.
I think it’s a good thing to point again at the link on the kanbanguides.org goes to the GitHub repo that backs it where everything is and there’s a discussion forum on there to have conversations about some of these ideas. And the any issues that you have, perhaps a discussion is a good idea to start with, right? Sometimes it’s not the right idea to just create a bug out of the gate and say this is wrong because perhaps, you know, perhaps it’s, I’m channeling a little bit of Nigel here, perhaps you’re just wrong from your perspective, right? And have some other eyes on your idea. But once you do come to a consensus, you can make the change yourself and submit it to us and then we’ll hopefully bring it in as quickly as we can as long as it’s relevant, pertinent, and there’s probably another word in there that I’m looking for that I’m not good at those words, but a good change, right?
Yeah. Thank you very much. And actually, it was a real challenge, wasn’t it, putting this together. I guess my job was kind of curating all the wonderful ideas from the different communities that are out there and often I say things myself that when I go to write it down it’s like is that really true and I often find things that I used to say when you write a book you challenge yourself, when you write a guide it’s oh my god is it really really true, you know.
John, I would invite people who know my work and my background with Toyota and the years I was very lucky to be taught and trained by them and also the conversations I have around Toyota’s production system, lean thinking and various discussions of that, there are a lot of people in that community who could now get involved if they disagree with the way I’ve worded something or the way I’ve tried to channel my training over the years into some of the nuanced words. They also are invited to participate in this to help us evolve how to use these techniques that originated in Toyota, that inspired others like David Anderson and others to adopt some of these ideas and bring them forward. And if you think that some of the nuanced language could do with improving or there’s something that’s missing or something that’s misworded, you now have an opportunity to contribute. You have now opportunity to go to the website, grab kanbanguides.org as it’s on the screen now, go and get into the discussion and contribute an improvement, a fix, a suggestion or have a bit of a conversation and a debate with the people in there and that will help us to improve it even further.
My focus here, my effort was to try and explain the distinguish, how we distinguish Kanban in manufacturing from Kanban in non-manufacturing, so-called knowledge work, not just software development which has been used in of course a great deal, and to nuance that, the difference between push and pull systems, that’s in there, what a WIP limit describes versus how Toyota pulls things and how they self-regulate the system and we’d like to see self-regulating pull systems in there. These are the things we’d like to see emerge. The guide doesn’t say you do it this way or that way. It gives you some suggestions and guidance as in a guide, but it does tell you that in your context, it would be great if you could do some of these things, but it leaves that open for you to do that. So have anybody in the community that are considered lean focused practitioners, Toyota focused practitioners, the people who I looked up to as leadership and who taught me over the years and others I still collaborate with. If you want to make it a little bit better, this is your now opportunity to do so.
Thank you, Nigel. Michael, I’d love to get your perspective as well. I think you had a couple of topics that you wanted to bring in. The floor is yours.
Yes. Especially for those who might have been pushed back by the Kanban stuff, they did not understand and maybe there was a lot of concepts that were not explained in brick layers theorem as they say in England. I think this guide helps to understand more what we’re talking about. Help us to break those barrier and those misunderstanding. Oh, this is just for manufacturing. No, it’s not. Takes a lot from that, right? It’s an important DNA. But what struck me probably from the first reading was that part where is written you don’t need to start with everything but if you don’t want to start at least start from here. So the starting point, right, a lot of people struggle in getting things perfect before even starting. Start where you are. Start making a difference, right? Start reducing by one day your delivery time. It’s already an improvement and move on from there, right? So the fact that this guide helps you also to orient yourself in a world that might seem, and that’s my personal opinion, slightly from the academia, difficult to understand, not for me, or stuff like that, probably will bring more people to give themselves a chance to read this, to understand it and scratch your head and say, you know what, I can grab some of this stuff and use it to make my team’s life slightly less miserable, right? I’m not saying making their life perfect, but you know, when I introduce flow with my teams, and I’m blessed to work with humans, not too much AI at the moment, but they, I think they need more simplicity than complexity. They need their life to be simplified. So these concepts can resonate very well with their day-to-day experience. So when they see something, right, when they visualize their work, especially in the scenarios where we’re in, they’re not lucky enough to be in the same room, right? So having a board that tells our common story is essential. And if you don’t have a visual radiator that is telling what is happening and is not triggering the right conversation and does not help you to monitor what’s happening, how can you expect people to deliver value or to understand what not to do to work, right, to maximize the work not done, intercept waste before it becomes waste. All the concept that people that come from the lean and the kanban might find second nature. But for some people it’s brand new. Oh really? Right. The simple things that make big changes. It’s something that not just in the academia, not just in the training but in the actual activity as consultants that we try to make people’s life much better.
You can really find, I wouldn’t say solution, but definitely tools and not just one hammer for everything, right, different tools for different scenarios depending on where you are. So I think that’s something that might struck and I would encourage people to give it a read and find something useful for them, be a little bit selfish if may say so, right, help your people, taking in what works for.
Thank you so much Michael and I saw another question came in as well about security, about, you know, what you do about, for me, for example, information security and risk, right, so one of the things that I love about Tom’s work is it’s almost like you’re starting with who, you know, we’ve all seen the video, start with why, the golden circle and all that, and there’s some elements of truth to that and there’s some elements of questionable, but I still find that a useful video nonetheless. You know, it excites people. But really, I think for me it’s about who, like who are our stakeholders and we define stakeholder. It could be internal, external, customers, end users, decision makers, governance people, whatever, right? And we’ve got these stakeholders and each of them has expectations and they’ve got limits as well, like one of the stakeholders might actually be the law, actually might, we often say, “Oh, it’s the lawyers.” Well, that’s what Meta thought and then they got a 10 billion euro fine from the European Union, you know. So, the law is the law. So, like who are your stakeholders? What do they expect? What are their limits? Which stakeholders are more valuable than others? And people will often tell you, oh, I want a secure system. And you know what? Having a secure system, I mean, even this website we have today, making that 100% secure, do you want to know what the cost for that is? It’s infinite. Infinite. So, do you have an infinite budget? Because I don’t. This is a collaborative exercise, right? This is on a shoestring. We’re a bunch of people who care about the community putting things together. Very much with the support of Martin here, getting us up and running with the website and so on. Really appreciate that. So, like in all honesty, what would happen is people say, “Oh, I don’t want any hacks.” Really? So no hacks ever? Or would you be okay with, would you tolerate maybe one hack every five years or is it, would you tolerate one every six months actually or is it more about we don’t mind them getting in but actually what did they get access to and can we close it down quickly, you know, things like that. And so what I love about Tom’s planning language, language for short, plain two world planning language, is you quantify, you say what’s the number of hacks, for example, what’s the meter, well the number of hacks reported on our internal dashboard or what’s spotted by our AI system seeing people getting in. Okay, so what would we tolerate? What’s tolerable? And then what’s our goal? What are we aiming for? Well, we’d actually be okay if you only got hacked once a year, you know, and if you actually look people in the eyes, they might be happy with that. And then, you know, what’s the stretch? Well, we only get hacked maybe once every 10 years or something like that. So you can quantify because if people assume that we only get hacked once every five or 10 years, then don’t be surprised if your budgets just explode because you’ve just goldplated what’s been asked for when really we would have expected less. So actually quantifying those is very important. So just having the will to have that conversation is really really crucial I think.
You know something, John, that’s where the, you know, there’s a huge debate about probability forecasting, you know, and we won’t dive too deeply into it here, but the area of risk management is where things like Monte Carlo simulation and probability forecasting comes in. So, if you are in an area where you’re trying to manage risk, and I’m fortunate to know people in risk, then that’s an area where that should be a greater focus. And that’s, we’re not going to give you the solution in this guide. We’re going to give you a guide to be able to use what we think is valuable. And I think now you’ve just, there was a question from Casper actually. I think you just put it on screen a minute ago. Awesome. And it comes to that because I was reading that while you were talking and, you know, if I’m interpreting this correctly, you know, it’s talking about the challenges, the friction, the constraints, whatever words we want to use in the system. And whether we, you know, we’re using scrum or agile or waggile or whatever we call these things in the old days, but the reality of it is, and this is why I think what we’ve created collectively is so valuable, because if you visualize how work gets done, all that stuff is transparent and as Russ said earlier, 100% transparency is crucial, we can see it all and then we can start to ask questions and in the guide we talk about, you know, helping people to get the right answers more rapidly. There’s language in there specifically, but essentially if you can see the workflow, you understand every step of how you do the work, this stuff becomes visible and you start to have the conversations to deal with it. And there is language in the guide and I’ll find that so we can pull it up in a minute. But I just wanted to sort of speak to this point because what Casper is saying is what drives people bonkers in the real world. But the answer to this is to make the work visible. Once you can see it, you can have a conversation about how to deal with it. And there is language in the guide specifically about that. John, I’ll hand back to you.
Yeah, thank you so much, Nigel. There’s a question from Ross actually. So who do we see as the audience for this? And maybe I’ll go around the room on this actually. I’ll go to Martin first and to Michael and to Nigel and I’ll give my own comments as well. But curious to hear your answers folks because we’re all from different walks of life. So we have different perspectives. That’s the whole fruit of the collaboration really. There’s different perspectives. I’m very curious to hear your answers. Martin, what’s your perspective on this?
Yes. Unprepared response. I think that in general for me the guide is a tool for practitioners to help them engage with other people. I think it’s definitely a tool for everybody, right? But I don’t think it’s discoverable for everybody because how do you find it if you don’t know it’s there, right? And if you don’t know that flow is your problem and most people and most teams don’t know that flow is their problem. They don’t understand what flow is. They don’t understand there’s a whole mathematical thing around flow that’s not just making [__] up. It’s actually understanding mathematically how work flows through your system. And I feel like that this is a great guide for practitioners to use in reference to, some of it is a little bit of lending credibility. Sometimes you need, you know, we’ve all been in this situ. I would, I guess many people in the chat as well have all been in the situation where you go into an organization to tell them what they already know. And that you’re bringing a little bit of external credibility to that story. And if you just have one person talking about flow, if you just have one person using those words, and that’s why it’s so good that the guide is in layman’s terms, is in plainer language than a lot of the reference material out there. That you can point people to this guide. You can use the language that we’re using in this guide to benefit the work that you’re doing with your customers. And I think that’s for me is the core audience for this is practitioners and then they will use this in ways with their practitioners. I don’t know the story.
Thank you Martin. Yeah, Michael, what’s your perspective?
Yeah, to me, I see a very very diverse audience, could be the newbies, right, that might have read other guides and found hard to understand because there’s a lot of unsaid or taken for granted or even expert practitioners that would like to dive deep into something, like, you know, tact, just to mention one, they might have heard it but I never find a very simple and straightforward explanation of that and it’s perfectly fine if it doesn’t fit with your system but what it does and maybe you could decide to apply it and propose it but also as a conversation starter and something I really liked it is that whenever something is mentioned and is referring to something outside, may it be systems thinking or other thing, there are references so it’s a starting point, it allows you also to build up a scaffolding system where you can start your personal journey in expanding your knowledge or use it with your team, probably as a trainer, can also be a good element to sediment concept and again as we said, simplify the language. So in short, the audience I think is wider than might have been probably before and this would also make more people comfortable to say, you know what, I read this, I think might be interested for you rather than, oh, you’re doing scrum, now you should be doing kanban, that’s why, right, maybe there’s these things that you can apply in your current scenario, it doesn’t mean it’s either or. So yeah, probably the audience is more wider than probably might have been intended for other guides before.
Thank you so much, Michael. Nigel, very interested to hear your perspective as well.
Sure. I like the word scaffolding that he just used because in some of my work on complexity and stuff, we talk about scaffolding being a temporary structure we put in place to support learning, to support whatever we’re trying to support. Some of it may stay permanently because it becomes part of the system or others can be removed away. So for certainly anybody starting out trying to find the way to manage work may find some utility in what we’ve described. When we talk about, I’m going to flash up a couple of things and I posted some of the, it came up as you so it looks like you’re making these statements but that’s good. These are copy paste from the guide. So if we read this, the strategy of Kanban system is to enable the system members to ask the right questions sooner as part of a continuous improvement effort. And then later on we talk about, as you mentioned early, genbutsu, which is the Japanese phrase which is go and see without assumptions, understand what’s really happening where the work is done and take action. And there’s some words on there. I won’t read it all out and people can read it and grab it off the video later. But the whole point of this is, so who is the guide for? Well, it’s clearly for people that are starting out wanting to manage workflow in some way. Be it software, be it something else. It’s clearly for people who want to visualize that workflow and understand where the opportunities for improvement are. Whether you call it kaizen or whatever or constraint management, it’s there for you. But this says managers, leaders or people who call yourself a leader or who have characteristics of leadership who control work in a managerial way, then that’s something that this guide suggests that you get involved with. My advice to people who start to use this to help them in their work using kanban type systems is to make that section visible. It’s the improving flow section. Make that section visible to your leadership, managers, people who tell you what to do so that they see they have a role. And if they read nothing else in the guide other than the statements about what is flow, what is value, demand management, they read that paragraph, that will be valuable and will help us. So I think that primarily yes, people who are using it and practicing it but people who are managing the process, the system and the people who are practicing it need to be shown it so they can see where it’s relevant for their role in helping the system improve.
Thank you, Nigel. And I’m not going to duplicate what’s a lot of been said. I agree with everything that’s been said by my colleagues here. My own kind of lens on life is coherence. And so we can have kanban system members doing great things. And if you think about it, what we have in this guide is really a coping strategy for all the craziness that goes around. If you have a team, all the craziness that goes around, the overwhelm of too many things being started in the organization and if you think about it in scrum, the product backlog is a coping strategy for all the nonsense. You only bring in what you want when you can bring it in. And similar here with the open guide to kanban as well. And there’s lots of strategies for dealing with that. I think one of the things that Nigel talked about is really close to my heart as well which is how can we make sure that there’s more understanding about what’s really happening in the system and some people talk about, you know, it’s okay to be on the balcony as a manager and there’s a lot of merit in that, you can see what’s going on but there’s also a lot of merit as well in just getting down on the floor, rolling up your sleeves and putting on your Wellington boots metaphorically and understanding what’s really happening because you’ll often find that you’re asking the teams, you know, saying I want more, I want it now and I want the quality up but actually is that coherent and so this guide is trying to do a couple of things, is trying to help people who are not in any of the existing kanban communities or flow communities, they’re not even aware of this, they think kanban is when you don’t want to do anything else, you just visualize crap on a wall, forgive my language, so we’re trying to say, well, it’s not that actually, there are some minimums, there’s not a lot that you have to do in this guide if you’re going to use kanban but we’re trying to say actually this is what we really mean and we’re trying to reach beyond, so it’s an open guide, so we’re trying to reach beyond so that we’re using language that we think everybody understand, you don’t have to be a kanban nerd, we hope, to understand what’s in the guide, we’ve also got lots of definitions and if you disagree with anything, of course, you know, you can debate with us in the discussions and we can do a follow-up and so on. So for me it’s about coherence, so what are the kanban system members dealing with, also if there are managers, is what are doing coherent as well with what’s going on in that exactly. It’s not just a board full of post-it notes and Jira and so on. That’s not really what we’re talking about. It’s about having a balanced system, a balance between capacity and demand. And we’ve got lots of suggestions on how we deal with that as well.
So yeah, I also want to bring some attention as well to some of the people that we’d like to acknowledge as well because this is a fork of Kanban guide May 2025 version which I was involved in of course and there’s many people who were involved in all of these different versions and history and so on and they deserve credit. A lot of them don’t want to be named and I understand why. But there are some people who were happy to be named at the time. For example, the July and December 2020 versions of Kanban Guide. We had John Paul Bailey, Jose Cassal, Colleen Johnson, Todd Miller, Eric Neaberg, Steve Porter, Ryan Ripley, Dave West, Julia Wester, Uvalure, and Deborah Zanki as well who was involved in editing that document. We were driving poor Deborah crazy, I remember. But it was really cool working with Deborah and very grateful for that. Then we have the May 2025 version where there were some additional reviewers including, for example, Mike Delena Furlit, Tom Gilb, Colleen Johnson, Christian Neverdal, Pratik Singh, Steve Tendon and Julia Wester and we had more reviewers than this but the people who were happy to be named for the open guide to kanban were Jim Benson, Andy Carmichael, Jose Cassal, Magdalena Furllet who said hello to us earlier, Michael Forny who was here, Martin Helwood who was here, Christian Neverdal at a Guns and Roses concert and I really, I think that’s a good decision, much better than being here, but he would love to have been here today. Nadart Talai as well who’s been a mentor of mine actually, he reintroduced me to Kanban, believe it or not, in 2015, I kind of dismissed it a bit 2010, 2011, thought yeah whatever and Nad brought me back to the trough so to speak and Andy gave me a lot of mentoring as well so very grateful for their putting me on the right path. Steve Tendon, if anybody remembers during the pandemic all these live streams, everybody was bored, I was doing loads of live streams and I think we did 10 hours of video with Steve Tendon and Nigel who’s here as well, of course, and many other people, many influences, people who probably don’t want to be named here at all, very fed up that we even named them. How dare you? What we’re saying here is look, people who are acknowledged here do not necessarily agree with what’s written in this document, and that’s okay. We still owe them a massive debt of gratitude and we’re very very grateful to everybody who was involved. It was a very very intensive review the last few weeks that I think it’s been about three weeks that we’ve been working on this roughly.
You know John, I think it’s an incredible achievement to get Steve Tendon and myself in the same document agreeing. So I’m sure, I’m just, go on, and it’s open so anybody can come and disagree with us and submit their suggestions, discuss, collaborate with everybody else and figure out what’s next.
No, I agree John. I think we’re at that time.
We are indeed. Yeah. Just one comment on Casper’s things there. So he said evolutionary. Yes, that’s its bias. That tends to be its natural stance. That doesn’t stop you from doing big changes. So if you’re in a situation where you have what I call layer cake teams, you know, if you’re an IT backend, middleware, front end, dependency hell, all that, maybe you realize after a while, maybe we need to restructure, you know, so like we’re saying, you might need to do that, depends on your school of thought and so on, where you come from. There could be other things as well, maybe the performance management systems need to change, maybe the finance systems need to change because the way we’re budgeting and so on. So we’re kind of hinting at that as well in this document. So it’s actually not all small changes. So we think actually we could use kanban for doing something much more as well.
So yeah, thank you very much everyone for joining in the discussion today. I think what I’d like to do now is go around the table for the final words and I’ll start with Martin again. Poor Martin is always getting stuck the first time, then we go to Michael and Nigel to maybe close us out today. Thank you so much gentlemen. Martin, over to you.
I want to reiterate just based on a few of the comments that Kanban and scrum are not at odds with each other. They are complimentary practices. They work together really well and you may or may not like scrum, right? That’s perfectly okay. But they definitely, I don’t have a single scrum team I’ve ever worked with that I don’t also recommend looking at and using flow metrics and flow monitoring and understanding your flow. And I think it’s great that if you want to translate the guide, if you want to be involved in that process, not just making changes to the guide, you might not have anything you want to change, but you want to contribute in some way. Perhaps you could try help translating the guide into another language. Perhaps you could just participate in conversation and discussion. If you don’t see the conversation, if you’ve thought of it, like writing a blog post, right? If you’ve thought of it, probably somebody else has got that problem, too. So, ask that question and collaborate on figuring out what works well.
Thank you, Martin. Michael, over to you, please.
Yep. For me, I think is an invitation to start a journey. That’s not the end of the journey. That’s the start of the journey. Even if you think you’re an expert, even if you think you’ve discovered everything, this gives you a fresh reread and you can validate your thoughts or question them, introduce a little bit of value, array and maybe thinking out of the box is just for software. Is not, is for systems and the people, people go back into, right, what I really love about Kanban is that you ask people to make those changes that can improve their own life every day, right, make that change, be vocal, observe, that’s why transparent 100%, so if you see something that doesn’t look right, raise your hand and let’s change it together. So the human side to me I think is very very important, so the journey and the human side. Thanks.
Thank you so much, Michael. Nigel, over to you, please.
I’ve said so much on this broadcast, but I think that this is an invitation for people to participate. I think it’s an opportunity for them to learn things. I think it’s an opportunity for them to apply some of the thinking and ultimately to understand that all we’re trying to do with flow, as it says in the guide, is to foster a smooth and balanced system to create value. This will help you in that direction.
Thank you so much Nigel. Really appreciate you coming on today and thank you everyone who contributed to the document. Thank you for all your comments today, Martin. Thank you so much for getting us set up on the website. We were on the website a lot today, weren’t we, Martin? And Martin’s been doing lots of things in the background. Absolute hero. Thank you so much. You always ask me just in time.
Yeah, sorry about that. We were still finalizing the document this morning. Okay. Yeah.
So, and Nigel, thank you so much for being willing to collaborate. Yeah. Our conversations haven’t always been easy and yeah, big respect to you for finding a way to work with us on this and to find a way to help people actually and there’s lots of arguments going on on social media, but we can get together sometimes. We can agree on some things, can’t we? We can find a way to help people and really appreciate the coherence that you brought as well from a Toyota perspective and the challenge that you gave us as well during this whole collaboration as well. Really appreciate that. And Michael, your reviews all the way through this as detailed as ever. I really appreciate you. You helped me as well with a recent guide as well. And this one, your feedback has been phenomenal. I really enjoyed, by the way, working with Michael on retro Lego serious play. Anytime I do a PSM class for scrum.org in London in person, Michael turns up and because Nigel was talking about Lego earlier, that’s why he had a Freudian slip. So, Michael turns up and does his thing and it’s amazing and he helps my training to get better and he’s helped me a lot actually over the last couple of years. So, I really really appreciate and for everybody involved. The document is there. It’s for you to look at. And we hope you enjoy it and if there’s anything that you want us to improve, please let us know. It’s collaborative. There’ll be lots of discussions. Sometimes there’ll be a little bit too much noise going on because remember we’re people who have a day job as well and you know this isn’t being funded by some major corporate or anything like that. This is like just a few people getting together. We’ll do the best we can. Sometimes what we do is we write long form articles to just try to make sure that when we’re having debates about things that we’re talking about the same thing and we invite people to calls as well. So when we feel there’s a little bit of friction going on, we’d like to set up some Teams calls or Zoom calls or whatever to whatever platform you’re using so that we can kind of understand your perspective more because sometimes it gets, that gets lost. Nuance gets lost a bit sometimes. Yeah, Gary was there as well when he was trained as well as one of Michael’s retro Lego serious play trainers. So yeah, thank you everyone for joining. So, thank you Nigel, thank you Martin, thank you Michael, thank you everybody for being here and we hope you enjoy the document. We hope you find it useful and if there’s something you don’t like, join the discussion and maybe join the discussion before you go on social media. I had a recent document, oh, I am only halfway through the document. I just like to say, well maybe you should finish reading the document or I haven’t read the document yet but this is what I think. No, yeah, I got one of those the other day as well.
So read the document please. This is shorter. It’s manageable. So you know just go through it and we put a lot of thought into it. So if there’s something wrong the best place to talk about improving it is on the site. There’s a join the discussion section. That’s a much better place, much more constructive than, you know, getting clicks and all that kind of stuff in social media. And you can still get the clicks by the way because what you’ve probably noticed already is that there are contributors already on the site. And so people who contribute get recognition. So you contribute something, you’re also a contributor to the document. So, you know, that’s a healthy way to maybe help the community. There’s too much arguing. Let’s try and help people fix problems and let’s try to win, not win arguments. So thanks everyone and yeah, we’ll leave you there and thank you so much for your time and looking forward to hearing what you think. Thank you so much everyone.
Thanks.
