Video details

40 Agile Methods in 40 Minutes: 2022 Edition by Craig Smith

Agile
10.06.2022
English

With 66% of the world using Scrum as their predominant Agile method, this session will open up your eyes to the many other Agile methods and frameworks in the world today. For many, Agile is a toolbox of potential methods, practices and techniques, and like any good toolbox it is often more about using the right tool for the problem that will result in meaningful results. So join us on this rapid journey to look at the universe of Agile approaches and adding some extra tools into your toolkit
More details: https://confengine.com/conferences/agile-india-2022/proposal/17245
Conference Link: https://2022.agileindia.org

Transcript

Hey. Welcome everyone to 40 agile Method of Medicine. 40 Minutes 2022 Edition by Craig Smith. We are glad that Craig can 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 Elition Podcast and director of the Agile Lines 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 wanted 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 of 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. We'll make all the slides and information available to you. They're very feature rich, you'll have all the links and things 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 40 minutes. So, as I said, coming to you from Australia, and really we have to look outside of the methods that we currently use. So if everybody's ready, you 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 a 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 mountaintop in Utah and they came up with four values and twelve principles. And of course, I'm sure you all know the four values. We value the things on the left a 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 agiless, it's the basis to where we go to now. We can 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, having 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. Let's look at method number one. I'm sure you're mostly familiar with this, it's Scrum. In the latest surveys that they've done, this is still the most popular method. It's bounced between 60 and 70% for ten plus years. Now it's the most popular method. It goes all the way back to 96. 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 of Scrum is 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 are no technical practices in there either. But yeah, they're recently updated with values which you can see on the top right hand corner and it is the basis for most of the Iterative processes that are in use today. The problem with Scrum is that it sometimes turns into what we call Scrum. But that's when if you've ever heard yourself saying in my organization, we're doing Scrum, but our sprints are twelve weeks long, we're doing Scrum, but 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 Ken Schweber said is we actually need to turn that around and not be talking about Scrum, but talking about we do Scrum. 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. End extreme Programming XP, not this XP, but the Extreme Program XP also came out about the same time as from Kent Beck, popularized by the White Book, as it seems there. 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 two thousands. And I think a lot of people forget, if you look at the process at the top, that it looks a lot like Scrum. It had a very similar process. Instead of Sprints talked 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 practice, 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 bit hand in hand. It also has a set of values. These practices have just become a good software engineering practice, to be honest with you. But it's still surprising the number of teams that probably haven't licked 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 early 1990s, is popularized by his book Crystal Clear. Interestingly, however, this was supposed to be a set of books at the top there, there was supposed to be a whole pile of colors for it, crystal yellow, orange, red, but GenTri and blue. And the idea was, 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 use and how you use it, it was certainly used or at least referenced a lot back in the day. Probably not when 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 Azure community today that show their roots to Alastair 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 DSDM. DSDM again, so these were all about the same vintage and again, all of these folks were part of the Agile Manifesto. Again, whether you've seen this or not, the thing about DFM was a lot more structured, it 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 DSDM in more recent years. In 2016 they evolved this to something called Agile PM but it still has the same routes in there. One of the problems in the early days was that you did have to pay to join it. It's all pretty freely available these days. This DM, 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 goes back to Tom Gill back in 1960 in a fur in the right, the Agile India Lite conference. You might have heard seen Tom speak and yeah, this was the original Agile method. We 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 consider the good Agile practice today breaking things down, doing the high risk things, early open ended architecture. Remember, this was the 1960s, 90, 60s through the 98s 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 newer 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 Rad Rabbit acclash development, also adaptive software development. This one goes back to the early 90s, james Martin and his Rad approach. 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. As to the name Rad. Jim Highsmith 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. Learning but if you have cycles that you go through some sort of discovery and delivery. It goes back to the roots of gym 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 99s before it's time. It's considered hacking test because you didn't have the ability to get things out to use as quickly. But again, a lot of our methods are built on the shoulders of these giants. So there was a lot of early methods there, 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 liens. 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 ELO Whitney as part of the Industrial Revolution. It started to get its roots, though, with Toyota and Tokyo 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 out there, the five of them. And also the fact that we put our focus on kaisen and improvement and Carters in having repeatable processes and also removing the mood or 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 thing 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 a 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 lead. And this is from the work of Eli Goldrack in 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 are 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 the Popinik, Marian Tom Poppinik 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 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. So all of their books are worth a look at. If you get the opportunity to see or hear Mary and Tom Popped 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 Thoroughly, John Turn and Brian Rivera, their extra 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 the principles, I mean, putting the customer first, that's 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 they're thinking behind it. If we start thinking about Lean, 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. Over the next few days at the conference, we'll quote Edward Stemming. 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 page, we could argue that the language is a little dated. But the interesting thing is that this was agility back in the 40s. Even though we talked about things like eliminate inspection, building quality, what that was really saying is inspected adapt, right? Quality is important. Break down barriers, work as a team. We now call that thing by crossfunctional teams or multidisciplinary teams, 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 is he has the plan to study act loop there. You may know that it's planned check act. He said that he wants to use the word study because it emphasizes inspection over analysis. So he was really thinking about inspecting 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 a Creative Commons or they're out of copyright. So go take a look at them. And if you haven't read that or discovered it in more modern times, though, we have Don Reynoldson 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 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 Dons dons book, 135 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 done a few years ago. I asked him the question, Why? 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 in your bookshelf if you're interested in that. Also at its lean routes 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 Khan barn board or a Khan barn wall, but that's only one of the five properties. To be truly doing the Khan barn 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 as 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 Anne 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. 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 two thousand s. And so this was interesting that when this book was published in 2008 by Eric Reese, 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 a measure and learn and do it quickly. One of the interesting things about the book was that it assumed agile the course. 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 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, 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 pull them together or pull them apart. And here's a pile of extending methods that you may or may not come across. Modern agile from Joshua Kariasky heart of agile from Alistair Coburn agnostic agile from Sam Zawadi are all extending methods. They all take agility and put a modern interpretation on it. Modern Agile is just down to simple four principles. Part of Agile the same agnostic, agile, a few more principles there but really saying hey, let's be agnostic. And even at softball we've been working on our own sort of thing here called the value lifecycle. 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 Scrum band. If you put XP and Kanban together you get Zamban. 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 for this was the term coined by Dave West from Forest back in 2011. That essentially just because you're doing Scrum have 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 falling towards scrum for more recently in 2016. Utah Exceed and John Buck, you tour is talking at the conference today as well. So look out for her a few years ago. They came up with the Boss and Overhau, which is putting together beyond budgeting sociopathy and open space for a new way of looking at the all hybrid methods. Sometimes we want to know how these things work and so we have something called Scrum Flop, which maybe you haven't come across if you've ever sort of wondered the patterns, because software development is all about patterns. Well, people have done some work to actually get the patterns out of Scrum and that's this program called Scrum Plot from 2010. Jeff Sutherland and Jim Kaplan, they wrote a book about it a few years ago. And you can go to the website scrumpop.org and you can see all the patterns 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 patterns in there. A few folks have said, look, we need to do something different with agile. And so we ended up with Agile Two. Not sure if we needed it or not, but Agile Two came out in 20, 20, 43 principles around Agility because look, we need to take a fresh look. I got to say this, but I think if these guys were smart, they would have come 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 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 learned in Agility to manufacturing, and this was built on some work by Joe Justice originally when he was at Wiki Speed and more recently around agile hardware in his work at Tesla. Now Wiki Speed, if people don't know, is about building a car for the XPRIZE and they essentially used agile practices to do it. Hats Grand Masters did it generations, 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 are 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 hard to change those things for experiments so 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 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 familiar with safety 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 leftwell 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 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 rough, which is where Dean Left and 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 be 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 DaFlex been around for since 2012 in more recent years being 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 for the early days had a lot of coverage of things like governance, DevOps and architecture and very enterprise. It aware, probably more so in some respects than safety. But again, when you read it, it can be considered a 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 our Shalloway, which is the lifecycle part of the process or the bass ring part of the process. Another scaling alternative is less large scale Scrum. Again, this was built on work from the Craig Lamen and Bass VODD back in the early days when a. Bunch of us were just trying to figure this out. The only thing we had to look for scaling. There were no frameworks. They were just these two books by Craig and Bass. Scaling lean agile development. The first and second book. And that's about all we had. And it wasn't until 2015 when they really start 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 times. 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 a silly name, less huge for up to a few thousand people. Still a smallish adoption, but it is growing. Sometimes a little difficult for people to implement. Spotify not a model, but people do it anyway. Henrik Nibberg 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. 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 ten years on. There are things that I find in lots of organizations that were just not at. It had its own set of principles, but the idea of this 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 again, it's probably because somebody has watched the video, read the PDF. It's 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 it's 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 an Executive Mediscrum team, or an EMT. But the idea is getting people to the scrum masters together as well, 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 is your organization really up for that. But I said gaining interest. Very interesting. The other one has been around for a while is Nexus framework. So Jeff was on scrum at scale. Ken Schwaber? This one about the same time. If you read the diagram, the top, it looks exactly like the Scrum process and all they've done is shoved the word Nexus in front of everything. So instead of a Sprint backlog, you have a Nexusprint backlog, you have a Nexus integration team, you have a Nexus daily 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 Scrum. But if you're looking for somewhere to start, it might be 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 a Scrum and Karm Barn, they fit very well in that complex or complicated part of knife. And Fast is really supposed to be in that complex and also when you bring 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 retaining and that teams will continue to form around work whenever they need to. There's only one meeting, so none of these four events or whatever you have in Scrum, just one meeting is called the Past 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 your 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 at some technical methods. We're past halfway, folks. We're doing well. So the technical methods DevOps, Dev Sekops and GitOps date back to 2009 and Patrick Dubois probably best digger described in the DevOps Handbook. DevOps is our bringing of dev and ops together. Dev Sekops obviously brings the security side into it. We also have Gin Hops, 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 develop more recent times. This is worker Fred George was actually based off some work he did at a company in the UK called Ford, but it has been adopted in organizations such a 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 PDFs and conference talks around. It does require a highly skilled team in order to do it beware there's no testing or planning in here 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's. Very interesting. So go take a look at the word of Fred George. The Mercato 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 say they're doing some refactoring and I say, well, actually, does it follow this? So again, if you want to put some method around some of the things you're doing, take a look at the Macado method for refactoring. You've heard of 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 what he talked about this back in the early days, he said 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 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 types of things. So we have TDD at the BDD and SDE 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 ATD, 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 pass the test and then that's evolved into a whole process which is BDD and SBE certification 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 spectacular 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 they are about agility. So it's aligned to agile testing and really the idea was to bring humans to the forefront. Not really a technique, but the school of thought. It is worth going to take a look at. Again, sometimes we ignore testing, 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 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 Utility Institute. Similarly, the Agile Business Organization has their own ones, their framework for business agility. And Nick Kersen 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 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 Buns and more recently the work of the articulagnes really around the oil industry is where this has started and it's 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 twelve principles here. Only one of them has anything to do with money. All the others are around management leadership processes. Typically we put budget 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. The human sense design goes all the way back to the 1950s. The popular is really in 2005 by David Kelly and Tim Brown when they spun idiot at 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 humancent 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 strategizer have done a lot of good things, things like the value proposition canvas wait 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 got Agile certifications, but actually how do we do things better? So the PMI and Prints too 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. ISTB have their Agile testers so they recognize it. And of course you have organizations like IC Agile 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 you're going to pillow is Management 3.0 well worth a look at the website if you haven't a lot of techniques and workshops and things you can do in order to think about how do we change management, move it from old styles to new styles and you can see there's a bunch of principles. Agile coaching has been 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 Atkins and Michael Spade. More recently, the Scrum Alliance has come out with an agile coaching growth wheel. Things like liberating structures and 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 these things around coaching facilitation. We could do a whole talk of 40 methods just on the things in here that these might be something to go look at. Let's sort of wrap by looking at some organization and transformational methods in large organizations and governments. The work of Frederick Gloom reinventing organizations, moving from these yellow and red organizations towards green and teal, looking at governments like the UK government, 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 in government. 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 is used a lot through the agile community. Open space technology is Daniel MEsix to look at essentially, as he says in that diagram there 100 days to enterprise agility. So how can you again move through transformation? It's a brand new type of thing. Live a manifesto. It's an interesting approach. Could you do this 100 days? But we'll work a look. If you're on an agile transformation, looking at things like holocracy and sociocracy are important. This is work of Brian Robertson in 2006. Like 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 the medium sized organizations, that have success at socioe. 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 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 knife and making sense of our world. This is updated if you haven't seen the new model that was updated and I think it was 2020 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 write. 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 Linux and Sporadamex 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 allegiance. This is something from 2010 by Alistair Coburn. Unfortunately the site is 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 just 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. Happy to certainly hang out with you after the talk, if you'd like to talk some more about these. There's no details there if you want more, and we'll make the slides available to you. Thank you, Craig. And just a quick reminder, please rate the session in the live streaming page when you view the session. And Craig will be in Hangout to answer your questions if you have any questions. So, Craig, we have one question in Q and A, so hopefully from Gerald if you can answer or you can take it and hang out. Still have one more minute before we. End up in I think he posted that question before I talk about things like the remote agility framework. So everybody has 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 colocated and bringing them together. That language is changing, but I think we're a long way to go, honestly, in relation to remote working. Thank you, Gerald. Thank you. Please.