Join Murray Robinson and Shane Gibson in a conversation with Scott Ambler about the Disciplined Agile Toolkit. In this episode we discuss toolkits vs frameworks. Tailoring your ways of working for your situation vs prescriptive methods. Method prisons and framework jails. The problem with two day mastery certifications and the over commercialisation of Scrum and SAFe. The PMI and Agile and Products vs Projects.

Read along you will

Shane: Welcome to the new nonsense edge odd podcast. I’m Shane Gibson 

Murray: and I’m Murray Robinson

Scott: and I’m Scott Ambler. I’m along with mark lines, I’m one of the co-creators of the toolkit. I am also the thought leader behind the agile modeling and agile data methods from back in the day. So I’ve been helping people understand this agile lean stuff for a long time since pretty much the very beginning.

Murray: So, yeah. Thanks. Thanks for coming on. Scott, I’ve read a lot of your stuff. I’ve been in admirer since the object oriented design and development book. I don’t think that was exactly the title, but one of those books and I’ve gone through your agile modeling website in detail, many times getting ideas from it.

So yeah, lots of good stuff there. 

Scott: Oh, thank you. Yeah, I think you’re thinking about the object primer. I like 

Murray: it, it was, it was you know, easy to follow. So, but nowadays you, you work for the PMI, you you’ve sold your business to them. I understand. And you’ve been working on discipline agile.

So if you could tell us a little bit about what that is. That’d be great. 

Scott: Yeah. So, so the Disman toolkit well, first it’s not a framework. So our which is an important nuance. So where the frameworks and methods tend to tell you what to do. They, you know, they present what they call best practices.

In da, we don’t do that. And which is a bit strange. So instead, what we do is we focus on here, excuse me, here are the issues you need to think about. And here are some options. So, because we don’t know your situation we can’t tell you what the best practice is. Nobody can. So what, but what we can do is to help you pick the right strategy for the situation that you face.

So do the best that you can and and always try to get better. Of course. So then we, we show you how to, how to improve and to learn over time and to maybe reduce some of these fast failures that everybody likes to talk about. And You know, instead I, I would rather succeed or succeed earlier or learn earlier which is what we’re all about with the da toolkit.

So it’s, it’s about more, it’s more around helping you to get better at getting better rather than telling you what to do. 

Murray: And is it, is it all about scaling? Is that what it’s about 

Scott: or is it, yeah, so it, it, no, but it originally started out as a scaling thing. So I’ll tell you a little bit of the history and then I’ll tell you about what we’re, what we’re doing now.

So it originally started in the late you know, around 2008, 2009 timeframe. So I was working for IBM rational at the time. And. Myself, my team and business partners that we were working with were going out to organizations and helping them to apply agile lean strategies on, in a, in a, in a very wide range of situations, almost always at scale, almost always, always in, in, in perfect situations.

And when I first joined IBM, I was pretty adamant. I did not want to write another method. I was clear about that going in. It was like, cuz I’d been there and done that with like enterprise unified process and agile modeling and agile data. And I was just tired of it and, and had all the arrows in my back and it just didn’t need that crap anymore.

but anyways what happened was, after a couple years of working with organizations, we started, you know, a bunch of us started noticing several things. First, everybody was struggling and I would, I would still say the same today, but they were struggling with this, this crazy agile lean stuff. They were spending a lot of time and money trying to apply it in their situations.

And they were all doing it differently. And even within their organization, the teams are doing it all all differently. And so that was, those were really interesting observations from a, like a process person, point of view, because basically, you know, this idea, this observation that everybody’s spending time and money, figuring this stuff out and really not getting it like often millions of years and millions of dollars.

And still not getting it told you that there’s a lot of waste in the industry around this, this agile stuff. But. The observation everybody’s doing it differently. Also tells you that a, yet another prescriptive method is not gonna get the job done. So, you know, observation one, you know, they need some sort of process help observation two.

They don’t need a prescriptive method which is what everybody else is doing. You know, there’s a lot of marketing rhetoric around prescription, but I would invite people to look the word up in the dictionary. When you tell people what to do, you’re prescriptive, sorry, you know, learn to read. And so those were two nasty observa.

Like there are like two like completely opposite observations. Right. And I would like to say that we were really smart and figured it out quickly, but you know, that wasn’t the case. It took us a long time to come up with what eventually evolved into da. And it was basically the, instead of telling people what to do.

We realized we really needed, we really needed to teach them about what to think about and how to make better choices and how to improve. And that’s that became, and that observation is what then led us to develop a choice based. Well, and we were calling it a method at the time or framework at the time Disman delivery, which is what we first released in 20, like in a book in 2012.

We’d had courseware and all this sort of stuff before then, but we released the book in 2012 and that became Disman delivery. We sent over time, evolved into what’s now the Disman toolkit. 

Murray: Okay. Yeah, I, I read disciplined agile delivery and I saw it as, I dunno if I read the first version or a later version, but it, it read very much like a.

Like a menu of options yeah. For different parts of the system development life cycle, if you’re doing it in an agile way. So, I mean, it’s pretty dry read from that point of 

Scott: view, a reference book. So it’s a reference book it’s not exciting, 

Murray: but you know, it’s really good to have a whole lot of tailoring options.

You know, I, I agree with you that a lot of the so-called process frameworks are, are very prescriptive. So, you know, scrum says that it’s immutable, for example. So, but, and I I’ve seen IVA Jacobson, one of the original rep guys talking about method. Prisons, like he’s saying people are stuck in method prison and he wants them to get out of it.

And, you know, safe seems a bit of a method prison like that. And I’m wondering if you could talk to us about this idea of method prison. 

