 Hey, welcome everyone to 40 agile method of methods in 40 minutes 2020 to addition by Craig Smith. You're glad that great and join us today. Thank you, Vijay. Welcome everybody. My name is Craig Smith. I am the global agility lead at soft ed. I'm coming to you from Australia. Also, the host of the Agile Revolution podcast and director of the Agile Alliance as well. Thank you for joining me. We're going to talk 40 agile methods in 40 minutes, the 2022 edition. I did this talk about back in about 2015, I think it was about seven years ago. And there was a reason I did it. I was doing a talk to the scrum gathering and I really just want to tell scrum folks that there were 39 other methods out there. But what it actually turned into was both a discovery for myself, but also discovery for people who saw this, because we sometimes just can't be across all the things that are happening in the agile community. So this is what I'm really going to be sharing with you in this talk is a bunch of agile methods. Now these slides are going to go pretty quickly. Don't worry too much if you can't get the details or try to snapshot it will make all the slides and information available to you. They're very feature rich. You'll have all the links and things that you that you need. So I just suggest you sit back and enjoy the ride and let's see if we can get through this in in 40 minutes. So as I said coming to you from from Australia and yeah really we have to look outside of the methods that we currently use. So if everybody's ready, it got yourself a beverage and some popcorn. This is going to go fast. Let's go. So I wanted to start with the foundational methods and in fact, it doesn't even get a number because it is the basis of everything we do and it's the manifesto for agile software development. We often call it the agile manifesto obviously 17 folks who were just trying to build agile methods back in the 1990s got together for a conference on a mountain top in Utah. And they came up with four values and 12 principles and of course, I'm sure you all know the four values we value the things on the left, little more than the things on the right. And this has been the basis for every method that we will see in this talk today. But also I guess for all Agilis it's the basis to where we go to now we could debate whether it needs to be updated there's some wording in there that probably needs to change. I mean, the word software is always the one that comes up that maybe we should turn it to solutions. But this is at its core. And I think the thing that if you think about this, it's having it's been around for 20 or plus years now is that it served us well and the way that they wrote it still holds pretty much true today. So that's the basis for everything we work on. So let's look at method number one. I'm sure you're mostly familiar with this scrum. In the latest surveys that they've done. This is still the most popular method it's bounced between 60 and 70% for 10 plus years now. It's the most popular method goes all the way back to 1996 it actually goes back even earlier than that you can trace its origins back to the late 80s. In particular, the Harvard Business Review article called the new new product development game where they were just looking at the fact that product development is very much like a game of rugby, which is where the name scrum came from. Now, so much stuff out there. I'm sure many of you are familiar with scrum. And if not the iterative method that's based around it, a lot of other methods use it at its core. Lots of different certifications. It's branched in the last few years. The scrum guide is the thing that holds it together recently updated in 2020. The other thing is scrum is it's really based on small teams. And that's the challenge as we start to scale, but a lot of scaling methods use it at its core. And there are numerous sources for this. The other debate is I guess that there's no technical practices in there either. But yeah, they're recently updated with values, which you can see up in the top right hand corner. It is the basis for most of the iterative processes that are in use today. The problem with scrum is that it sometimes turns what we call scrum, but and that's when if you've ever heard yourself saying in my organization, we're doing scrum, but our sprints are 12 weeks long or we're doing scrum. But, you know, we don't have a full time product owner. And that's really the issue with scrum. If you're following scrum, it's the rules of the game. So what can Shwaver said is we actually need to turn that around and not be talking about scrum, but but talking about we do scrum and and that's when you start to run out of runway and need to have more methods in your toolbox. And that's a lot of what we're talking about today is even if using scrum, you're going to be looking for other things. So think about moving towards scrum and extreme programming XP, not this XP, but you know, the extreme program XP also came out about the same time as from 1996 Kent Beck popularized by the white book as it seems. There was a second edition. I was never a fan of the second edition. This was my Bible when I started my agile journey back in the early 2000s. And I think a lot of people forget if you look at the process up the top that it looks a lot like scrum. It had a very similar process instead of sprints talk about iterations. It talked about release planning. It popularized user stories which weren't really talked about in the scrum guide. So if you're using some of those terms, it's probably because you borrowed it from a hybrid of extreme programming and that's actually where the popularity of scrum came about is whilst it was very good at talking about the process. People use the technical practices, particularly in building software from XP. As you can see there, though, that you can't pick and choose them on the right hand side. The practices, there are lots of them and they all sort of work a little bit hand in hand. It also had a set of values. These practices have just become good software engineering practice to be honest with you, but still surprising number of teams that probably haven't looked these. So still worth a look. The book is still awesome. If you haven't read it crystal crystal is the work by Alistair Coburn goes back to the 1990s. It was popularized by his book crystal clear. Interestingly, however, this was supposed to be a set of books. If you see at the top there, there was supposed to be a whole pile of colors for it. Crystal yellow, orange, red, magenta and blue. And the idea was that depending on the size of your team, which is the axis moving across the horizontal and the type of work you were doing, whether it was comfortable discretionary essential or life threatening would depend the type of crystal that you used and how you used it. But it was it was certainly used or at least a reference a lot back in the day, probably not one you see around now too much. But where you might get some value out of this is there are a lot of things that I suspect that we talk about and we use in the edge of community today that show their roots to Alistair and crystal clear. If you talk about frequent delivery, if you talk about having a good technical environment, if you talk about cross functional teams, they're the languages that came from crystal clear. It's well worth a look if you haven't seen it. One of the popular methods, and this is particularly throughout Europe in the 1990s was DSTM. DSTM again 1994 so these were all about the same vintage. And again, all of these folks were part of the agile manifesto. Again, we've seen this or not the thing about the SDM was there's a lot more structured in aligned a lot more to some of the project management techniques at the time. You can kind of see that in some of the diagrams here had a very clear process. Again, there are things from here that you may not realize that you've been using over the years. If you're familiar with the Moscow technique must have should have could have won't have yet that was described inside DSTM in more recent years in 2016 they evolved this to something called agile PM but it still has the same roots in there. One of the problems in the early days was that you did have to, I guess, pay to join it. It's all pretty freely available these days. DSTM I say it's relatively uncommon. It's actually one of those things that keeps popping along. So you will see it pop up but well worth a look even if you're using other methods because there is a lot of good stuff in there. EVO is probably the oldest technique. It goes back to Tom Gill back in 1960 in a third interview with the Agile India Light Conference. You might have heard seen Tom speak. And yeah, this was the original agile method. Consider this the start of agile. He talked about the Plan to Study Act. He had a lot of principles in here and again things that we considered be good agile practice today. Breaking things down, doing the high risk things early, open-ended architecture. Now remember this was in the 1960s, 1960s through the 1980s particularly. The thing about this is that the book is good. Some of the resources are a little vague to get and a lot of new methods are built on these principles. But if you want to go and take a look back at how this all started, go take a look at EVO. Another one of the foundational methods is RAID, Rabadak Pleasure Development, also Adaptive Software Development. This one goes back to the early 90s, James Martin and his RAID approach. Now he was just trying to look for things at high quality, high speed and low cost, but meeting the needs of users which was a little radical at the time. So as to the name RAID, Jim Heismith picked this up in his work on adaptive software development. And one of the things that really came out of his work was this idea of the loop. And if you've got different stages in your development process, in his book he talked about speculation, collaboration and learning. But if you have cycles that you go through, some sort of discovery then delivery, it goes back to the roots of Jim and adaptive software development. Most of this is reasonably uncommon these days. It was the concept of good enough work. And often it gets back in the 90s, it was a bit before its time. It was considered hack and test because you didn't have the ability to get things out to users quickly. But again a lot of our methods are built on the shoulders of these giants. So there was a lot of early methods, they're just some of them. Let's go and take a look now though at lean methods. And of course the granddaddy is all of the leans, whether we call it lean, lean manufacturing, lean enterprise or the Toyota production system. We can trace our roots to that all the way back to the 1850s and Eli Whitney as part of the Industrial Revolution. It started to get its roots though with Toyota and Tycho Ono in 1936, when they really started talking about the Toyota production system and the House of Lean. And it was James Womack in 1990 who wrote a book called The Machine That Changed the World that made this visible to everybody. So again what you're starting to see is the 1990s were where things were starting to move along. Now of course when we talk about lean, lean is about the key lean principles that you can see up there, the five of them. And also the fact that we put our focus on Kaizen and improvement and carters in having repeatable processes and also removing the mood or all the waste. If you look through lean, there are so many learnings here. Even though it's based around manufacturing, we can learn things in IT and business in general, but you have to get past the manufacturing wording. And one of the things you have to be very open to is gathering of metrics. But despite Toyota having launched this, pretty much every key manufacturer uses some element of lean and it's very prominent in non-IT parts of the business as well. So we've got some sub parts to this, the theory of constraints. This builds upon lean and this is from the work of Eli Goldrack in 1984, his awesome book called The Goal. If you haven't read it, it is a luminary text. If you've ever talked about bottlenecks, we see them in manufacturing. We see them in all sorts of process work is that you can only be as fast as you slow as part of the process. And so being able to find those bottlenecks and increase the throughput is what that's all about. It seems pretty self-explanatory, but being able to identify that constraint and then restructure around it is the key to this. And again, lots of methods and models just have this as part of it. It's well regarded. The interesting thing about the goal is there's lots of things in there that I still don't think we've truly uncovered. So again, it is worth a look. The problem with lean, as we said, though, it doesn't have a technical language. And so Mary and Tom Poppendick in 2003 decided to make them something that was more relatable to technology. And they did this in their book Lean Software Development. So seven principles and 22 tools of taking lean and applying it to software development and a technical process. And you can see there, they've got a bunch of principles where they've taken the same things and turned them around. And in fact, they wrote a number of books past this. All of their books are well worth a look at if you get the opportunity to see or hear Mary and Tom Poppendick speak. They make a lot of this very real. Of course, this is something that we're still trying to discover. And there's been lots of attempts at trying to make this more available to people. One of the more modern ones is the flow system. It just came out a few years ago. Nigel Thurlow, John Turner and Brian Rivera, their ex Toyota folks. Who, again, we're trying to make this more to the type of world that we live in right now, particularly our VUCA type world. So again, they have the house as Lean does, but really a focus on what they call the triple helix of flow, which is complexity thinking, distributed leadership and team science. Some of their principles, I mean, putting the customer first, that flow of value. You can get the flow guide for free. There is a book that follows this. What is interesting though is to really get into it. It can get actually quite comprehensive. They have a comprehensive certification assessment process behind it. But you can get started in order to learn a little more about this and their thinking behind it. If we start thinking about Lean, you know, the thing was it was in manufacturing, but we were starting to think about what does this mean. And all the way back to the 1930s, we can go back to Edward's Deming. Now, I suspect if it hasn't happened already, you will have some speaker today at the conference or the next few days of the conference will quote Edward's Deming. He was a pioneer of his time. And as I said, we're talking about 80 plus years ago now, he came up with his 14 points for management. Now, if you look at the points there on the on the page, we can argue that the language is a little dated. But the interesting thing is that this was agility back in the 40s. You know, even though he talked about things like eliminate inspection, building quality. What that was really saying is inspected at that, right? Quality is important. You know, break down barriers, work as a team. We now call that things like cross-functional teams or multi-disciplinary teams. You know, eliminate quotas and substitute leadership. In other words, self-organization. So the words have changed a little bit, but the principles have been around for a long time. This is nothing new. And we are still uncovering a lot of the things that he came up with. The other interesting thing about Deming was he has the Plan to Study Act loop there. You may know that as Plan to Check Act. He said that he wants to use the word study because it emphasizes inspection over analysis. So he was really thinking about inspect and adapt when he did this. A lot of deep stuff. The nice thing about his books is because they're so old now, they're actually all freely openly available. So you can download them as part of our creative commons or they're out of copy, right? So go take a look at Deming if you haven't read that or discovered it. In more modern times though, we have Don Ryniston and his Principles of Product Development Flow. 175 principles. There's a lot of stuff in here. We're going to be unpacking this stuff for years. But essentially what Don does in his book is he proves why Agile and Lean works. He looks at things like why we should break things down, why we should do things like cost of delay, why work in progress limits are important, controlling our batch size. So all the things that we build into agility, a lot of them come back to this. So if you're ever looking for that evidence or the mathematics in some cases, go take a look at Don's book, all 175 principles of it. Now, ironically, the book has a waterfall on the cover. Also, the book I'm going to tell you now is a little hard to read. I had the great pleasure to meet Don a few years ago. I asked him the question, what is it about his book that makes it hard to read? And he said to me, Craig, my book is like fine cheese. You can only take it in small doses. But a great book, one you want to have a new bookshelf if you're interested in that. Also at its lean roots is Kanban. I'm sure you're familiar with Kanban. The thing about Kanban is that a lot of people only ever stop at the first core property, which is visualizing the workflow. We talk about a Kanban board or a Kanban wall. But that's only one of the five properties. If to be truly doing the Kanban approach, you also need to limit your work in progress. You need to measure and manage your flow. So looking at things like cycle time, you need to make your process policies explicit. In other words, what is the rule from something moving from one column to another and also use models to recognize improvement opportunities. It's based on four principles. Start where you are. Look for evolutionary change. Respect the process and everybody is a leader. The thing about Kanban is that it's a rival in a lot of cases to scrum because sometimes that whole idea of sprints just don't make any sense. But if you're going to move to Kanban, it does require a lot of discipline. If you can do something in scrum, you can absolutely do it in Kanban, but you'll need a different set of disciplines to do that. At the same time as Dave J. Anderson was working on Kanban, Jim Benson and Tony Arnn was working on personal Kanban. They were sort of working in the same space. This is essentially Kanban for your own to-do list, personal Kanban. And it actually just has two rules. Same as Kanban, but just visualize your work and limit your work in progress. And that's important for your task list because we all know we can't multitask. So they've got steps here. It's not about scaling. It's about your own personal thing, personal focus, but well worth a look, particularly for managing your own things and being able to practice agility in your own space. Lean startup. We've gone through this revolution, I guess, where startups, particularly in the late 2000s. And so this was interesting that when this book was published in 2008 by Eric Rees, it was a New York Times number two bestseller. No book in Agile or Project Management had ever done that before. And it was because it laid out how to be an entrepreneur. But what's important is that even for organizations, entrepreneurship is super important. And it was just based on this very clear loop of build, measure and learn and do it quickly. One of the interesting things about the book was that it assumed Agile at the core. So even in 2008, it said, of course, you're going to be doing all of the basic Agile practices. In some cases, people kind of say this has got a little bit of hype on it. And a lot in more recent times, people criticize it because it focuses more on features rather than full products. Again, there's an element of truth to that. But being able to go quickly and just do small things, build the measurement and learn them has a lot of value. Let's take a look at some of the extending methods now. Because sometimes we have things and we kind of want to pull them together or pull them apart. And here's a pile of extending methods that you may or may not have come across. Modern Agile from Josh Kurevsky, Heart of Agile from Alistair Coburn, Agnostic Agile from Sam Zawati are all extending methods. They all take Agility and put a modern interpretation on it. Modern Agile is just down to simple four principles. Heart of Agile the same. Agnostic Agile, a few more principles there, but really saying, hey, let's be Agnostic. And even at SoftEd, we've been working on our own sort of thing here called the value lifecycle, as you can see here. Essentially, all products need to continue spinning through the discovery, delivery and operate loops. There's also been a lot of hybrid type approaches. People putting things together. So you put Scrum and Kanban together, you get Scrumban. If you put XP and Kanban together, you get Zanban. If you put Scrum and XP together, you get Scrum XP. That's from the folks that's safe. So all of these things are putting these together and they can work together effectively. The things to look out for though, just because you're doing Agile doesn't mean that and often organizations fall into what we call water scrum fall. This is a term coined by Dave West from Forrester back in 2011, that essentially, just because you're doing Scrum, how do you look left and right? How fast does it take your requirements to get through? How fast can you get to the hands of users? Lots of all large organizations still fall into water scrum fall. More recently in 2016, Yuta and John Buck, Yuta is talking at the conference today as well. So look out for her. A few years ago, they came up with the Bossanova, which is putting together beyond budgeting, sociocracy and open space for a new way of looking at agility. All hybrid methods. Sometimes we want to know how these things work. And so we have something called Scrum Plop, which maybe you haven't come across. If you've ever sort of wondered the patents because software development is all about patents, well, people have done some work to actually get the patents out of Scrum and that's this program called Scrum Plop. From 2010, Jeff Sutherland and Jim Copplin, they wrote a book about a few years ago and you can go to the website scrumplop.org and you can see all the patents. Now, since the pandemic, it sort of seems to have dropped off a little bit. They used to have an annual conference and of course that couldn't happen for the last couple of years. But still, a lot of these things haven't changed too much over the years. You'll see lots of really good patents in there. A few folks have said, look, we need to do something different with Agile and so we ended up with Agile 2. I'm not sure if we needed it or not, but Agile 2 came out in 2020, 43 principles around agility because look, we need to take a fresh look. Look, I've got to say this, that I think if these guys were smart, they would have came up with 42 principles, which would have been the meaning of life. They missed a geek calling there. Nonetheless, well worth a look. There's some interesting things in there around their values and principles and a look at it. The problem is that in its own right, there's not a lot of guidance here and it's just a bunch of ideas, but still some interesting things and I suspect that this may start to evolve over time. We've also taken a lot of our things that we've learnt in agility to manufacturing and this was built on some work by Joe Justice, originally when he was at Wikispeed and more recently around Agile hardware in his work at Tesla. Now Wikispeed, people don't know is about building a car for the X-Prize and they essentially used Agile practice to do it. Hatscrum Masters did it in iterations and a lot of organizations got very interested in what they were doing. In more recent times, Joe has been working at Tesla and talks about how they apply these practices to manufacturing. So it's essentially Agile outside of IT. He talks about the fact that there's 27 changes a week as part of innovation and everybody gets their hands dirty on the production line, even Elon Musk. If you're looking for details about this, it's not terribly well documented. There's a lot of videos and they're well worth a look. The other thing is that I guess the culture of Tesla is built around this. The thing about factories is it's hard to change those things for experiments very fast and the other thing that's with this is that some suppliers really struggle with the speed of change. But again, it's an interesting experiment in where manufacturing might be going. All right, let's change the pace and let's talk about scaling methods because we talked about Scrum being at the team level but now what we're trying to do is scale agility across the enterprise. And many of you, I'm sure, are familiar with SAFE, the Scaled Agile Framework. It is the most popular scaling method by far at 37% of uptake based around the big picture, which is the thing on the left-hand side there. Been around since the mid-2000s from Dean Leffing. Well, in fact, earlier than that, if you go back and read his books, the interesting thing is if you read the book, Scaling Software Agility, it's about requirements. If you read the book Agile Software Requirements, it's about scaling. But particularly Agile Software Requirements was the book where that was starting to start to form this idea of SAFE. Look, it's a very popular, large organizations and government. There is a lot of community criticism on the framework. People either love it or hate it. And it also has a lot of influence from RUP, which is where Dean Leffing well came from, and also a lot of certifications built around it. But if you do get into it, it is based upon agility. You can see the core values and the principles. They're all built on sound things. I think sometimes it just comes down to whether you can map your organization into this box or not, again, which is why you need these other methods. But it is worth a look. But is it the end game, which a lot of people think it is? You just can't implement SAFE and the Agile. But it might be the right starting point for you. This isn't the only scaling method, though. We have disciplined Agile, Dad, as well as DA Flex. Been around for, since 2012, in more recent years, been picked up by the PMI and integrated into their work. Again, a toolkit, a lot of the same things that there are in SAFE. It has, from the early days, had a lot of coverage of things like governance and DevOps and architecture, and very enterprise IT aware, probably more so in some respects than SAFE is. But, again, when you read it, it can be considered a bit heavyweight. It has a lower market adoption, and the PMI is still integrating it to date. So it's going to be interesting to see where this goes into the future. DA Flex is a subset of that, which is the work by Al Shalloway, which is the lifecycle part of the process, or the basering part of the process. Another scaling alternative is less, large-scale scrum. Again, this was built on work from the 2000s by Craig Laman and Bass Vod. Back in the early days, when a bunch was just trying to figure this out, the only thing we had to look for scaling, there were no frameworks. There were just these two books by Craig and Bass, Scaling, Lean, NADJOL Development, the first and second book. And that's about all we had, and it wasn't until 2015 when they really started to document out large-scale scrum. Now, this is about taking scrum and scaling it. It is up until recently been very much around case studies, as opposed to direct instruction, and this is one of the reasons why people struggle with it. In more recent time, they have added principles to the process, so they have built the book. They have less for up to eight teams and what I think is the silly name, less huge for up to a few thousand people. Still a small adoption, but it is growing. Sometimes it's a little difficult for people to implement. Spotify, not a model, but people do it anyway. Henrik Nyberg popularized this back in 2012, which was just the work that Spotify were doing at the time. Initially, if you look at Spotify in 2022, they're not doing a lot of this, right? The roots are there. So it was never an approach, but we have to put it here because lots of people talk about it. It is well worth a look, though. If you haven't seen the engineering culture videos, there's a couple of those which you can go see. Even 10 years on, there are things that I find in lots of organizations that were just not out. It had its own set of principles, but the idea of this was, was something that worked well for Spotify at the time. So if your organization happens to be a music streaming company in Northern Europe, maybe this is something you want to approach. They did popularize this whole idea of words like squads and tribes and chapters and guilds. If you're using those, it's probably because somebody's watched the video or read the PDF. It is not a framework. It's just a sharing of experiences. But again, there are things that we can learn from here. Scrum at scale is probably one of the newest scaling methods came out in 2014 and has been evolving over time. This one is only meant for small teams. But it does allow you to scale. Again, there's lots of language in this. This idea of minimal viable bureaucracy, this idea of an executive action team or an EAT and the executive Meta-Scrum team or an EMT. But the idea is getting people to the Scrum Masters together as well as the product owners together and scaling those types of things. It clearly builds on Scrum. It's built on the work of Jeff Sutherland. You can download the Scrum at Scale Guide freely in order to look at it. The key thing about this one that people struggle with is it requires a whole pile of organizational redesign in order to do it. And this is your organization really up for that. But as I said, gaining interest, very interesting. The other one's been around for a while is Nexus Framework. So Jeff was on Scrum at Scale, Ken Schwaber was this one about the same time. If you read the diagram at the top, it looks exactly like the Scrum process and all they've done is shove the word Nexus in front of everything. So instead of a Sprint backlog, you have a Nexus Sprint backlog. You have a Nexus integration team. You have a Nexus Valley Scrum and you have a Nexus Sprint review. But seriously, the idea of this is you scale it and essentially this team of team type idea that your team and all the other teams, they get together and it's a combined process. Not a lot of usage that I've seen in my travels and just assume Scrums, but if you're looking for somewhere to start, it might be a one to take a look at. One of the newer scaling frameworks is Fast. Fast Agile stands for Fluid Scaling Technology. And the idea behind this is that it combines particularly open space and open allocation. If you look at something like Scrum and Kanban, they fit very well in that complex or complicated part of Knephen. Fast is really supposed to be in that complex and also when you're bringing things back from chaotic. So it's essentially a more modern version of an Agile framework. Again, it has a set of principles and values as well. It relies on dynamic re-teaming and that teams will continue to form around work whenever they need to. There's only one meeting. So none of this four events or whatever it is you have in Scrum, just one meeting, it's called the Fast Meeting. And it's built around a lot of modern approaches, things like open space and open allocation and lean startup. It's only a new model. I haven't seen a lot of usefulness or sort of use of this at the moment. It does require a lot of discipline and you do need to read it very carefully. There's not just a big picture you can kind of follow. It's more based around principles. But again, it's something worth taking a look at. All right. Let's take a look some technical methods. We've passed halfway, folks. We're doing well. So the technical methods, right? DevOps, DevSecOps and GitOps. Here they all are. Date back to 2009 and Patrick DuBois, probably best diagram described in the DevOps handbook. DevOps is our bringing your Dev and Ops together. DevSecOps obviously brings the security side into it. We also have GitOps, which is also bringing in the whole idea of how we actually do operational type work. Again, if you look back to the water scrum fall we talked about before, this is about fixing that problem of the scrum fall type part. The key one about this is that this is not a team. It is a culture and it's not a tool, right? It is a culture. Yes, there are teams and tools that may help you in doing this, but it has to be part of the culture of what we all do. Program Anarchy is an interesting one. It's been renamed to Chaos Development more recent times. This was the work of Fred George. It was actually based off some work he did at a company in the UK called Forward, but it has been adopted in organizations such as GitHub over the years. What you'll see is that essentially what they did is they moved from agile to very fuzzy practices. They said, look, we don't need stand-ups. We don't need retrospectives. We don't even need managers. We can get rid of all those things and just work fast. You see, this is developer-driven development, and if you have a very good culture, you could possibly do this. So in some organizations where they can work in this lightweight culture and everybody is committed to the cause, this could work really well. If you want to look at this, there's a couple of PDS and conference talks around. It does require that highly skilled team in order to do it. Beware, there's no testing or planning in here, right, because you're going at speed. So it's a hard one if you want to convince your managers to do it, but you can learn some things from it. It's very interesting. So go take a look at work with Fred George. The Mercado method is another method that developers use. If you've ever done refactoring, you may not have realized that there is a method behind it. So sometimes I talk to developers and they say they're doing some refactoring, and I say, well, actually, it doesn't follow this. So again, if you want to put some method around some of the things you're doing, take a look at the Mercado method for refactoring. You've heard a pair programming, but mob programming has been building in popularity since 2012 when it was introduced by Woody Zool. Instead of two people sitting at one computer, it's a whole team sitting at a computer. What's been interesting over the last few years is actually just seeing the amount of organizations that actually try to do this and it's continuing to grow. It's an interesting thing. It's well worth looking at the process and watching the videos. When I first saw Woody talk about this back in the early days, he basically convinced you after 40 minutes, this was a good thing. And then told you not to do it because the whole reason this came about was his team were just looking for a better way of working. But lots of organizations and teams have looked at this and have started to adopt it. And there's a lot more stuff behind this now than there was in the early days. So worth a look. And of course, we've looked at testing and those type of things. So we have TDD, ATD, BDD and SBE all the way back to Kent Beck in 1994 with test-driven development, just doing small things. Build a failing test, pass that test and then refactor with confidence. We then scaled that out to the wider part, which is ATDD, which is let's do it for a story card or for a piece of work. Have a failing test, do the story, prove that you passed the test. And then that's evolved into a whole process, which is BDD and SBE, specification by example, and behavior-driven development, which allows us also to put some more rigor around the entire process. Both these books are really good. If you're looking for the developer side, Kent Beck's book or specification by example by Goiko, both awesome books. And again, just part of process when you're really starting to go at speed and scale in an agile method. What people don't realize though is that the testing community for many years has been trying to move in an agile way. And so context-driven testing has been around since the early 2000s. Again, they had a whole pile of principles and if you read through those, so it's aligned to agile testing and really the idea was is to bring humans to the forefront. Not really a technique, but it's a school of thought. It is worth going take a look at. Again, sometimes we ignore testing. It's sometimes one of the biggest roadblocks we have to agility. In more recent years, business agility has become the thing. And so in the business agility domain, we have a whole pile of different things here. Evan was talking just before me. He has the domains of business agility from the Business Agility Institute. Similarly, the agile business organization has their own ones, their framework for business agility. And Mick Kirsten is also well known for his flow framework, which came out in 2018 about trying to move flow. All of these things are about looking and saying, hey, we don't have true agility until it matches across the entire organization. Which means that we have to look at other things, for example, beyond budgeting. Finance is often where there is a bottleneck. So again, this has been around since the 1990s. Started with the first book by Jeremy Hope and Robin Fraser and Peter Bunce. And more recently, the work of Beate Bognus. Really around the oil industry is where this has started and is very popular in Europe. But is something that more organizations are starting to think about as they start to move forward. The interesting thing is it's based on these 12 principles here. Only one of them has anything to do with money. All the others are around management and leadership processes, right? Typically we put budgeting in place because of trust issues. So it's about saying, hey, how can we reduce some of that complexity and move budgeting forward? Design thinking is another one of the processes. There's a whole pile in here. Human cent design goes all the way back to the 1950s. The popular is really in 2005 by David Kelly and Tim Brown when they spun IDO out of the Stanford Design School. And the interesting thing is if you go back to the manifesto, the first principle in the manifesto says that we need to primarily satisfy the customer. Well, that's why human cent design works so well with this. And really this is about fixing our discovery process. So again, talking about the order scrum for, how do we actually make things happen faster, start to build experimentation and things into it? Also strategizers have done a lot of good things, things like the value proposition canvas, ways for you in order to do design thinking. This is a whole field of thought, very much aligned with what we do. All right, let's quickly look at some role methods. In order to make sense of this, people have got role-based certifications. We've got agile certifications, but actually how do we do things better? So the PMI and Prince II have project management processes. So the key project management tools we use all now recognize agility. In business analysis, the IOBA now have agile analysis and are actually now moving into things like product ownership and cybersecurity. ISTQB have their agile testers, so they recognize it. And of course you have organizations like ICAGIL that then spread out into different things like coaching and testing and DevOps and other role-based things as well. Management, there is a whole pile of alignments in management. One of the closest probably to the agile world is Juergen Apello's Management 3.0. Well worth a look at the website if you're having a lot of techniques and workshops and things you can do in order to think about how do we change management movement from old styles to new styles and you can see there's a bunch of principles. Agile coaching has been a facilitation of things that have evolved over the last few years. There's a whole pile of models here. For coaches, there's an agile coaching competency framework from 2011 from Lisa Adkins and Michael Spade. More recently, the Scrum Alliance has come out with an agile coaching growth wheel. Things like liberating structures and other ways of doing facilitation to make sure that we're truly inclusive in the way we do it. And also in things like for development teams, the Salmon Method came out last year from Emily Bash. All of these things are around coaching facilitation. We can do a whole talk of 40 methods just on the things in here, but these might be some to go look at. Let's wrap by looking at some organization and transformational methods in large organizations and governments. The work of Frederick Lelou and other eventing organizations moving from these yellow and red organizations towards green and teal. Looking at governments like the UK government and the digital service standard and also some work that we've been doing here in Australia around the government agility model. So we're starting to see a lot more uptake in large organizations and governments. Agenda shift is an interesting one to go look at. It is a whole process for transformation and it's framework agnostic. So it gives you a whole bunch of patterns in order to do a successful transformation. Another one of these is open space technology and open space agility. Open space technology is just a facilitation framework that Harrison Owen popularized back in 1984 and has used a lot through the Agile community. Open space technology is Daniel Messick's look at essentially as he says on that diagram there, 100 days to enterprise agility. So how can you again move through transformation? It's a brand new type of thing. It's a manifesto. It's an interesting approach. Could you do this in 100 days? But well worth a look if you're on Agile transformation. Looking at things like collocracy and sociocracy are important. This was the work of Brian Robertson in 2006. Look, there's been some limited uptake around this and some criticism of it. Zappos was the poster child for this and has had limited success, I guess. But it's an interesting way of flattening the cycle and there are lots of organizations, particularly sort of medium-sized organizations that have success at sociocracy. Again, it's interesting to go look at and learn some of the things that you might be able to use in your own organization. We're all doing things remote these days. So in the last couple of years, the remote agility framework has come out in 2020. And whilst you really in order to get into this, you need to actually have certification or community access. It's an interesting look at how we do things remote first. So how you can take things that we used to do in the real world and bring them out. And lastly, number 40, Kenefan, making sense of our world. This is called the Updated. If you haven't seen the new model that was Updated in I think it was 2020, it's with some different names on it. But essentially, how can we make sense of the world that we're in? And that's extremely important when we're starting to make some sense of our agile world. All right, that was 40. In fact, it was about 60. But there you go. We went very fast. Here's some final thoughts. There is a whole pile of stuff that I would have loved to have put in here that I couldn't, right? This would have been 200 agile methods and 200 methods. 200 minutes. So I can just talk about things like NVC and domain-driven development and lean UX and spiral dynamics and a whole pile of other models that are on the cutting room floor. This was just a start, but hopefully this will give you some things to go think about. And the thought I want to leave you with tonight today is the Oath of Non-Allegence. This is something from 2010 by Alistair Coburn. Unfortunately, the site's no longer up. But he said back in 2010 that we should promise not to exclude from consideration any idea based on its source, but to consider ideas across heritages in order to find the ones that best suit the current situation. In other words, just because your organization or you have done training in one particular school of thought, be open. Open to the ones that have started this all off. Be open to the brand-new ones and bring those into your world and we'll have a better agile world as a result of it. Thanks for coming on the ride, folks. We're happy to certainly hang out with you after the talk if you'd like to talk some more about these. There's my details there if you want more and we'll make the slides available to you. Thank you, Craig. And just a quick reminder, please read the session in the live streaming page when you view this session. And Craig will be in Hangout to answer your questions if you have any questions. So, Craig, we have one question in Q&A, so hopefully from Gerald. If you can answer all of it, you can take it in Hangout. We still have one more minute before we end the session. Yeah. So, I think he posed that question before I talk about things like the remote agility framework. So, everybody's been impacted by remote working and what we're saying to see with some of these more, with these newer methods, is that that is taken more into consideration. We used to talk about having teams co-located and bringing them together. That language is changing. But I think we've still got a long way to go, honestly, in relation to remote working. Thank you, Gerald. Thank you, Craig.