Episode Description
Dan Neumann, your host, has been reviewing the history of the Agile Coaches Corner Podcast and encountered the most popular show among these 184 episodes, it is titled “What is Agile?” and was hosted by himself and Sam Falco.
In this episode, you will get the chance to listen again to the most listened episode so far, which explores the foundations of Agility and the history of the Agile Manifesto.
Key Takeaways
Why was it important for the Agile Manifesto to be declared? What is the history behind it?
It was created in reaction to what was happening in the software industry in 2001 (predominantly waterfall and other predictive methods with bad track records for delivering on time).
In response to “scope creep” (AKA changes or uncontrolled growth in a project’s scope at any point after a project begins).
Because it is very difficult to predict what you need to do when you’re trying to solve a new problem every time.
Out of necessity (as any work that requires creativity and a high degree of uncertainty about the outcome you’re trying to achieve [such as software development] is difficult without a set of principles and values).
Because every problem is unique with software development.
In the Harvard Business Review in 1986, an article was published titled, “The New New Development Game” which outlined the need for a new way of working where teams could be given objectives instead of tasks and they work together as a unit to accomplish their work.
What is the Agile Manifesto?
It’s the thing we point to when someone says, “What is agile?”
Those that came up with the Agile Manifesto didn’t put it together to justify their existence; they put it together because they recognized the success they were having through its methodology and wanted to figure out the commonalities.
If you’re asking if something is agile, you can reference the manifesto’s values and principles.
What is Agile?
It’s creating a competitive advantage and being a disruptive force.
Delivering working software as your primary measure of success.
A collection of values and principles as laid out in the Agile Manifesto.
It is the ability to deliberately respond to change and demand; not just react.
Controlling risk.
Building stuff that people actually want and will use.
Solve the problem that the customer has called for and not gold plating everything.
Agile practices are simply that; practices — they’re good in some circumstances and not good in others.
Are you changing just to change or are you harnessing change for competitive advantage? Is change happening to you or are you creating the change?
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro [00:03]:
Welcome to agile coaches corner by agile thought the podcast for practitioners and leaders seeking advice to refine the way they work band pave the path to better outcomes. Now here’s your host coach band, agile expert, Dan Newman.
Dan Neumann [00:17]:
Hello, and welcome to this episode of the agile coach’s corner podcast. I’m your host Dan Newman. And I want to appreciate you for taking some time to spend with me and to listen to this podcast. I also want to make a point of appreciating the listeners for not just listening to this podcast, but for having listened to the 183 prior episodes to this one, I did a little research as I was trying to think of a topic that I wanted to cover as part of this podcast and learned that the median life of a podcast is merely 174 days. And so for this one to be sitting not at 174 days, but well, past 174 episodes, I think is really a Testament to listeners for showing interest. If there was no interest in the podcast, we would not continue to do it. And a Testament to all the collaborators that I’ve been able to have as we’ve gone through the prior 183 episodes.
Dan Neumann [01:16]:
So three and a half years later, I just wanna take a moment and say, thank you very much to everybody who’s been involved, whether it’s on the production side, the support side, or of course on the listener side. So thank you again. I also want to refresh the invitation to feel free, to email me podcast agile thought.com. I do get them. I do read them and we work those into various episodes. So appreciate folks who have reached out in fact of a bit of a teaser. The next episode, episode 180 5, barring any major changes will be a listener question who had the topic of how do you work with architects or dev specialists to really shift from a mindset of, we have to get all the architecture up front and we have to get it right, because that’s the basis of everything we’re going to do and shift them to more of a mindset of, you know, what we know enough.
Dan Neumann [02:12]:
Now we need to move forward. We can validate our assumptions and the architecture can emerge as we go forward. So stay tuned to that. That should be episode 180 5. Again, we might inspect and adapt based on shifting demands, but right now that’s the trajectory. It looks like we are on reflecting back on all the episodes we’ve had. The very first episode was one on the topic of the importance of doing agile well before scaling agile. Of course, as we look back that has quite a few downloads relative to all of the other ones. It was our first, it is not the most popular one though, that sits in number three, number two on our list, believe it or not is about story points and estimation. So I would not have thought necessarily that the second most popular topic would be on user stories and story points, but there it sits.
Dan Neumann [03:10]:
And then in first place, the most popular of our episode so far was one that we titled what is agile. That episode sits a little more than a year old at this point and was a collaboration with Sam Falco. And if Sam were here, he probably would chastise me for not having muted all the devices that just shifted an alert for me. So a shout out to Sam, he’s seeking his fortunes elsewhere at this point. And, uh, that’s why you haven’t heard him, but of course, if Sam is listening Sam, we wish you well and want to appreciate, I want to appreciate personally all the efforts you put into getting this podcast where it is. So in honor, of the most popular episode and the collaboration of everybody involved in the production side and on the listener side, what we’re going to do here is a little best of, and I hope you enjoy listening to Sam Falco. And I collaborate on the topic of what is agile, which also happens to be the answer to what is the most popular episode we have at this point. And thank everybody again for your listenership. Please do reach out with your questions and we’ll work those into future episodes. Thank you and enjoy listening to me and Sam riff on what is agile. Welcome to this episode of the agile coach corner. I’m your host Dan Newman, and joined by collaborator Sam Falco,
Sam Falco [04:33]:
How you doing Dan?
Dan Neumann [04:34]:
Wonderful. And it sounds like we’re gonna step on each other just
Sam Falco [04:37]:
Once tonight. It’s, it’s what we do.
Dan Neumann [04:40]:
It’s part of this fun, right? But we hope to still make it an amazing experience for people who are listening. So diving right in today, we’ve invited people quite regularly saying, Hey, go ahead and, uh, you know, send us some questions podcast@agilethought.com. I didn’t anticipate properly that I would get a question on LinkedIn, uh, not LinkedIn on Twitter. One of the other platforms on the Twitters. And it only took me about three months to notice that I had a direct message. So for that, I apologize. And I’m Bravo trying to use, trying to use Twitter better. The question came in from a listener named Chris, and he was wondering what resources there might be for what is agile for people that are trying to understand that.
Sam Falco [05:27]:
That’s interesting. I mean, we talk about agile a lot, but everybody’s got their own perspective on it or own definition of it. And so you’ll hear people say, oh yes, we’re agile. But when you dig in, they’re still acting in ways that don’t, don’t seem to be in alignment with the agile manifesto or principles. And maybe before we start talking about what it is, it might be important to dig into why, why was it necessary for an agile manifesto to be declared? Where, where does this come from?
Dan Neumann [06:04]:
Agreed. So I think one of the places that, um, the agile manifesto comes from is a reaction to what was happening in the software industry at the time, you know, preceding 2001 with the manifesto. And that was the, the predominance of waterfall and horribly unsuccessful track records for delivering, you know, value projects on time with scope, people cared about for the, the money somebody was interested in paying for it,
Sam Falco [06:35]:
Right? And it wasn’t just waterfall. There were a lot of big design up front frameworks or methodologies that were not producing the results. Waterfall is the most commonly known it’s the most, uh, was the most prevalent, I think. And it’s interesting to me, because if you look at the paper where waterfall was first described, published in 1970 by Winston Royce, and he describes one way, we might start professionalizing software development and he describes this and there’s the pretty diagram. And later in the paper, he pretty much says he doesn’t think this will work and probably shouldn’t do it that way.
Sam Falco [07:15]:
I maybe overstating the case, but he was not saying, this is, this is going to work. And people started applying it and very quickly it became apparent that no, this doesn’t work in Roy’s paper. He was also saying these should be short cycles and that you should have at least two, one as a prototyping phase. And then your delivery phase, once you’ve learned something, unfortunately that part of his analysis sort of got dropped because, well, let’s just go faster. It’s faster if we just do it right the first time, how many times have we heard that phrase? We just wanna do it right the first time. It would be awesome if human beings were capable of doing things right the first time, but not so much.
Dan Neumann [07:58]:
My, my favorite part of doing traditional management when I did was the post mortem. We’ve just spent 18 months on the project. Oh, it sucked. What are we gonna do better next time? You know, we can do better. Next time we can get the requirements. Right, right.
Sam Falco [08:17]:
<laugh>, we’ll spend more time looking at those requirements and analyzing them. And then the developers will know exactly what we want them to do, because we will tell them in excruciating detail
Dan Neumann [08:29]:
And we’ll hold the customer to that requirements. Absolutely. And design because they signed off. Darn it.
Sam Falco [08:35]:
Right. And customers love to be told things like, well, you signed off on it. So pay me. No, no one likes that.
Dan Neumann [08:43]:
Yeah. I, uh, I did about a decade under waterfall stuff in my, my favorite quote, when the haggling over a change request was from an Irish engineer named Edgar. And he goes, that’s what we call the same, but different. And I’m like, I have no idea what you mean Edgar, but yeah. All kinds of fascinating behaviors in a predictive, get it right the first time single shot through type of approach.
Sam Falco [09:09]:
Right. And that’s where the fear comes from. You hear this phrase all the time, scope creep, and I’ll hear it in my scrum trainings. And I’ll hear it when I’m coaching someone, whether it’s scrum or not, whether any agile framework, how do we prevent scope creep? Well, I think the lesson we should have learned by now is that you do not prevent scope creep and in an agile way of working, you learn that that is called learning <laugh> and take that into consideration and adapt to change. But we’re getting ahead of ourself.
Dan Neumann [09:43]:
Well, let’s, let’s not get ahead of ourselves. Let’s
Sam Falco [09:45]:
Let’s continue talking a little history. I have a history degree. So I like to use this every now and then. Uh, oh,
Dan Neumann [09:49]:
Well, we’ll we’ll uh, we’ll, we’ll try and contain you though. Okay. So <laugh>, so there’s the waterfall and, and other predictive methods that were, uh, highly prevalent at the time. And we should probably give a nod to our, our friend, our friend Taylor.
Sam Falco [10:04]:
Yeah. Frederick Winslow Taylor, who tried to apply what he called scientific management to work. This is a reaction to the industrial revolution whereby we can, we can analyze the work, doll it out, uh, time. It, uh, know exactly what the work is going to be, and we can establish best practices for everything. And that actually has its place in simple, or maybe even complicated domain work here. I’m relying on, uh, Snowden’s CIN framework for, for domains of, of management and work for those things where we know more than we don’t know, or we know everything about the problem we’re trying to solve. You can use that. You can do a predictive analysis. Here’s a fun side note. Uh, Taylor was the inspiration for the main character in the original movie, cheaper by the dozen I’ll edit, having many children was much more efficient than, than just raising a few. Um, just something I read one time and I thought, well, that’s just odd anyway. And now, now you know it too.
Dan Neumann [11:10]:
And, and now back to tailorism so right. <laugh> uh, so I had, I had a coworker once, so, um, we have a, a child, my wife and I do, and, and one of them, and this person was trying to explain to me how, you know, once you have like three kids, they just take care of each other. Um, the fact that she had zero kids made the advice a little dubious <laugh>
Sam Falco [11:36]:
I wonder that was, that was Taylor’s theory, but anyway, getting off of the, uh, the children,
Dan Neumann [11:41]:
But there were parts in Taylorism about, you know, reducing motion waste. So if you know, right. The traveling movements that are unnecessary, not working towards the outcome, removing waste and right. Um, and there’s some value in
Sam Falco [11:53]:
That there is some value
Dan Neumann [11:54]:
For certain types of work.
Sam Falco [11:56]:
Yeah. And the problem is when we try to apply that industrial paradigm to knowledge work, and this is true, whether it’s software development or, or, you know, marketing campaigns or whatever, involves a high degree of creativity and uncertainty about the outcome you’re trying to, to get to and software development very quickly outstripped the ability to predict what we can do because we’re solving a new problem. Every time let’s take, we’re building a house, humans have been building houses for a long time. We have a lot of data around how long it takes to lay brick and for the mortar to dry and to get pipe in there for the, for the plumbing, et cetera. We don’t really have that with software development because every problem is unique. We’re not solving the same problem over and over again.
Dan Neumann [12:41]:
So you are, you’re doing it wrong.
Sam Falco [12:43]:
You’re doing it wrong. Right? And I mean, how many times have we seen people say, oh, I know exactly what I want. I want you to rebuild. I want you to build exactly what my old system does, but not as creaky.
Dan Neumann [12:54]:
Oh, replatforming is in my experience, a, a fraught activity fraught with danger. They, they don’t go well because it isn’t just give me the old system, but on the new architecture, its oh, and roll in some enhancements and roll in. Some things are gonna discover. And the rest of the new ideas, you’re gonna come up with over the next
Sam Falco [13:13]:
12, 18. Right. But make sure that we still have all the old features without any analysis of whether or not anybody’s using those or needs them. But, but it becomes quickly apparent to anybody who’s paying attention. The waterfall is not having the desired effect. I won’t say it never works. Projects were delivered, but the failure rate was somewhere, uh, in the 80%, I can’t remember the exact study or the exact number, but it was like 85% of waterfall projects failed to deliver the value they were expecting to de to deliver. And so
Dan Neumann [13:44]:
It measured, sorry, and measured against, you know, original timeframe, expectations, original budget expectations. So it was pretty easy to fail. Did you do everything that you thought you would on time for the same dollars? Well, yeah. Good luck with that.
Sam Falco [13:57]:
Right. And so, as early as 1986, we see that waterfall’s not working. There is a paper that comes out the new, new product development game by Hika Tachi and NOCA in the Harvard business review and they are analyzing the way waterfall is failing and they compare it to a relay race. Um, in waterfall, of course, each group does its work and hands it off to the next, you have your requirements gatherers. They hand it off to analysts who then hand off the task, et cetera. And they say, well, that’s not working. And what we need is a way in which teams can be fed objectives instead of tasks. And they work together as a unit to accomplish the work. And their comparison was to a rugby team. The way a rugby team works together to move the ball up upfield,
Dan Neumann [14:50]:
Which I, I think the analogy works even though, uh, I couldn’t tell you what’s happening in rugby. Some dudes get together, the ball moves and eventually they celebrate <laugh>.
Sam Falco [15:01]:
I do like rugby, but I, I do find it baffling. I, the first time I watched it, uh, there was a stoppage in play and I said, what’s going on? And my friend said, oh, there was a foul. And I’m like, what did someone stab? Somebody? Because I couldn’t see that there were any rules.
Dan Neumann [15:13]:
Cause the, the rest seems to be fairly violent too. Yeah. So unlike, unlike a relay race where people are handing a Baton and by the way, often gets dropped in transition. This is more about everybody collaborating to move the ball together, down the field,
Sam Falco [15:30]:
Right? No specialty or very little specialization. Um, cross-functional anybody can carry the ball. Uh, I’m really reaching the limits of my, my rugby analogy here. So I’ll just,
Dan Neumann [15:42]:
If you have rugby tips for Sam and I feel free to email them podcast. Yeah. Teach us about this, but that’s where the term scrum then came from.
Sam Falco [15:55]:
Right. Um, and this is the, the last bit of my, my, my rugby knowledge is that a scrum occurs because there’s been a stoppage in play often because of a foul when Jeff Sutherland and Ken Schwaber were putting together, what became scrum, they built in stoppages in play. We have at the end of the sprint, we stop and look at what did we do and plan before we move forward. Every day we have a stoppage in play, so to speak where the team gets together and figures out, what do we need to do today? But I think we’re getting a little farther afield from our original question, which is what is original. Why,
Dan Neumann [16:33]:
What is that? Yep. So some of the, some of the things that weren’t working waterfall, some of the misapplication of tailorism leads to distrust when you’re setting expectations with your stakeholders, about how much money and when, et cetera. So lots of problems with the industry as a whole leading up to the pre 2001 state of when the agile manifesto was created,
Sam Falco [17:02]:
Right? Enormous amounts of distrust between business. On the one, hand it on the other, not just distrust, but in some cases, animosity, uh, a lot of finger pointing you, you never give us things on time. You can never settle on what it is you want, uh, et cetera. And so the agile manifesto comes about when the 17 people who were signers were all doing something different than waterfall and met to figure out what do we all have in common? What are we all doing that works that we could offer to other people to figure out how they should proceed instead of waterfall or any other big design upfront process?
Dan Neumann [17:44]:
I think that’s a really important point to pause and amplify agile. Wasn’t, let’s get together and think about a new way of doing things. It was a distillation of, Hey, we’re doing some things. It seems to be getting better results in the industry as a whole, what are we doing? That’s common across the different methods, crystal, scrum, XP, et cetera, cetera,
Sam Falco [18:09]:
Right. Et cetera. Right. And it’s reflected right? In that opening statement, we are uncovering better ways of evoke developing software by doing it and helping others to do it. These are practitioners. I actually had someone at one company said, when I asked, where do you think the agile manifesto came from? Said, you know, some agile coaches basically put this together to justify their existence. I’m like, no, you’re car for the horse there. Agile coaches come much later. But yeah, these, these are practitioners. These are people who have been having success and they want to figure out what’s in common because none of them were saying, you must do what we do. All of them recognize that their framework was good for their context. It might be good for others, but some people would not find them as valuable. And how could you essentially roll your own? Now, scrum sort of ate the world of agile because it’s effective. Um, and a lot of people adopted it. There’s varying theories on that. That are some are more cynical than others, but which is why we often hear scrum and agile being equated. But that’s why I kind of wanna try to avoid talking too much about scrum right today, because we wanna talk about agility,
Speaker 1 [19:22]:
Have a topic you want us to tackle, send an email to podcast, agile thought.com or tweet it with a hashtag agile thought podcast.
Dan Neumann [19:33]:
So back to agility, then the agile manifesto for me is the thing I point to when somebody says, what is agile? Uh, it’s got the, the four values on it. I think it gets truncated to individuals and interactions over processes and tools and yada yada
Sam Falco [19:51]:
Yada,
Dan Neumann [19:51]:
Right. One yada per each of the other three items
Sam Falco [19:55]:
Is that how Yadas work?
Dan Neumann [19:56]:
That’s how Yadas work. And then behind those four, those four values are 12 principles. And the degree to which a behavior or a mindset or approach aligns with those 12 principles is the test for lack of a better word I would use for is the thing, an agile method or not,
Sam Falco [20:20]:
Right? It
Dan Neumann [20:20]:
Doesn’t have to be an agile method that might not be applicable to your type of work. But if the question is, is this thing agile? Well, let’s look at, are we delivering working software? Are we frequently, frequently? Uh, are we changing just to change? Are we changing? Even welcoming changes, even late in development for a customer’s competitive advantage, right? It isn’t just whimsical cuz you know, we want to, so that’s the place where I would, what, what is the agile
Sam Falco [20:49]:
Right? And that this is a slight tangent, but what the heck? Um, one at anti pattern I see is people say, oh, responding to change means anytime I want, I can come in and tell you to, to stop what you’re doing and do something different. And that is exactly the behavior that led to the distrust in the first place in a pre agile world, that business would come in with new requirements or changes that needed to be made. And it would shrink back from that because no, it’s not in the contract, that’s not in the original scope and have the change management. And so here we have animosity. And so that behavior gets painted as well. This is agile. No, that is an anti pattern that is anti agile to just change. Willy nilly manifesto says respond to change or following a plan, not react to change. So sometimes we look at change and say, we’re not gonna do anything about that right now.
Dan Neumann [21:51]:
And, and one of, while we, while we pick on words, are we harnessing change for competitive advantage or is change happening to us? So the, you know, like harnessing, uh, a donkey, I guess, to, to pull a cart along like the, donkey’s not just running around doing whatever donkeys do, but you know, are we actually harnessing the energy of this change for that competitive advantage?
Sam Falco [22:14]:
Right. Well,
Dan Neumann [22:15]:
There’s our soapbox on change,
Sam Falco [22:17]:
Right? Well, just to, to add one thing, there’s a, a great statement in a book called agile software development ecosystems by Jim he Smith. I think it’s out of print now, came out early in the agile revolution and um, which is worth trying to find because there’s a lot of the why of agile in there and a great appendix on roll your own. Here’s what you need. If you’re going to alter or alter an existing owner, um, make your own. But what Jim says is that harnessing change for the customer’s competitive advantage is not merely keeping up with your competition, but generating. And I’m not sure I’m getting the quote exactly right here, but generating chaos rating, chaos that your competition has to deal with. So it’s not just keeping up, it’s not merely staying a step ahead. It is causing trouble for your competition that they have to adapt to.
Dan Neumann [23:13]:
Okay. Bringing it solidly back to yes. Okay.
Sam Falco [23:16]:
It can, you can reign me in <laugh>
Dan Neumann [23:19]:
So, so what is agile? You know, it’s, it’s, it’s creating competitive advantage, right? Disrupting your customer like, like you were talking about being the disrupting force. Are we delivering working software as our primary measure of are we, are we measuring progress using working software as our primary measure? My waterfall world, it was, we said, this was gonna take 300 hours on this activity. And you know, we’re, we’re 200 through, are we two thirds of the way through the effort we are measuring time and activity. Tayloristic kind of concepts, right. As opposed to measuring, using actual working software that we validated. So what is agile? It’s this collection of values and principles as laid out in the manifesto.
Sam Falco [24:06]:
Right. And I think that we get to the heart of it. When we say that it is the ability to deliberately respond to changing demand. Like not just react, but deliberately respond with with thought and at the same time controlling risk. And that’s another factor that big design upfront I’m, I’m deliberately trying not to use waterfall for everything, right? Yeah. Uh, but those predictive methods don’t limit risk because they take too long most of the time and they make it either difficult to change or when change happens, it throws our plan to such disarray that we can’t finish. So flexibility for sure. Um, but it’s with thought and we, we manage risk.
Dan Neumann [24:59]:
I love bringing in the concept of risk and it’s easy to think of just the requirement side of agile, you know, are we responding to change? Do we have working software? I love also that there are technical and engineering principles behind this. Are we, are we maximizing the amount of work? Not done, not just from a feature standpoint, but from a technical standpoint, don’t write code. You don’t need to write, uh, technical excellence enhances agility. This isn’t about just writing some crap. It’s writing enough code. That’s good. So that when things change, the underlying foundation is also easily changeable to deliver those.
Sam Falco [25:40]:
Right. And it’s funny because that gets labeled as an agile thing. That’s a principle that has been around maybe not in software, but build as little as possible. Right. Don’t, don’t build things. Nobody wants. Um, it’s articulated people little more clearly.
Dan Neumann [25:59]:
Yeah. I had a lot of experience with, oh, we’re going to need this. Oh, what if, oh, we should build it. Cuz they might. My experience, at least prior to agile was about building a lot of stuff that probably would count as gold plating or just, you know, we think somebody’s going to need it.
Sam Falco [26:20]:
Right. And I’m thinking of my working career before software, uh, there were often that idea that don’t do that. We nobody needs it right now. So I worked for a bookstore for many years and don’t unpack and sort those books onto a cart for shelving. There’s no room on the shelf, leave those in the box for right now. We don’t need them. Um, that kind of thing. Uh, and other, other jobs as well, where just don’t, don’t do a lot of work that we don’t need to do when I was doing the sub tech support, you know, solve the problem the customer has called in for, don’t try to do more than that and you can always escalate to tier two and let them handle it. If it really is a more complicated problem, maybe I’m overstating my case.
Dan Neumann [27:05]:
No, I, I see that with, you know, figuring out what the team is going to do and metaphorically that big box of stuff, you know, around a feature like leave that alone. Don’t start unpacking that if you don’t need to unpack it for some actual working software in the near term, just leave it alone. Like you can, you can get to it later. Right.
Sam Falco [27:27]:
And I think what I was getting at, um, and didn’t articulate well is just that many of the, what, what are referred to as agile practices are practices agile uses, but they’re not, they’re neither agile nor not agile. They’re just practices. And they are good in certain circumstances and not in others. And some of these things that we call agile predate the manifesto, they are practices that we know or, or knew about. Um, and we’ve just discovered, Hey, these are valuable. So let’s do them. Is it agile? I don’t know. Does it help you be agile? I think is a better question in that circumstance.
Dan Neumann [28:12]:
So Sam, thank you for taking the time to explore the tweet that I, uh, received from Chris on the topic of what is agile. We covered some of the background that informed the way software is developed leading into 2001 waterfall methods. Tailorism that bred distrust with, uh, business and stakeholders and lot, uh, with it. So lots of, lots of bad things were happening there. And then in 2001, people who were using methods that were yielding more success than what waterfall or other highly predictive methods were at the time got together to say, Hey, what are the common threads about what we’re doing, which then yielded the agile manifesto, the values, the principles. And, and we had a chance to explore some of that
Sam Falco [29:05]:
That was, that was
Dan Neumann [29:07]:
A mouthful. I, I think that was a mouthful. So that’s, that’s the, what is agile that brings us to the, what is Sam reading these days what’s on your continuous learning journey?
Sam Falco [29:19]:
The latest book I’ve picked up is called the surprising power of liberating structures. Liberating structures are ways to gather or encourage feedback and participation in solving problems and or even identifying problems and then solving them. There’s a website. I think it’s just liberating structures.com. We’ll have to check that before we put it in the show notes, we’ll
Dan Neumann [29:45]:
Put it in the, we’ll put the appropriate link in the show notes,
Sam Falco [29:47]:
Right? Uh, that gives an outline of these. The surprising power of liberating structures goes a little deeper into the theory behind these, these activities so that you’re not running the same kind of event over and over again. Uh, you can be a, a little creative dig, a little deeper. So I want to understand those more. I’ve only used a few of the structures that are described on the website and I wanna know why the others work when they work so that I can start using them appropriately.
Dan Neumann [30:16]:
That totally makes sense. Yes. I multitask liberating structures.com is the correct URL. We will still put it in the show notes, but, but you did not, uh, mislead people verbally. And there are some structures I’m familiar with 1, 2, 4, all for, for getting individual ideas and then aggregating them up into other ones. So, uh, applicable to what types of scenarios do you think for,
Sam Falco [30:39]:
For the retrospectives? Um, whether it’s a team retrospective or broader, um, planning sessions, strategy, even, uh, more to the point, some of these, some of these structures are quite lengthy. They’re not something you do in an hour or two there maybe all day, but if you’ve got big decisions to make lots of people, there’s a lot of these structures will help draw out inferences understandings and thinking that that might not have come to the surface. If you just sat everybody in a room and said, so what do you think?
Dan Neumann [31:17]:
Right. So I think there’s probably a, a deeper dive and a podcast dedicated perhaps to liberating structures in the future. So we’ll, we’ll throw that into the backlog and
Sam Falco [31:29]:
I’ll be, I’ll be an expert by next week. We’ll
Dan Neumann [31:31]:
We’ll do it. That’s I’m counting on. And I <laugh>, and I appreciate you letting me live vicariously through your learning. Um, it, it’s far more EF, uh, efficient than doing it on my own. It’s kinda a tailor approach. Really
Sam Falco [31:46]:
Nice. <laugh> nice. Nice, nice callback to the,
Dan Neumann [31:49]:
I try. So until next time
Sam Falco [31:51]:
Job,
Dan Neumann [31:53]:
I hope you enjoyed listening to that exploration on the topic of what is agile. Again, I want to appreciate Sam for the collaboration. Thank you very much, Sam. And I want to appreciate the listeners who made that our most popular episode to date. I look forward to other future episodes that are perhaps going to eclipse that one in popularity. And would it be next? Week’s possibly take a listen. As we explore with my colleague, Eric Landis on the topic of how do we work with architects and dev specialists to shift a mindset from perhaps what they’ve been trained on a very predictive and designed forward approach to one that embraces more emergent architecture. Thank you very much. Talk with you all next week.
Outro [32:41]:
This has been the agile coaches corner podcast brought to you by agile thought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of agile thought. Get the show notes and other helpful tips from this episode and other episodes@agilethought.com slash podcast.
Mentioned in this Episode:
“The New New Product Development Game,” by Hirotaka Takeuchi and Ikujiro Nonaka | Harvard Business Review (January 1986)
Agile Software Development Ecosystems: Problems, Practices, and Principles, by James A. Highsmith
The Surprising Power of Liberating Structures: Simple Rules to Unleash A Culture of Innovation, by Henri Lipmanowicz and Keith McCandless
LiberatingStructures.com
Want to Learn More or Get in Touch?
Share These Tweets!
“Agile wasn’t: ‘Let’s get together and think about a new way of doing things.’ It was: … ‘Hey, we’re doing some things. It seems to be getting better results than the industry as a whole. What are we doing that’s common across the different methods?’” — Dan Neumann