Scott: Yeah. So the, so this is this is coming from E a and it’s a, it’s a fantastic observation. So we, he wrote a an article a couple years ago for, I, I, it was either for I E compute or I E it was one of the, I.

Publications. And the basic idea is that when you successfully adopt a framework or a method you, you hit the limits of it, right? So, you know, scrum solves a certain problem, safe, solves a certain problem and so on. And if you have that PR, first of all, if you have that problem and you successfully adopt the framework or method, then you know, you get benefit from doing that.

And that’s a good thing. The, but once you’ve successfully adopted the method, well, you’re at the limits, right? You’ve, you’ve hit the, you’ve hit the, the jail wall. And they don’t really give you any advice for how do you go beyond the method? You know, there’s, there’s marketing rhetoric, you know, it’s the art, everything’s the art of the possible, and you can tailor it.

You’re really smart. All these good sorts of things and sure enough, you know, you are smart and you could tailor it, but that’s, that’s the element of their advice or, you know, hire our expensive consultants and that’s about it. So. And frankly, their business models aren’t set up, you know, they don’t want you to move away from the framework that that would completely ruin their business model.

So, this is why there’s not a lot of advice. And so you, you end up in jail and so how do you break out? Yeah. So E a E R is behind essence which is based on the on CMA. And the basic idea is, so his focus is on software engineering. So how do you so he describes the process in terms of a collection of practices.

And so, you know, what practices do you pull off the shelf and, and apply? So, and they’ve done a fantastic job there. Now, the focus is software engineering. So they’re, you know, they’re, you know, they’ve narrow, you know, they’ve got a narrow band. Which you’re aiming for, which is great as a phenomenal, good thing to do.

And we’re doing the same sort of thing in Disman agile, but what we’re doing is we’re taking a broader scope. So we’re looking at enterprise agility. So not only, you know, how do you do software engineering, which is what Disman delivery was all about, but what about the rest of DevOps? What about value streams?

What about the rest of the organization? Like, you know, how do you become more effective at finance? So, you know, the challenge is like, yeah, you might have really good software development teams, but if the finance people are shooting you in the foot with their funding strategies and with the way they govern you, it doesn’t really matter how effective your software teams are.

If, if they’ve got an anchor on their neck or if the procurement people aren’t very effective, or if the HR people aren’t very effective. So. A fleet travels at the speed of its slowest ship. So you really need to focus on enterprise agility and how do you improve across the organization? But the challenge there is, you know, the finance people, they have their own way of looking at things and their own their own priorities and their own belief system.

So do the procurement folks, so do the software folks. So do the operations folks and so on. So they’re gonna, and, and they’re all, and they’re all facing unique problem. And they’re gonna improve in different ways at different speeds for different reasons, hopefully sort of all going in the same direction.

But you know, and but the other challenge is they have to work with each other. So, you know, it’s, you know, if, if my software team gets really good at, at being agile, but my financial team isn’t or vice versa then there’s a disconnect there. So we need to learn how to experiment with new, new ways of working across these very disparate teams.

Because if one team gets too far ahead or two out of sync with another one, then then you run in trouble and then, you know, you got grinding gears and it’s just not gonna work out. 

Murray: So Scott and I Shane and I are big fans of tailoring. So, so we, we will often say that you know, you, you need to start small, find out what works and, you know, grow from there.

Cause each organization is different and situation is different. So, so I, you know, I think we really like the idea of having like a menu of options or patterns. Would you say Shane? 

Shane: Yeah. And, and funny enough, I think I got it from Scott. So, yeah, when I started my, my agile journey right. In the early days I read, you know, cause I work in the data and analytics space primarily.

So I read some of the books from, you know, king Coley and Ralph Hughes and, and their adaption of agile practices and in the data space. And then I think it must been with your agile data.org site. I just stumbled across it. And then onto, onto dad And so for me, that, that philosophy of a toolkit of taking practices and patterns and crafting your own way of working that stuck with me for the last 10 years.

And it’s, it’s how I coach teams. And I suppose when I look at it now, in retrospect I can’t understand why the nuances are so important to me, but it is. So if I compare, you know, dad to safe, you know, and, and I apologize for doing that. So to you not to that’s but, but you had a, a toolkit, right?

You had a bunch of practices and patents that you had adapted from other things and said, if this looks like the thing, you are struggling with, try this, you know, whereas safe says here’s all the things other people do. You sh you shall do. You, you had built training material as a business model to support your development of that.

From what I can tell. And, and we know that the, the safe world is funded by those, those courses. And I think you also started certification, right? You started the certification process in, in the dad space, which we know again in safe as, as where the money is. So when I kind of step back and look through the window, I go, well, I could look at the way Safe’s being rolled out in the world and the way you did dad.

And I could almost say it was the same, but for me, it wasn’t. And, and I think it comes back to that fundamental philosophy of menu versus prescription. You know, they, she do it this way or here’s a whole lot of choices you have try. and then, you know, craft your own way of working, craft your good practice because you are the same as everybody else, but you’re also a little different.

So for me, yeah. Yeah, I, I swallowed the, the dad pill from day one, I think. And, 

Murray: So yeah, so, so we both really like the, the menu driven, tailoring a approach and, and you’re right. I am a safe SPC and I’ve, I’ve run PI planning and it’s very prescriptive. So with safe, you get like an hour by hour.

Description of what you’ve gotta do during PI planning. Like every meeting who’s gotta be there, what you do and so on. And I find that with safe people spend two months planning for their PI. Then they go through it. They expect the teams to commit to everything in detail, like as per book and managers expect them to then deliver it.

Exactly. So, I don’t think safe is waterfall, but it’s more like rep and rep applied to like a series of rolling three month projects. That I know safe is not supposed to be fixed scope, but that always seems to be the way it’s implemented. 

Scott: Yeah. It’s well, I, I think the, some of the challenges is, you know, to be fair to the safe guys safe is can, and be an, can be an improvement compared with the traditional ways of working.

Right. So, you know, rolling out safe in a traditional shop is, is probably a pretty big change. Almost always for the better. Yeah. But it’s only a start and I think that’s where people start to fall down. So, you know, we see a lot of safe shops that are, that are in fact doing better than they were before.

So, you know, you gotta give ’em credit for that. Yeah, but there’s still a lot of room for improvement and this is where the da tool kit kicks in. Particularly with some of the work we’ve been doing lately around value streams. So when PMI purchased the disciplinary organization, they also person purchased net objectives from Al Salway.

So Al came in and he had a methodology called flex which was all about value streams. And how do you, how do you actually implement a value stream in a coherent manner? And we brought, and it was interesting that that it fit in almost perfectly. So, we integrated flex into da, which has now formed our value stream layer and is the fundamental component of our Disman value stream consultant offering as well as our upcoming value stream management offering.

And it looks at the full life, you know, the full life cycle of a value stream. And how do you, how do you implement it? And how do you tweak it? How do you, how do you improve upon it? Right? Because you want to be constantly improving and getting better at what you do. And so it’s really coherent. It’s really, it really fits together well.

And of course we provide options, right? So, you know, we start you out, you know, we get you going, but then we say, well, Hey, you gonna tweak this? Well, look it over, you know, look at, look, you know, look at the portfolio management value process blade for options. And you know, so start here, but then, you know, you know, as you get comfortable at this level you know, start, you know, tweaking the dials and you improve your way of working based on your situation, your people, the challenges that you currently face.

So it’s not just, here’s a bunch of best practices go for it. It’s yeah, here’s a good starting point. And here’s how you, here’s how you improve from there on what you need to improve on. So it, it’s a, it’s a much different mindset. . 

Murray: Yeah, well, that’s good. And we’re gonna be talking to Al on this, on this podcast soon.

I think though we gotta talk about the elephant in the room here, and that is the PMI, because a lot of people in the agile space have a very negative experience with project managers. Now I’ve been a project manager myself, so I don’t view them so negatively, but I, when I was a member of the PMI back in, in, you know, 2000, I, I met a lot of very old fashioned conservative project managers at PMI meetups.

And you know, I think that there’s just gonna be a lot of people, very skeptical about the PMI, you know, really doing something agile. 

Scott: Yeah. You know, fair enough. You know, I, I was skeptical too, but what was interesting wa one of the things that attracted us to PMI was they, they were actively in the process at the time that we were purchased reinventing themselves and they had, you know, so we got, see under the covers and we also got to see some of the upcoming work, like stuff that’s now released, but at the time, you know, was still, you know, a work in progress in particular the PI buck guide seven, which is now a principles based not, not prescriptive.

Yeah. There’s still a little bit of prescription, but you know, nowhere near, near what it used to be and more of a hybrid. You know, still some traditional stuff and some agile stuff and lean stuff as well. Much better aligned with our philosophy and da. So, so for example, in da it’s not just agile, right?

So we put, we put techniques certainly from the agile space into context, but also lean strategies and traditional strategies as well, because our focus is on what’s the best you can do in the situation that you face and how can you get better? And sometimes the best strategy for the situation is a fairly traditional technique and that’s okay.

Right. So do the best you can. So the, and PMI like that now. There are some still a lot of legacy people and still coming up to speed. There’s also an issue around what I prefer to call tangible versus intangible efforts. So the intangible space is basically working with bits, right? So your it projects or you know, media projects, artistic things creative things.

And then there’s the tangible space. Where you’re dealing with atoms for the most part. So you’re building bridges and houses and, and whatever, and those are two very different things. So, you know, working with atoms, you’re starting to deal with laws of physics and stuff like that. Working with bits it’s things change instantly.

So, so you need to work in a much different ways in those spaces. Having said that the more traditional community that focuses on tangible efforts can certainly become more agile, like applying agile in the construction industry is a definitely a thing. And to be fair, you know, applying traditional strategies in the in the, in the intangible space do, do apply as well because, you know, we have to, you know, respect the fact that.

The, the traditional folks have gotten a few things. Right. So, even, even in the it space, so, and that’s okay. So I think there there’s that sort of thing going on. But certainly you know, the, the PMI has been involving just like every other organization. And but you know, if you look at the, if you look at the, at the latest materials I think you’ll be impressed.

The just the, you know, you know, the, you know, the principles based approach in the PI in the new version of the pinball guide is worth looking at, let alone anything else in, it 

Shane: sounds a bit like PMI have become agile in terms of, you know, inspecting, adapting and, and changing who they are. Yeah, the changes that are happening around 

Scott: it’s, you know, it’s not, not something you they could possibly avoid.

You know, you know, agile is real, it’s here to stay. You know, like it or not. So, and, and even in the, even, even in the construction industry, I go, I I’m often interact and it’s, and it’s really interesting, like some of the problems they take on but I’m often interacting with people in the, in this tan, more tangible space and working with them to try to figure out what, what, what is it that you’re doing, but also, you know, how can that improve?

You know, how, you know, how can we start doing better here? And and there’s lot, you know, there’s always lots of opportu. And also be fair, like, and this is one of the, one of the things that’s interesting about the da toolkit is it goes far beyond software. So I think one of the challenges with the agile community is it’s still overly focused on software.

Cause I, you know, that’s, that’s its, you know, that’s its history, but you know, the fact, you know, earlier I was talking about finance and procurement and, you know, legal and marketing, all these other aspects of your organization have, you know, are not it specific. So you know, you, you see marketing and in construction firms and, and procurement and construction firms, and certainly those aspects of those businesses can improve.

And even, and even construction firms are still effectively software companies, you know, they’re still running on software, they’ve got logistics software. They you know, they’ve got design software. So the key things in a construction company are often software based. You know, I don’t, I don’t know of any construction companies that, that compete on their ability to pour.

You know, it’s just, doesn’t, it’s not the way it works. But they darn well better be good at pouring cement. Don’t get me wrong. 

Shane: So have you found that by kind of joining the PMI, this, you know, so, so moving dad or da under, under PMI that it’s opened up the audience to your toolkit. Did, did you find that beforehand you were a, a lesson known.

Term, you know, we, we heard lots of safe and scrum and, and lean and flow and Kaban, and we heard a little bit of less and little bit of nexus, but you know, not, not a lot, especially not over here in New Zealand. Actually heard quite a bit of, of dad over in New Zealand because you had a certified trainer over here.

And yeah, he was, he was talking about it, which was great, but I got the impression that, you know, it wasn’t well known, even though it was publicly available, freely available and bloody good. Have, have you found that’s changed now that you’re under a, a brand? 

Scott: Yeah, it it’s, it’s gotten a lot better.

Yes. We were being out marketed. There’s nothing we could do. We were, we were overwhelmed, you know, the safe guys are marketing professionals. The, you know, the scrum folks just had word of. You know, entrenched, you know, totally entrenched. So yeah, we were getting killed just like the last, the less guys were getting killed too on marketing.

Right. We just, we weren’t just getting our message out and, and others you know, as you’re pointing out. So yeah, we were, it wasn’t good for us, but yeah, PMI has a lot more marketing cloud. We’ve got the, the chapters, which are amazing. I’m, I’m just constantly amazed about the really good stuff that’s going on.

At the chapter level, they really are there to help and to share information to help PE people come along. So that’s that’s good news for us. So we’ve been getting, getting the word out at the chapters and you know, we do have a marketing budget now. You know, our, my marketing budget before was, you know, whatever, whatever it cost me to, you know, speak at a conference so my travel budget yeah, so we just, we just didn’t have the marketing budget back in the day.

Shane: And I’m assuming it’s part of being PMI. You’ve, you’ve now got the ability to look across a wider audience and see the change that’s happening in the, in the market and the world. And so near the beginning, you talked about you know, as you started your journey, you, you were looking that there was lots of waste waste in the way organizations work.

Do you think that’s any different now? What is it? 13, 14 years old now? Or does it, has it gotten any better? 

Scott: No, I don’t think it has maybe a little bit, but the, the challenge is one of what just a people overwhelmed with the marketing rhetoric and the, you know, I like to talk about how, even though I love scrum, I, you know, I like to talk about how people have scrum blinders on.

It’s amazing how many times I get into conversations about, well, how do you do this in scrum? And how do you do that in scrum? Why don’t you just Google it, dude? Like, you know, like how do you do architecture and scrum. Why don’t you Google it or, you know, but, but the problem is, is the, the termin, you know, people have gotten roped in by the terminology and they, they focus just on the scrum stuff, not realizing there’s this wealth of material out there available to you, like earlier talking about the agile modeling site, which has gotten a bit, I’ll admit it’s gotten a bit stale.

But I, you know, I, I improve it as a, as a hobby on the sideline and the agile data site as well. And those are like, like there’s just fundamental concepts there. But if you don’t know how to search on terms like modeling rather than mapping or, you know, whatever, whatever the fanciful terms that are being used desperately avoid the term, like terms like planning and modeling and, and others.

You’ll never find this material. I, if you even not even if you even think to go look for it and that’s a serious problem. So the. So you, so you get people just locked into scrum, so, or, or, or safe as the case may be because that’s the only thing they know they’ve gotten training in scrum. They like, they get framework training and, or method training, you know, depending on terminology.

And then they get locked into framework gel, like, like Evo, Evo, Y likes to talk about. And they never think, you know, not only are they in framework jail, but they don’t even know to break out. They like, they can’t even recognize they’re in jail. And you know, so then the idea of breaking outta jail is a bit radical.

So, and this, this is truly unfortunate. And I, I was just on a call earlier today where people were basically equating scrum with agile and they had no concept that there was other things out there. And it’s amazing how many people, like who are reasonably new to the community have never heard of things like extreme programming.

Or TD 

Murray: sad 

Shane: and, and you know, the number of times when people say the word scrum sorry, say the word agile, and then you, you listen to them. You’re going, so you’re talking about scrum. And then you go, well, you know, do you use a Kaban board? Yeah. So you, you’ve kind of mixed your toasties already, right?

You’re bringing in, do you do peer programming? Oh yeah, we tried that. Cool. So yeah, you know, that came from somewhere else. Right. Really, really useful. So yeah, I I’m with you that people. Scrum is agile. You also, you kind of picked up an interesting theme there and, and we will often go off and, and rent on the idea that after a two day certification, you are supposedly a master of something.

And you know, my view is certification or, or training is great, right? Starting off with somebody explaining the basics to you, gives you a language, gives you a place to start. It it’s valuable do it. You know, it, it has value, but it doesn’t make you an expert. It doesn’t make you an coach in any way. And it’s not until you’ve, you’ve experienced and practiced with teams doing it for a while that you realize that there are other ways of mixing it up.

Do you find that, that it it’s this whole market of a two day course is enough for you to be an expert? Whereas in fact, you’re a novice and then, you know, as you get more mature in your practice feel, yeah, you, you look out wider cuz you start hitting the barriers of what you’ve already been told.

Scott: Yeah. It’s The it’s unfortunate. The, the realities of the agile marketplace are really unfortunate with what what’s, what with what’s happened with certification over the last 20 years? Yeah, I’m a firm believer in good training and coaching and learning. But yeah, you’re not a, you’re not a master after two days.

Now having said that, you know, we do have a two day Disman scrum master course, which is we’re gonna rename it’s poorly named. And cuz we teach far more than just scrum mastery, but Yeah, it’s, it’s, it’s the reality of the marketplace, unfortunately. If you try to, you know, if you try to force people to earn their certs you know, that’s, it’s a killer in today’s marketplace.

So, you know, you know, when, when you’re competing against, you know, take this two day course, and you’re a certified master versus, you know, work along, you know, work really hard, take a really hard test. And then maybe you’ll pass be to become a novice. Um Hmm. That’s from a marketing point of view.

That’s not the greatest strategy. So yeah, so this is why, but what’s also unfortunate. If you look at the, if you look what’s going on in the marketplace, the vast majority of introduction to agile is this certified scrum master training. It’s really hard to find just a general agile workshop. And then if you do.

It’s not well attended because you’re not getting some mastery certification. So the market’s a mess. As a result of this people should stand up and say something. They really should push back. Once again, they don’t they’re in jail. They don’t know it. It’s it’s really that bad. Now. 

Murray: I, yeah, I, I wanted to reflect with you on the, the state of the, the industry because Martin Fowler had a great talk at 2018 at, at the Australian agile conference, which you, I remember you can see it online or you can, you can see what he wrote about, but he talked off the cuff about the agile industrial complex.

You know, he didn’t use method prisons, but he was talking about the same sort of idea. He, he was saying that the big problem in the agile community now is fake agile, everywhere. He goes, people say oh yeah, we, we are doing agile. We know all about agile. And you know, he asks a few questions and he finds out that they’re doing some fake agile bullshit, frankly.

And, and I’ve seen that as well, a lot when I’ve coached people. So, so the, the two patterns that I see a lot of are people are doing scrum, but everything else is the same. So they’re working in silos with stages and gates. It’s just that each team, the business analysis team writes these, you know, 10 page, business analysis, user stories, and then hands them on.

They do the in, they have six sprints of that, and then they hand them onto the design team, that sort of thing, you know, and everything’s all fixed. There’s that pattern. And the other pattern is safe, which I don’t think safe is actually agile at all. It doesn’t, even though it’s got the word agile in it’s named, I don’t think it, it fits with the agile values.

So in the, what I see a lot in safe is fixed scope, fixed time, fixed budget, you know, no, no agility at all, you know, did completely disempowered teams. So. There’s just, it’s actually really depressing to, to be honest, you know, just still there’s water scrum, full, fake agile, and you know, a lot of people congratulating themselves.

I’m just wondering if you see that too. 

Scott: Yeah, it, I see that a lot. It’s it’s unfortunate. Well, the, the problem is, is that we. You know, at the beginning, I, I was there at the very beginning and at the, in the beginning it was, you know, we, everybody was trying to, you know, really sort of push the you know, push the market forward and push, you know, push the state of the art forward.

And there was a lot of really good vibes. And we were really, you know, trying to do some really good stuff like the first few years, that’s that’s when you know, extreme programming, you know, at the very beginning, extreme programming ruled the roost. It was the thing Zen Zen scrum was dead in the water, absolutely dead in the water.

Nobody cared. The, you know, this agile modeling came out of extreme programming. Then agile data came out of agile modeling. Cuz we were working on fundamental challenges at the time. But then the, the scrum certification stuff came around and was all over. Right. And we didn’t, and you know, a group of us pushed back hard.

But another group of us saw money and money won. Yeah. And us an unfortunate side effect now is that we’re all pretty much in scrum jail. We have completely lost the idea of having to earn a sort of, you know, having to actually work for a, a certification. Like it. It’s interesting if you were a chance to talk with real professionals like lawyers or architects or doctors, and then explain how people learn and get certified in in our community.

They’ll think you’re lying. I I’ve literally been out like a dinner and my wife’s a landscape architect, and I’ve tried to explain to architects who have, have to spend sometimes decades to get to the, to become a IR recognized as a master. And I literally had a conversation once trying to explain some of the, the certification schemes in agile.

They first thought I was joking. They second, and were amazed at how anybody could get away with that and how the, how, how profe, like how the community would even tolerate it. And I said, well, you know, it’s it so, they, they, and, and it’s real shame and we’ve done ourselves a great disservice as a community.

And I, I, I can’t see how we’re gonna dig our way out of it. It’s it’s just too systemic. 

Shane: Yeah. And Agile’s not the only place we’ve done that. So yeah. Data engineering, data, warehousing, ETL development, whatever the new buzzword for it is. Cuz we do the same things. As we do an agile, we take something that works and we rename it and break it.

If we look at that as a, as a domain, as a, as a an expertise and you go to somebody and you say, well, the engineer’s gonna write some code and they’re gonna push that code to production. And then the user’s gonna test whether the data’s right for them by using. You know, we, we have no practice.

There is no certification of the way we work. If we were, like you said, if we were surgeons, we would be killing the patient on the table eight outta 10 times. 

Scott: And we would, we would be failing fast though. So that would, we’d be killing . 

Shane: So, so on that note, so, as I said, because you wrote about agile in the data space, which, you know, still is unusual.

If I look at it from a domain specific point of view, there is very few people that are taking agile practices and applying them in the data space, or, sorry, rephrase that. And then sharing the results of what they learn with the rest of us. Yeah. Do you think and, and, and when I try to explain to people why applying agile patterns to data teams is different to software teams, it’s always is always an interesting conversation.

Do you think that that’s where we are gonna go in, in, you know, over the next couple of years is move away, hopefully from these framework jails, but move to towards toolkits that are domain specific, where we say here’s all the patterns and practices, but if you’re in this domain, these ones seem to have more value over these ones.

When you start, you know, is, is that where we’re gonna end up or is it really just gonna be one, one tool to roll 

Scott: them? It’s hard to say. I sort of, I sort of hope that’s the way it’ll go. You know, you’ll, you know, I’ve seen some good stuff, you know, there’s the agile marketing movement, there’s the lean agile procurement stuff.

There’s other other areas have, you know, body or growing bodies of knowledge. The problem though, you know, there’s great stuff going on in the UX community. But the problem is, is that they end up being, they see themselves at the center of the universe, right? So, you know, when you’re, you know, if you’re to go to a marketing conference the marketing people are pretty much convinced.

They’re the most important group of people at the organization. If I was then to, to go down the street and attend a procurement. Obviously the procurement people are the most important people in the organization and they’re there saving the universe. And then if I was to walk down the street and attend a an it conference, well, very clearly the, it, people are the most important people around and they’re of course the saviors of the organization and so on.

And so and so on. So. Having these separate, and, and this is the problem with the traditional data community, right? They’re off, you know, they think that data, you know, they’re the center of the universe cuz they, they have a, a death lock on the data. And that was one of the reasons why we, a bunch of us put the data, agile data method together to begin with was to, you know, give them a slap upside the head and say, you know what?

You can do a lot better than what you’re doing. And, and here’s how, and BA you know, if, if you looked like at the, what was in the, the DM box at the time 90% of it was, you know, this traditional stuff that made no sense whatsoever except to data bureaucrats. And then, you know, we just called BS on most on most of the, most of the assumptions in that, in that body of knowledge were just fundamentally flawed and the rest of the material was fundamentally flawed as a result.

And then in, in the agile data world, we say, well, wait a minute, Let’s let’s question the assumptions. Cause like one of the assumptions in data was that production databases are hard to change. And I still run into data professionals that believe that and that there is no proof of that. What’s and there is significant proof that it’s absolutely trivial to change a production database schema safely, if you know what you’re doing and that’s where, that’s where it all falls apart.

Right. So if you know what you’re doing, yeah. I could, I know I can change a production database scheme and no problem at all. But if I don’t have the skills and techniques to do it then yeah, it’s a phenomenally, phenomenally dangerous thing to do. But the problem is, was they never broke out of their assumptions.

So anyways, what’s got, so if we go for domain specific agility and I think that’s a trend then you’re gonna start, you’re gonna start seeing silos again because everybody will go off in their own direction and it’ll all be the center of the universe and it’ll be like trying to integrate. You know, if you ever had to integrate software packages every software package believes it’s the center of the architectural universe, right.

And that everything else has to integrate with it. Otherwise it’s not gonna happen. Or it’s absolutely brutal is the way it plays out. And this will, this will be what happens with all these you know, these various agile domains. It’d be great stuff by itself, but if it doesn’t fit in with everything else, well then it’s not gonna.

Shane: But we can solve that. Cuz we just bring in terms, right. We’ll come up with micro agile services or service architecture. Yeah, there we go. We can, 

Scott: There’ll be, there’ll be process cleaner. 

Murray: agile service architecture. Yeah. And you of first here. I 

Shane: and yeah. Agile, agile interface contracts. There we go.

Scott: yeah. You just heard the new buzzwords folks for 2022. 

Murray: Hey Scott, what I, what I see as, as being in, you know, an emerging direction that’s getting quite a lot of steam is the whole idea of moving from projects to products. So, you know, the scrum community has really got behind it because they’re trying to turn product owner into product manager by the look of it that sort of expands the universe.

And they’re not the same thing, product owner, product manager, but, but not at all. But yeah, I, I really like the, the idea of having a product focus. You know, I quite like projects as, as well in some cases, but you know, this idea of having, bringing everybody together around a cross-functional team, you know, working iteratively and incrementally around the product, focused on real users and real customers seems to be, to be a really, you know, that that’s like a core agile concept, even though agile didn’t talk about products at all.

And agile, agile manifesto, you know, can, is, is really written from an it point of view. But you know, I, I love this movement into. Into products and product focus. I was wondering what you, what you think about that? 

Scott: Yeah, I, I do too, but it depends. Right. So I think, I think what’s happened is the, I guess that’s a trend that makes sense in the it world for it.

Some it projects I should say. So, but the reality is, is that there’s always gonna be projects. There will always be not projects. There will always be some sort of agile approach and some sort of lean approach, but there’ll always be some sort of traditional approach as well. So I view the project to product movement as, as more of a, you know, it’s a subset of the overall the overall vision or, you know, the overall environment.

So, yeah, so, so I think fair enough. I think in the, particularly in the intangible space when you are actually working on products or services or combinations thereof then having a longstanding team. And, and, and the teams evolve over time. Right? Cause it it’s, you never have the, the exact same people forever, but yeah, having longstanding teams makes sense.

Having them as cross-functional as possible makes sense. But they’ll never be fully autonomous. So, so in da we support multiple life cycles. We don’t inflict one way of working on anybody. So we have an agile project life cycle, but we also have an agile, continuous delivery life cycle, more of a DevOps type of a thing.

We have a lean project, life cycle and a lean continuous delivery life cycle, like a pure DevOps type of thing. We also have an exploratory life cycle for when you’re you know, taking a hypothesis of an approach with MVPs and trying to figure, you know, basically lean startup and of course, a program life cycle.

And we also It’s not released yet, but we’re, we’re gonna be adding citizen developer life cycles as well. 

Shane: So on that though, you, you mentioned something before and you kind of reiterated it here is this idea of a menu. Yeah. And I think in the previously you talked about menu versus prescription.

And one of the things I did struggle with with, with the da stuff or the dad stuff right at the beginning was there was lots of choice. You know, I could, I, I kind of likened it to when I was a kid, I used to read those sci-fi books where it was pick your own adventure. You’d read a page and it’d say, now go to page 59.

And, and I often found that within the da side, I got lost. Yeah, I went off on a lovely journey, but I didn’t answer the question of this is what I’m stuck on. What’s next. And so I can see that complexity, that choice, you know, if I think about, if I go to a Chinese restaurant and there’s 600 different dishes and 500 different versions of rice, I, I dunno which one I want.

And I, so I’ll start off with a set menu maybe is, is, is that what you see as a way of, of balancing out that complexity of choice with just make it easy for me to start or, you know, have some of the more prescriptive methodologies got it right in there. Actually, I don’t get a lot of choice, at least I know what the next step is.

Scott: Yeah. So I think we real, excuse me, we really need something in between and because people need recipes, they need start, you know? So, we like to use the, the, or the metaphor of cooking dinner. You know, so if you don’t know how to cook, if you don’t know what the ingredients are me just telling you, yeah.

Go to the grocery store and buy some ingredients and make dinner. Good luck so that’s not gonna work out well. So people want recipes or better yet. They just, you know, they’ll end up going to McDonald’s gimme the big Mac, you know, supersized meal deal. But the problem is you can’t eat a big Mac for dinner every single night.

It’s not healthy. And and you need tr you need a little bit of help learning how to cook, and you’ll, you’ll never be a chef maybe, but you, everybody can learn how to cook and everybody can, and, you know, learn how to follow recipes. And, and even when you start cooking a dish for the first couple times, I follow a recipe.

But eventually I learn it and sort of learn it depending on who you talk to in my family. And, and then I start tweaking it, right, because I know what my daughter likes, what my wife likes and so on. And you start tweaking the recipe and eventually you just start, you, you gain the skills to put together on your own and you know, you’re missing an ingredient.

So you throw something else in and you learn those skills. And the problem is, is. the so da, when it was originally presented was, you know, here’s all the ingredients. Here’s, here’s the trade offs. Here’s when you would use each ingredient, but we didn’t have any recipes. The issue at the other end of the spectrum with the prescriptive frameworks is here’s a recipe for, you know, one recipe for K chicken catch to and you and darn well better, like want to eat chick catch to for every meal, the rest of your life.

Cuz that’s the only thing we’re gonna teach you because that’s the best practice is eating, is eating chicken catch to for dinner every night. There’s gotta, you know, we need something in between. So we are working on starter what we call starter kick kits or starter packs to get you going on that like, one example.

And it’s not the greatest example, but it, it is one actually on the agile data site, I have a description of how do you do a, how do you, how would you approach a data warehousing project? In da, I mean, it’s still, it’s reasonably high level, but it, it walks you through. Here’s what you do. Cause it makes the choice, it pulls the choices off the shelf for data oriented stuff outta the toolkit and plus a bunch of other things as you, you, you know, it’s more than just data techniques, but these are the sorts of things that, that we would need.

We’re working at, you know, that’ll be a 20, 22 thing for us. Mm-hmm 

Murray: Wondering if we, we should you know, do a bit of a summary of our, our thoughts on this Shane, what do you reckon? 

Shane: Yep. Go for it. You go first or second. 

Murray: I I’ll go first. So. There’s such a lot of stuff you’ve been working on. Scott, it it’s you know, I, I think you are an underappreciated writer and thinker in this space and, and I’ve, I’ve said that to a lot of people, I, you know, you’ve, you’ve done such a lot of work on agile architecture, data modeling, you know, across everything.

And I think people should go and look at it. Like you’ve still got those websites that people can go and look at. 

Scott: I do. Yeah. And I do it, evolve them over time and. Constantly tweaking here. I, I can’t let it go. yeah. 

Murray: And, and I think, I think the thing is that you’ve been sitting outside the major organizations that’s like sitting outside scrumming safe and that’s why you just haven’t been getting that the recognition I think you deserve.

Thank you. So, I I’ve always really liked what you’ve had to, to say about this space. So we’ve talked about such a wide range of things. That’s, that’s one thing disciplined, agile delivery flex and wow are really interesting. I really liked the wow book I read through it. I don’t know much about flex, so, you know, I’ve gotta learn more about that.

I don’t even know where to look on the, 

Scott: Hey, well, if you’re, if you’re gonna talking with Al Shao he’ll fill you in fantastic work there. He’s also underappreciated as well. I think. 

Murray: He did some, yeah, I’ve always really liked his stuff. I’ve read some of his books as well. And I really liked the discussion about method, prison.

So many people I come across think that agile is, is scrum. And like everything is scrum, scrum, scrum, you know, scrums. Great. Like I think we all agree. We like scrum, but it’s just, you know, a slice of the pie yeah. Of the whole pie. And or otherwise, you know, it’s all just safe, safe, safe, and, and safe is just being implemented in safe is safe.

Is got a lot of good things in there. I think if you treat safe like a menu of different patterns you can use, then it’s quite good. And I know some very experienced, safe practitioners who do that, but you know, safe itself has been it’s it’s not the low process. Framework that we were looking for when we developed agile, it’s a, it’s a heavy process framework.

It’s very much like rap, I think. So people get, people get locked in that and you know, that people really need to think about this. Are you seeing the world from a scrum point of view? Are you, are you in the scrum prison or are you in the safe prison? Because it’s time to break out. There’s so much more.

I think those of us who are in it at the early days with XP and everything realize this and people who’ve just come in through the scrum door or the safe door, just think that’s all there is. And there’s so much more. And there’s also this really fundamental problem going on where organizations are tailoring, scrum and safe to be like their traditional authoritarian command and control siloed bureaucracy.

That’s the kind of tailoring I see going on. And You know, people need to realize that to get, really get the benefits of all the stuff we’re talking about. You really need to challenge these silos. I mean, it’s all about, I, I wrote an article on managing uncertainty and models of uncertainty on medium.

And, you know, I think that the factory mindset has its, has its place. Factories are great for producing, you know, a, a billion pins or, you know, 10,000 Teslas that are exactly the same. Cause it’s cheap and efficient. Yeah. But software and products are not like that at all. Nothing like it because there’s uncertainty.

And learning required. And every time you write a piece of software, you’re learning something new and doing about the business, about the design and is it technology. So you’re doing something different and traditional fixed scope, siloed methods, just work very poorly in this space where there’s a lot of uncertainty and learning, I think, and agile works great.

So if you want the benefits of agile, you gotta, you know, do it properly and not try to force it into this factory mindset. 

Scott: Yeah. 

Shane: Yeah, Shane. Yeah, so same key thing came out. You know, it, it’s not a framework, it’s a toolkit toolkit. So where the value are. Yeah, there is no such thing as best practice.

There’s just a bunch of good practices. Other people have done that may have value for you. So adopt them where it makes sense and adapt them where you need to change it and trash them where it doesn’t work for you. As long as you’ve proved it didn’t work for you. Right. Don’t don’t just try it for 10 seconds.

The idea of framework jail or method jail or framework prison is not a term I’m familiar with is always, I, I learn new stuff on this, these podcasts every day. So that one I’m gonna go and use and abuse cuz I like it. The idea of tangible versus intangible that, that, that CA that’s a new one for me as well.

This idea of building physical things versus building intangible things. I think I always struggled with, you know, We’re describing where waterfall traditional ways of working had value. Cuz they did, you know, I, you know, whenever I was teaching somebody and they come from a traditional background, they say, well, why should we adopt their job?

You know? And, and there’s some reasons where it’s useful and there’s some reasons where it’s, it’s hard. Yeah. So, I think that tangible versus intangible, cuz me some quite nice framing of, of how to describe that. I think the idea that when we have a menu or good practice, we increase the complexity.

So a fast start or a way of, of entering that early and learning from that. And then as we get more maturity, I think that’s highly valuable. And you know, one of the organizations I worked with. They started looking at safe a lot, not because they were gonna adopt safe, but they found it as the prettiest way of understanding all the moving parts and which one they may wanna look at next.

Yeah. So as they say, six cells, so, let this make the menu pretty and, and easy to digest. But the main thing really is be true, who you are. So, you know, you, you, you invented dad and you’re the king of dad jokes. So that’s like the ultimate branding as far as I’m concerned.

So, yeah. I think the last one for me is, is you said something that that’s true to my heart as well, is that in, in the agile domains and in the data domains and in some other domains we talk about certification, but we don’t do it. Justice. If we go to our, you know, our medical brethrens or our accounting, brethrens, you know, they have a true certification process where they, they are deemed worthy to do the work.

They do. We, we don’t, we use their terms and then we abuse it. So we should look at ourselves and, and actually rectify that, remove the term or do it properly. But don’t, don’t keep abusing somebody else’s terms. You know, it’s like project managers who do standups, you know, doing a stage at stand up as a project manager where the team collaborates on a daily basis is great, but it’s not agile.

Yeah, there’s more to it, but it has value. Right? So, so certification has value, but let’s let’s not abuse it as much as we do now. So yeah I think for me ending out, it’s not a framework, it’s a toolkit. 

Scott: That’s the thing. That’s something I, I, I wanna, I wanna point out. So I’ve been looking for best practices for decades.

I’ve never found one. I’ve had thousands of strategies and practices presented to me as best practices, but every single practice I’ve ever run into works well in some situations. So it’s best in that context. But is a phenomenally bad idea, other context context. So it’s not really a best practice. Similarly I’ve never seen a worst practice and I’ve looked for those too.

I’m hoping to find at least one but there’s always. No matter how bad the practice is and all are, you know, religious wars about, oh, this my practices can beat up your practices. I’ve never found one that I couldn’t find something good to say about it’s sometimes it’s been hard, but you know, there has been some situations where I, I would recommend yeah.

That practice, you know, that’s, I would, that’s probably your best bet in that situation. Even though I hate that practice, but it’s your best, best bet there. So I think, and so you’ve gotta be able to choose, you gotta learn how to choose. And otherwise you’re a one trick pony and that I think is a big problem with a lot of people right now that are effectively one trick ponies and don’t realize it.

Murray: That’s great. Really appreciate it. Anything else to say, Shane? 

Shane: No, it’s reiterate that the context of when that practice or that pattern was applied is important. Yeah. You know, we all walk into work. Other people have done and we like to bag it. What we, what we hardly ever do is we hardly ever spend time understanding the context of why that practice or patent was implemented.

Why was that chosen of all the choices they had? And, and once you understand the context, nine times outta 10, I sit there going, yeah. I don’t like the decision, but if I was in your shoes at that time, with that context, yeah. I probably would’ve made exactly the same decision. 

Murray: So yeah, I, the, the key thing is, you know, there’s a, a lot of patterns you can look at and there is a good pattern for you for your situation.

And, and that’s what I really like about your approach in, in find your wow, that you, you know, it’s like a, it’s a patent book, really with some guidelines on how to choose them. So, yeah, it’s been great. 

Scott: Excellent. Yeah. Thank you. 

Shane: All right. On their note. We’ll catch you later. 

Scott: Okay. Yeah. Thanks for taking time outta your busy days to listen to the podcast.

thanks for, thanks 

Murray: everyone. That was the no nonsense agile podcast from Murray Robinson and Shane Gibson. If you’d like help with agile contact Murray evolve, that’s evolve with zero. Thanks for listening.