Transcript:

Jim (00:02.062)
Welcome everyone to the next episode of Mastering Agility. This is Jim. I’ve got my normal co -host, Sander, with me and we’ve got an amazing guest today. Gojko, can you please give the audience a quick introduction to yourself?

g (00:16.242)
Hey everybody, I’m Gojko. It’s amazing to be on this show. I’m a developer. I’m kind of used to do lots of consulting now, mostly building my own products. And I like writing books. That’s one of the ways I get to kind of empty my short term cash memory into something longer termish.

So I wrote a couple of kind of books that for whatever reason became popular. It’s amazing and here we are

Jim (00:46.126)
That’s right. Well, uh, I’ve been using your books and the ideas from especially spec by example for a number of years now. So that’s why I’m really excited to talk to you. But, um, so we’re going to dig into that here in just a moment, but Sunder, how are you doing?

Sander (01:02.693)
I’m doing wonderful. Thank you. I’m still writing a good high from a teaching a PSPO class yesterday and the day before it was a really good one. Um, so I’m still writing that I’m really enthusiastic, energetic to, to have Goyko here as well. I mean, the, in, in the professional scrum material, there are references to your book as well. So I’m really happy to have you.

Jim (01:21.55)
Yeah. And you had some travel recently, didn’t you? Or is that upcoming? Yes. Next week. Ah, OK. OK. Well, so, Gojko, let me just tell you kind of what, or I’ll tell you in the audience, what I’ve been the most interested in, which is visualizing specifications.

g (01:21.844)
Yeah, thank you.

Sander (01:27.525)
Me? No, that’s next week. Next week we’re going to be in Helsinki at the Scan Agile Conference.

Jim (01:48.174)
So just to start us off, what I would like to kind of mention is the book Specification by Example, how it helped me and how I use it with teams and clients is moving away from words and adding in pictures, graphs, charts, visuals, examples of what those words mean. So was that where all this started or what kind of led you to?

want to write this book in the first place. And you know, obviously you’ve written a few, but I’m starting kind of with specification by example.

g (02:23.798)
I don’t know, I’ve always been an edge case. When I moved to the UK from Serbia, I went into the bank to open a bank account and then after about half an hour of typing all the information people can get from me, the bank clerk said that they can’t open my bank account because I’ve recently been released from prison, which was like, what? And then it turns out that the system, if you’re not on the voters registration list…

immediately says you’ve been recently released from prison because of course that’s the only reason why you wouldn’t be on the voters registration list when you open a bank account. And yeah it’s kind of I tried to make good software kind of for as long as I know you know.

Jim (03:04.206)
Nice.

g (03:19.146)
When I was a lot younger, I used to be a leader of a team where we would kind of do outsourcing, but we’d kind of charge a fixed price and I’d pay my team members a variable price. So the thing had to go out the first time around and not come back because if it was coming back, the client wouldn’t be paying more.

and I would be paying people. So, kind of, you know, that was opened my eyes to lots of problems with software quality. And then later I started working for some larger organizations where there were lots and lots of people there and you can see communication problems causing issues. Everybody thought that they knew what they were talking about, but things were just falling through the cracks. So I started looking for ways of solving that.

And that’s how kind of I picked up on lots of different ideas that were described in the Spec by Example book. So that was actually my third book on that topic. The first book nobody knows about because I had a contract with the pragmatic programmers that they cancelled. Like when the book was already done, it’s supposed to go to printing, which left it like really in a desperate state.

So I self -published that and like nobody knows about that. Then the second one was bridging the communication gap, which was kind of slightly more systematic and had lots of like my experiences and then I got really angry at the conference in Germany where I was listening to somebody on the stage talking about how in the real world nobody does stuff like that. And now it’s purely theoretical and then I decided look I…

Jim (04:59.854)
Hehehe

g (05:04.182)
I want to do a book that shows how serious organizations are actually using, spec by example, using VDD, using these techniques to solve real problems. So I started kind of getting in touch with everybody I knew that is using this and begging them to do an interview. And then out of that, about 50 different companies accepted, some big, some small, and that’s basically what the book.

why the book came to exist. I wanted to have something where I could name companies, I could detail their process and extract patterns and show people that yes, there are people that are doing this in the real world. It’s not fairytale, unicorn land and things like that.

Jim (05:47.598)
That’s interesting. Do you have any tips to share or what was the experience like getting that permission from companies to either let you in to see the details of their process or to even be named in a book? And I’ll tell you why I’m asking. I’m working with Scrummed by Dorg on a case study write up for two of my clients and we’ve been talking and we all expect one of the biggest hurdles or the only hurdle maybe.

to be getting the approval for a client to be named because there’s a lot of normal reasons that people are hesitant for that. So what was your experience like?

g (06:29.334)
Well, I mean, it was took a long time, let’s say that. So, you know, I started the book with that idea. So immediately kind of when I was interviewing people, I kind of that was on the table. I wanted to have companies that we could name. And we actually got a few teams at big banks to sign off on that. We got some larger enterprises to sign off on that. And I think.

I started the book with that in mind and I announced it upfront so people would check with their, you know, management or PR departments or whatever if they needed approval for anything. And I gave them plenty of time to review it. So when the interviews were kind of first recorded interviews, then turned them into chapters and then kind of sent to people so they could get the internal approval, I think all in all kind of probably took

three to six months to get all the approvals. So plan for plenty of time and, you know, announce that upfront, I guess. And then I think, again, the benefit of this was that when I was writing about that topic, it was still like new and fresh and people in these organizations were internal champions who actually wanted to do the same thing as I did. They wanted to show that these things are…

These things exist and their teams are actually that good. And I think for lots of these teams, the book became a really good internal promotion because they could point to the book in their company and say, look, we’ve been named as one of the leading teams in this book and we’re using something new and cool and important.

So I guess it was a win -win for everybody and it wasn’t particularly difficult, it just took a long time.

Jim (08:28.334)
Yeah, yeah, I just flipped. I just flipped open the cover of the book and the second printing that I have was from 2012. So, I mean, that’s 12 years ago and I still am finding people out there that when I mentioned, you know, specification by example, they’re, you know, they give me that look that tells me they don’t know what I’m talking about, which is OK, right? There’s more information out there than we can all consume. But what patterns have you seen over the last 12 years that?

g (08:37.972)
Yeah, yeah.

Jim (08:56.502)
you’re dismayed that they’re still persisting and what benefits or what positive patterns are you seeing in kind of this area of translating what we want to what we actually get?

g (09:10.644)
Look, I mean, in terms of adoption, you know, these ideas have been around for a long time. There’s Donald Gauss and Jerry Weinberg wrote a book called Exploring Requirements. It was published in 1989. And you see kind of…

some common ideas of what they were doing then, in spec for example. Ward Cunningham was using this on the Vikesh Plus project in probably early 90s. So, you know, even when we were adopting this in 2005 -06,

There was probably somebody who could have said like, you know, we’ve done this 30 years ago and the industry is still not adopting it. And I think this is where, you know, we’re hitting like Sturgeon’s law, really. Sturgeon’s law says that 90 % of anything is going to be crap. So 90 % of the teams out there will just not be good at developing software. And they’re going to kind of have problems that were self -inflicted and so organizationally inflicted.

Jim (09:54.636)
Mm -hmm.

g (10:19.35)
that they don’t wanna fix because that’s not their bottleneck. And in terms of where these things were going kind of last 10 years or so, I think what’s happened since I wrote the book is kind of a consolidation around tooling. When I was…

Jim (10:37.856)
Mm -hmm.

g (10:42.824)
writing the book, there were lots of different tools on the market. And I think Cucumber just came out when I was writing the book. I actually wrote the book in 2009. By the time it was all done and approved and edited, it was already 2010, 2011. So yeah, Cucumber was just emerging back then. And…

And the whole given when then a system of describing examples was relatively new because Liz Keeo and Dan North kind of came up with that in 2006, I think. So it took a long time for that thing to get such a wide adoption. And I think that’s the biggest change actually from…

When the book was published today, everybody seems to be doing kind of given when then now as examples, where it wasn’t like that, you know, 15 years ago.

Jim (11:42.83)
Yeah. So Sundar, you were just teaching a class on product ownership this week. I was catching up with you on WhatsApp and LinkedIn. So did any of these concepts come up in this week for you where it’s, you know, maybe requirements, specifications, or just people in the product realm trying to capture what it is that they’re trying to build?

Sander (12:07.747)
Oh yeah, absolutely. I, the biggest struggle that I see or that I saw in the, in these specific classes were more the organizational impediments where the behavior, especially of middle and higher management become the bottleneck in the adoption of these kinds of things. And by doing so people tend to be more battling these kinds of issues rather than actually doing either discovery work or specification work or figuring out these kinds of things. There are so much in the.

and until then and struggling with the political games that they don’t have any time left anymore to do actual specification work or design or discovery what value actually means. And I’m curious about that in your experience as well, Gojko, what has been the biggest bottleneck in the adoption of the theory that you passionately wrote in your book?

g (13:01.942)
That’s an interesting question. I don’t know if there’s like one single biggest bottleneck really. And again, I’ve not really been working as a consultant for quite a long time now and I don’t know what the current situation is, but I…

Imagine as you said it’s mostly politics and things like that now because can really people that are now starting to adopt Agile are so late to the game that you know the question is why they’re now looking at it and the answer is probably that you know they’ve been stuck in political

crap for the last 25 years and now they’re looking at it. So, you know, companies like that, nothing’s going to help them. And they’re going to keep looking at seemingly agile processes that just require them to, you know, rename people and roles like safe and things like that, because they actually, you know, they don’t want to build better software. They want to pretend to be better.

They want to pretend not to be so late to the game so that they can still hire people. Because you have to have like, this is not pure marketing. You you can’t hire people to do waterfall anymore. And, but they don’t really want to change anything. So I would imagine that, you know, this late in the game, that’s actually the key problem. When I was working as a consultant, um…

people were a lot more enthusiastic about actually doing good work. And I think from that perspective, what I love is the process that Chip and Dan Heath described in Switch. And I’ve used that with great success lots of times.

g (14:52.374)
So Switch is a book about causing organizational change where you don’t have really any political or economic influence and how to do that. So it has nothing to do with software, but it’s just kind of a book about figuring out how to cause organizational change. And they have lots of really interesting stories, but one kind of thing that stuck with me is they talk about how generally people don’t object to change, they object to being changed.

and imposing an external thing on them is a problem. And how people often don’t like, one of the biggest problems with any process change is that people disagree with the problem, not with the change. So they disagree that they have a specific problem because they might think that something else is a problem or they might not understand the whole picture. They understand only a small part of the whole thing. So kind of…

What they talk about in the book is like the step number one is to actually visualize the problem, not talk about solutions. And in case of spec by example, some problems that spec by example solves is kind of lots of rework caused by misunderstanding, by kind of business bugs, by…

poorly understood requirements and by assumptions being discovered too late in the game and the other thing that’s paper example tends to solve is a long cycle time from you know when when we have an idea until it goes out because of kind of fixing and rework and long analysis and things like that so

Step number one is kind of visualize the problem. What’s the number one thing that’s slowing down the team? What’s the number one thing that’s causing rework and things like that? And if these things are actually a big problem for the team, then step number two, according to Chip and Dan Heath, is not to propose BDD spec by example, automated validation or whatever.

g (16:54.71)
but to actually get people involved in designing the solution, to suggest like, okay, what do you think is, you know, how do we improve this process? Let’s all kind of put stuff there and vote. And then you can propose your own stuff. And then step number three, they talk about how it’s very difficult to get commitment from people for something they don’t know. So it’s much easier to get the permission for a reversible experiment.

And then instead of saying, oh, you know, from Monday, we’re going to do spec workshops like this. So we’re going to, you know, we’re going to try to automate some tests in this way or that way. It’s kind of, okay. You know, we read this book by this crazy Serbian guy. Like, let’s try it for a couple of weeks. What’s the worst that can happen? You know? And so by doing that, you disarm a lot of these things and.

There’s actually a story in the Spec by Example book about a big data analytics company that my colleague David worked with. And we didn’t really, I did not read Chip and Dan Heath’s book when I wrote that. So I didn’t know about that specific process, but you can see in that kind of story, I described there pretty much all the aspects of that. David was trying to get them to figure out what’s slowing them down at the moment through retrospectives and things like that.

They were kind of trying to figure out different solutions that could help with that because he was then proposing his own kind of ideas. Everybody voted on the stuff and then they selected a few of these kind of ideas to try out these experiments. And when I interviewed them for the book, they were absolutely convinced that they invented the whole process themselves. They were really surprised that anybody else in the world is doing that.

because it felt like it grew inside this company organically and they had their own twists on the thing. It wasn’t exactly the same as, you know, in everywhere else, but that’s so brilliant about this idea. You kind of iterate over it and figure out what’s your number one problem, figure out how to solve it. And maybe some of these ideas fit, maybe some of these ideas don’t. And I think…

g (19:04.314)
When you read the original Scrum materials and things like that, pretty much Scrum was supposed to be about something like that. It was supposed to be about pause every couple of weeks, figure out what your number one bottleneck is, and then figure out how to solve it. Everything else that emerged, user stories, you know, running poker, retrospectives, spec by example, BDD, all of these other things,

They’re all solutions for specific problems that people are finding along the way. And in some cases, these solutions can be translated from one theme to another. In some cases, they can’t. And the original scrum material was like this theme. And now there’s books called Essential Scrum that are kind of hundreds of pages, which is ridiculous because we’re just kind of copying solutions from other places where it’s not necessarily that they fit in a specific environment.

Jim (20:03.542)
Yeah.

Sander (20:03.845)
Now, from your experience, figuring out what the problem actually is, is a very daunting thing. I mean, if everyone has their opinion, and especially in the modern day and age, everyone has a very strong opinion about any single detail. And how do you make sure that you objectively define what the problem actually is?

g (20:10.708)
Mm.

g (20:23.766)
Well, I mean, you can track, you know, where people are wasting time. You can figure out what causes delays in what aspect, but, you know, if you want to go like full McKinsey, then there’s, you know, time and motion studies and things like that. But generally, my experience, people in a team kind of have a pretty good idea what their number one problem is. And if you let them expose these things and vote for them,

you’ll figure out for a specific team what’s kind of causing the biggest issue at that very moment without a lot of bureaucracy. But yeah, you could do value stream mapping. You could do kind of figuring out where things are in the queue and tracking how long a specific Gira ticket spends in what state and figuring out maybe what people are spending time on or wasting time on during the day.

I remember one case I used to work as a consultant for a big hedge fund. And when we started looking at where developers are wasting the most amount of time, it was waiting for virtual machines to start up in the morning.

There’s nothing to do with anything else because, you the company kind of implemented this whole disaster recovery policy where everybody had to use virtual machines so that if a computer dies, you know, the work is not interrupted. And everybody comes in at the same time in the morning, they all turn on the computers, they try to log in and the virtual machine system just takes like 40 minutes to allocate the virtual machine, which is ridiculous.

If you multiply that with the number of programmers and the salaries that they were getting, like economics of data, you can buy a whole data center for that money per year. And adopting TDD at that point or adopting Kanban or adopting Spec by Example or user stories.

g (22:26.87)
I would not solve the number one bottleneck. What solved the number one bottleneck is taking that data to kind of the business stakeholders and saying, this is insane. Look how much money you’re paying just for people to wait for virtual machines to start up. And then we got a permission.

for programmers to use physical machines, not virtual machines, because all the work is anyway in version control systems. So if a programmer machine dies, it’s not that big of a deal. But I think kind of, yeah, just figuring out what people feel that they’re wasting time on usually produces good results.

Jim (23:05.422)
Yeah, I was trying to help a client with a problem recently and you know, I was making it visual. I was using facts and screenshots and you know, pulling up screens and saying, this is what I’m seeing. Do we agree that there’s a problem here? And the answer I got mostly was, yeah, yeah, of course, of course. Now, what do you recommend? I’m like, okay, so it’s great that one person

agreed that they see the problem, but the solution or suggestions would have impacted hundreds and hundreds of people and cost, you know, six to maybe even seven figures in the long run. And I said, I don’t feel comfortable making a suggestion yet until more people agree that there’s a problem. Because to your earlier point, people don’t resist change, they resist being changed. So I think that the way this technique helps is,

I see myself and you two may agree as we’re catalyst for change. We’re not the change. We’re creating the change or maybe facilitating is even a better word, a desire to change. How would you, or what’s been your experience when people don’t intrinsically or internally step towards change? So like to Chip and Dan He’s point,

Don’t try and change them because as a consultant, I try and not mandate changes or even really, uh, suggest specific changes. But if you’re hired to be a consultant, to come in and help the group or team or whatever the, the organism is do something different. And how do you create that in internal drive to want to step towards change?

g (25:01.974)
No, no, that’s not really a question for me. As I said, I’ve not been working as a consultant in this space for a long time now. I started building my own products. So when I used to work as a consultant, this was still new and fresh and people were enthusiastic about that. So I would have been hired by people who already kind of feel that they want to kind of change. And a lot of my work wasn’t done on…

generic kind of agile transformations and things like that because there were lots of people doing that already. My work was around much more kind of specific techniques that people have kind of already identified that they want to use or at least they want to try. So yeah, that’s not really, yeah, that’s not really working. Unfortunately, unfortunately, yeah, I think the, you know, the, the, the, the,

Jim (25:47.31)
That sounds awesome.

I want that!

g (25:57.27)
The situation with people adopting these things 15 years ago or 20 years ago was completely different from people adopting it now.

Jim (26:07.054)
Yeah. So that’s a good segue. Tell us what you’ve been up to. Um, because I’m intrigued by, um, the fact that you, I, I see you as a great author and practitioner and for the audience, the Gojko’s books are extremely dense and with what I call pragmatic ideas, like one chapter in the right hands or in the right, when there is a need there is packed full of

actionable, simple things that you can begin using tomorrow. So what have you been doing over the last five years? I’d love to just kind of understand what you’re building and how COVID affected, you know, yeah.

g (26:48.394)
Yes, so my colleague, my colleague Dave DeFlorini and I built a mind mapping tool a while ago and that really took off and it’s reasonably popular now and we’re working on maintaining that and I wrote a tool to help people create narrated videos easily from PowerPoints and from Markdown and kind of documentation videos, promo videos and things like that.

And that’s actually kind of taken off like, like mad last couple of years. Last year I had something like eight and a half million active users and I’m the only person working on it. I’m the only sales, pre -sales developer tester, product owner, ops and everything.

Jim (27:37.6)
Wow.

g (27:39.99)
And yeah, that’s kind of been an interesting thing. I still occasionally kind of do some workshops with people mostly around impact mapping and things like that. And I’m writing a new book now called Lizard Optimization that’s going to come out in…

a few months time. It’s based on the experiences with growing Naraketan and Mindmap where a lot of the work that really kind of unlocked growth came out of identifying edge cases and outliers in user behavior and kind of figuring out how to transform these things into ideas to make better products. So it’s kind of…

Sander (28:22.117)
There is this statement in the professional scrum material or a true or false statement that students need to figure out whether you can be a scrum team with two people. And I think I need to revise my answer because you just demonstrated you can be a single man army just by yourself and do an entire product.

g (28:37.91)
I think what’s happened over the last 10, 15 years is the bar to create new products has kind of lowered significantly. I had a company in 2008, 2009 where we were making a product and there were five or six developers. We had a tester, we had a product owner, we had a…

kind of an even an infrastructure person and then all the other kind of supporting staff around that and you know there’s so many kind of better tools now for operations for kind of doing the heavy lifting around things that are not really core to the business that

you can have, you know, a relatively successful product done by two people or one person. And then, you know, there’s interesting dynamics that happen there. And I think especially now with all this kind of generative AI and co -pilots and things like that, the bar is going to be kind of even lower and a single person will be able to do a lot more. But then, you know, this does require quite a lot of

cross -role knowledge and cross -role work. I think I’ve been blessed by touching lots of different parts of the software process. So I know how to do development and testing and I’m, you know, know how to do product management. I’m still struggling with enterprise sales and things like that. That’s not really my key skill, but it’s an ongoing learning process. And I think, yeah, we will.

It’s going to be really interesting what’s going to happen over the next 10 years or so once all these code generation tools mature a bit more.

Jim (30:36.526)
Yeah, I saw a headline the other day that said, and I’m paraphrasing, but it basically said all of the no code tools are going to be in products are going to be built, are going to be moving towards low code. So what I inferred from that is no code is a starting point for, you know, non coders like me, maybe to get.

a proof of concept going, but then as soon as you want to customize it or add significant complexity, you probably need someone like you. Do you see that as being the case or do you see those tools just getting smarter and remaining kind of what is called no code today?

g (31:23.126)
I don’t know, this whole no code promise again is something that I remember when I started working, people were doing case tools and 4G languages and everybody was talking about how case tools will replace developers because you can get…

a business person to just describe what they want in a case tool and, and it’s magically going to happen. And that didn’t materialize. And then there were all these kind of business process management tools and things like that later and app generators. And that never really took off again, because as you said, it’s, it’s, you get the prototype working. And then after that, uh, you know, there’s a, there’s a problem there, but the way I look at these things is, um,

You know, there’s been a huge progression from people doing physical wires to doing like bits and bytes and then doing assembly and then doing compiled languages and things like that. And I actually used to be a decent assembly developer. I was able to kind of optimize code better than the C++ compiler before.

Wotcom 8 .5 came out and then that defeated me the first time around. And I think, you know, I remember doing my own memory allocation libraries and things like that. But then I started using Java and I kind of forgot how to manage memory. And I think…

There’s a progression of these things where we’re getting better tools to be more effective. And on the other hand, I think what’s been happening, especially with Jupiter and things like that in the industries that we’re democratizing what it means to be a developer. We have people who are not necessarily, who wouldn’t be called software developers 20 years ago, who are now able to develop software because of these.

g (33:25.558)
tools, whether they’re low code or no code or something like that. And you have these data scientists, you have business users that are able to apply their knowledge to create automation. And I think that’s where, you know…

A parallel I like to use for that is spreadsheets or Excel or VisiCalc and things like that. VisiCalc came out in 1979 and created a complete revolution because it put kind of all these calculation tools and statistical tools in the hands of regular people.

And now we have Excel and Google Sheets and things like that as kind of the most popular iteration of that. But it democratized all this kind of work and gave people powerful tools to do things. And of course, then you have people abusing it and misusing it and getting overconfident like there was a case.

during the COVID pandemic where the British government actually managed the list of COVID cases in Excel and then they lost 20 ,000 people because somebody who should have really built a database wanted to use Excel. They were comfortable with that. And I think what I’m trying to say is all these tools that are emerging, whether you call them low code, low code, whatever, they’re gonna help people create automation. Now you can…

Greg Brockman from OpenAI demonstrated this thing where you can use a wireframe, can draw wireframe and create a web app. I read yesterday that Google has this prototype where it can generate the platform video game from a description and things like that. So these things are going to be really great for prototyping, for first cut attempts, and maybe even for getting some simple automation in place.

g (35:26.166)
And then you can figure out where you want to optimize it and where you want to do different things and maybe kind of get people to tighten it up or create something stronger. So I think, you know, going back to spec by example and things like that, I think what, you know, the power that we’re kind of hopefully going towards is people being able to…

Jim (35:36.716)
Yeah.

g (35:51.414)
take the human knowledge and express it in some way and then get that translated into software without so many layers of interpretation.

Jim (36:03.598)
And that is what I have picked up on in the last number of years. Tools like FigJam and Zeppelin and some of these other visualization tools have made it easier than ever for, and Mural and Miro and other such tools, but they’ve made it easier for business people or leaders to take an idea that’s in their brain about what they want.

and sit down with someone like you and say, okay, now I see we’re talking about the same things. Have we considered this? And they’ve really not replaced the doing of the work, but they’ve created an on -ramp or increased the shared understanding of what it is maybe somebody is after. And one of the other things you mentioned that I…

I was working with a group this week and this idea of two primary types of developers being out there and I know that there is far more than two, but there’s a lot of people I run into that want to do one thing. They want to be a specialist and they want to kind of treat their proverbial desk as like an inbox outbox. Like, give me what you want me to do, let me do it and it’s going to go to the outbox. And then there’s other people who sounds like yourself, you know, you’re doing

pre -sales, you’re doing operations, you’re doing this, that probably you enjoy doing that. And I don’t think you would do it if you didn’t enjoy it in some way, but you’ve probably likely had to decide what you don’t do, what you outsource and all that. So do you see a shift or is this, is the industry not changed much in the last 20 years from, you know, maybe the subject matter experts versus that more entrepreneurial

Jack and Jill of all trades type mentality.

g (38:01.962)
Yeah, that’s I don’t know. I don’t have a good overview of the industry, but I think generally what I would expect to happen and to be happening slowly is that as we’re getting better tools, you can do a lot more with a smaller group of people. And that means that you no longer need, you know.

a thousand people to do something. Of course, there’s a big question whether you needed a thousand people in the first place to do that. But it’s going to be less, you know, more and more difficult to justify having so many people sitting and doing kind of simplistic stuff. I mean, the same way how…

Jim (38:32.686)
Right.

g (38:49.398)
When we got better tools around automated testing, it all of a sudden became really difficult to justify having people there sitting and manually clicking and going through scripts. And then some portion of those people, they started focusing more on things where you really need the human brain and they started doing more exploratory testing, they started becoming experts in…

that kind of stuff and the automation went the other way. But some portion of those people just wasn’t needed anymore. And I think the way these things kind of seem to work is once you have organizations no longer needing that many people, they kind of tend to go and work for smaller organizations that tend to start their own work. I think, you know, like if you look at what’s been happening in Sweden,

Um, everybody used to work for Ericsson and then Ericsson wasn’t doing that well. And then people left and started Klarna, started Spotify, started King, started, you know, all these things. And then out of these people, you know, you have, um, people starting Izettle or starting Mojang and, and, and doing all these other things. And then kind of there’s, there’s lots and lots of kind of new products there and Stockholm is now a massive IT hub.

where kind of people have, I think, been able to create products with smaller and smaller groups of people. And I think that’s probably what’s going to be happening in the future, or at least that’s what I would like to see. In terms of, you know, whether you have specialists that just like doing one thing or generalists, I think that’s more a kind of personality thing. And I think in the future, we’re probably going to be seeing…

both groups still, you will still have kind of highly effective specialists doing a specialist task, but there will be a lot more kind of general purpose work as well. You know, for me personally, I was like fascinated with software as a kid because to me that was the closest thing to magic. You can kind of say some magic words or type some magic words somewhere and you know, poof, something appears and it’s amazing. And I’ve always…

Jim (41:05.42)
Hehehe

g (41:12.126)
enjoyed building products, I’ve not just enjoyed programming. And that’s why I probably gravitated towards kind of this side of the work. And I’ve tried to learn how to do product management, how to do testing, how to do all sorts of other things. But yeah, there’s nothing wrong in being extremely good at one specific type of work and then…

Jim (41:16.076)
Mm -hmm.

g (41:39.826)
working on that is just I think the marketplace for those kind of things is going to be shrinking and shrinking and shrinking.

Sander (41:49.461)
What I’m curious about in that sense, because you’re talking about AI, et cetera, that made me think about your closing keynote for the agile tour of Vienna in Austria past, what is it, September? We were both speaking there now. I was there, which by the way, even the start before your talk actually started was hilarious just for the audience. You used chat GPT or the your, I think it was the Irish co -host used chat GPT.

To generate your own introduction, like give me an introduction on who Gojko Adjic is just in the version of an Irish leprechaun. And then he would read it out loud in the, in his full Irish accent. It was genius. But your talk was about whether because of chat GPT, whether developers, analysts, et cetera, are still necessary. And you were talking about the, the political games within the organization. Do you think slash hope that.

g (42:17.078)
Yeah.

Sander (42:44.709)
chat GPT or any other generative AI tool is going to help eradicate or at least minimize the amount of political games are needed in an organization.

g (42:54.206)
I don’t think so. I think political games exist because people like playing political games. I think people like behaving like feudal lords and having their kind of budget. Technology is not going to solve that. That’s like a cultural dimension. And I don’t think technology solves culture. I think other things are necessary. But what I think is going to happen and where…

You know, you can see the patterns of technology. What technology is doing is technology is eliminating middlemen. Technology is eliminating middlemen in hotel bookings. You know, this 30 years ago, people used to go to an agency and then book a hotel or book a flight. Technology eliminated that. You have like technology eliminating middlemen in…

all sorts of areas. And I think one aspect of that might be that technology is going to start eliminating middlemen in organizations, which is kind of middle management really. Because in lots of organizations, middle management is kind of, I don’t know, a glorified email exchange. They kind of, you know, it’s kind of, you know, if you can replace somebody with Excel and a few email rules.

Jim (44:10.51)
Alright.

g (44:17.59)
It’s difficult to justify their job there, but a lot of the times the middle management is also where the organizational change happens. They’re the ones that are pushing through organizational change, which is now, you know, there’s an interesting dynamic there. What happens when you eliminate the middle management? Is anybody kind of able then to push through an organizational change anymore or not?

So that’s kind of the interesting dimension of that. And maybe, as I said, I think technology kind of in automation in general doesn’t make things better or worse. It makes them faster. So we can speed up the information exchange at the company. We can speed up the distribution of ideas from.

top to bottom and from bottom to top and sideways and matrix ways, whatever. But if these ideas are not good, then it doesn’t really matter if they’re slow or fast. And even worse, if you have a horrible idea and you speed up the kind of transition of that, then you just make mess faster. So lots of these kind of political things are.

I think cultural responses and technology is not going to solve that, but maybe it will lead to smaller organizations and then by implication, kind of smaller politics.

Sander (45:40.613)
Interesting. Well, thank you for that perspective. Gives me something to think about. And I was almost hoping that you would say, yeah, that’s going to happen. Or, you know, um, because we, because of the, uh, the, uh, digging into the problems of where to find the problems. And in many organizations, the middle management, not necessarily the people, but the behavior, uh, can tend to be a big problem either because of a hidden agenda or, you know, reluctance to change or whatever reason there is. And.

If we’re going to be using AI tools or whatever to, to speed up this process. And I would imagine these problems would become even more transparent, even faster. So we have to deal with it a lot faster as well.

g (46:17.878)
Yeah, possibly. But I said, you know, if you look at like, you know, this is a podcast, if you look at kind of adopting agility and things like usually it’s kind of the middle management is pushing these things through. It’s not the kind of the, you know, it’s very rare that a CEO of a bank really kind of wants to be in control of a process or how the process changes. These people kind of, you know, have different level of.

needs and engagements and things like that. Whether we end up with fully autonomous teams and things like that, that’s an interesting thing because then you still need coordination between these things. And somebody will need to do orchestration, coordination and a bunch of other things. And maybe, yeah, again, with better technology, maybe a fewer middle managers will be able to…

um, organized this whole thing. But then again, you know, um, uh, like Cyril Parkinson in, in 1950s, did this analysis of, uh, bureaucratic organizations. And he concluded that regardless of what you do, bureaucracy grows about 5 % a year. And, you know, he talked about how when you have administrators, kind of administrators tend to find more work for administrators and that grows and grows and grows.

And you can see that in lots of these kind of enterprise Scrum teams where Scrum masters tend to hire more Scrum masters and we create kind of additional levels of bureaucracy and they tend to be obsessed about the process itself rather than the purpose of the organization, which is really ironic considering the like…

original ideas of agile where you’re not supposed to kind of be fixated on the process. So I think it’s just a natural thing with larger organizations, they get slow and bureaucratic and bloated and then they die off smaller organizations take over. And that’s just the natural cycle of these things happening.

Jim (48:36.334)
What was the book or the author you just referenced?

g (48:40.158)
Cyril Parkinson is famous for Parkinson’s Law. He looked at bureaucracy and things like that. I think there’s a good article on the Economist website describing his conclusions. I don’t think he actually published a book. I think he published on the Economist magazine.

Jim (48:44.076)
Yeah.

Jim (49:02.222)
Yeah, that’s what I thought you had referenced. I just wanted to clarify because when I read that book again earlier this year, and I think one of the original published dates on it was like 1962 or something. And yeah, 50. Yeah. From the, I mean, and a lot of the stories came from like British Navy in the thirties and forties. So it kind of shows you none of these problems are new. And.

g (49:15.188)
He was 50s, yeah, yeah.

Jim (49:27.532)
One of the things I took away from that was there’s only a few solutions to this, which is the organization either continues this cycle of bureaucratic growth or it almost has a Phoenix type thing where it crashes, burns, and then re -emerges as something new. And I think that’s what we see in…

the workplace and these big companies spin off small companies, small startups, little dojos, you know, whatever words you want to use. And then those get bigger and they IPO and they’re a billion dollar valuation. And then they have all the same problems that, um, they were created to avoid in the first place. And it’s this very predictable cycle. It’s still very profitable, but it’s also kind of predictable that with size comes complexity and complexity comes problems. And yeah, it’s, um,

g (50:13.438)
Hmm.

Jim (50:20.878)
I highly encourage anybody that’s interested in like organizational dynamics to, it’s great if they know what Parkinson’s law is, but it’s a very quick read, the work behind it. And there’s a lot of nuggets in that. I want to come back because I see the time we’re getting right up to the time. I want to ask just maybe a quick question. You can give me a black and white answer or you can expand on it a little is, do you think people and teams spend,

Too much time, not enough time, or just the right amount of time on edge cases, negative use cases, et cetera. Because you referenced that a few times, and I’m interested in your opinion on that.

g (51:01.11)
If you look at how much shit software is out there, then it’s obvious that people are not spending enough time. You know, like yesterday I was traveling on kind of by British rail here and…

All the trains were delayed because they had some kind of signaling problems at a big junction. And, you know, they can put any excuses they want, but you and I know it’s because it was the 29th of February and all the software that developed last four years that wasn’t testing for that kind of exploded yesterday. And, you know, things like this happen. And at the same time, as you mentioned, you know, software is extremely profitable at the moment. And.

Jim (51:33.294)
Right.

g (51:46.518)
And then the question is, if we can get away with, if companies can get away with such rubbish software, should they actually create better software or not? I mean, is the software good enough? But there’s an economic component to that. Of course, there’s like a political component to that. You know, there’s a, in England at the moment is a…

Jim (52:00.15)
Right?

g (52:08.316)
Quite a contentious issue, there was some software developed by Fujitsu Siemens a while ago that was doing accounting for post offices. And they had some bugs in the accounting software that was reporting that the post office operators are basically stealing money from the post office. Lots of people went to prison, some people even committed suicide, they were ruined.

And then it turns out, you know, these were software banks. And now there’s a big political issue with kind of the government trying to figure out what to do and how to restore these people, you know, who went to prison and who lost their livelihoods and jobs and things like that. So, you know, bad software.

tends to have more and more systemic implications on because it’s everywhere now. And I think software is going to be more controlling of our societies and communities and governments. And there is a responsibility professionally for us to create good software and deal with all these edge cases. But as I said, I think while…

Nobody’s going to prison and everybody’s still very profitable churning out bad software. It’s very unlikely that the tide will turn.

Jim (53:31.468)
Right.

Sander (53:31.845)
Does that have to do with educating the user as well? Because apparently we’re just en masse accepting it.

g (53:39.158)
I think it has to do with educating the user, but I think it has to do with also, you know, like not really… It has to do with risk transfer. I think, you know, it’s one of the kind of… There’s a popular comedy duo in England called Mitchell and Webber. They have this phenomenal sketch where the bank calls somebody to tell them that all the money’s gone because of identity theft.

and they’re trying to argue whether identity theft is kind of the right way to call it because that person still has the same identity. It’s kind of the bank that’s given away the money and somebody, you know, defrauded the bank because of a problem and the bank is not accepting it. No, no, no, it’s not kind of, you know, it’s not the bank’s problem. It’s your problem. You have, you know, identity theft. And that’s ridiculous. I mean, what does identity theft even mean? So I think we as a…

Jim (54:19.404)
Interesting.

Jim (54:24.3)
Yeah.

g (54:34.08)
as a society have been kind of transferring the negative consequences of bad software to users. And that’s a political problem. I think only relatively recently have people started going to prison for actually programming stuff that was illegal. I think that the people that did the Volkswagen…

Jim (54:43.692)
Yeah.

g (54:57.104)
cheating in the US. One developer went to prison and I think the two developers that did Bernie Madoff’s kind of software went to prison. Those are all relatively recent developments. I don’t think that, you know, that the there were any consequences for anybody doing horrible software, even illegal software, you know, before. And usually people will just get away with that. And I think…

Jim (55:07.47)
Yeah.

g (55:24.694)
for something like that to change in a society, the governments would have to step in and start imposing, start shifting where the downsides of these things are. If you look at like, know, experience and all these kinds of people losing people’s private data in the US, all of the sudden, you know, everybody’s private data is available on the internet and people can go and get the mortgage in your name.

But it’s your fault, it’s not the experience fault that they kind of leak the data or allow the data to be stolen, which is insane, totally insane. So I think this is a political problem, it’s not a technological problem.

Jim (56:07.982)
Yeah. Well, you’re, you’re, this is an amazing take on it. Like, I mean, I, I kind of realized some of these bigger societal things, but I’m just so happy to hear you verbalize it. And this week I saw a headline about one of the big security companies was fine, lost a court case for basically their, their security product was actually selling customer data. So the very people you’re paying a service and for software to, to protect you is selling your data to the very people who perpetuate.

identity theft and all that. But you’re bringing up it’s a business problem. Like that if that fine is not significant enough to change the industry, they could chalk it up as a business expense and say, well, yeah, I mean, we’re still making a ton of money.

g (56:52.438)
Absolutely, that’s why all the EU fines to Facebook are pointless. But that’s a societal problem. I think as an industry, we are still relatively young. I mean, if you look at architecture or something like that, where doing such shoddy work would probably land you in prison and you would lose a license and things like that. That’s how society solves these problems. But with software, I think they still…

too much demand and too little supply. So we’re not able to, the societies are not able to create controls like that. And I think, you know, who knows 50 years from now, maybe the situation is going to be different, but I’m not particularly hopeful that something is going to change big in the next five to 10 years.

Sander (57:41.125)
Well, that’s kind of what makes me think what Dave Snowden said on this podcast as well, where he’s envisioning that IT should become a profession. And then you would get the same bar, like you would get in advocacy or with the medical doctors and surgeons. And you have to keep yourself accountable for the quality that you deliver basically. And if you deliberately endanger other people, for instance, with the diesel gate from Volkswagen or what Bernie made of in his stupid pyramid scheme we’re doing, yeah, then you’re a hundred percent criminally liable.

g (58:10.504)
Yeah, I think, you know, that’s, that’s, um, uh, those are changes that have started happening last couple of years. And I think that’s going to keep happening. But, you know, on one hand, you have these kind of clear cut criminal cases and that’s easy to pursue. But on the other hand, you have these kind of, oh, it’s a stupid bug thing, you know, like somebody, somebody hacked us and we’ve leaked all the kind of.

all the customer data or something like that. Or, you know, the software is doing accounting badly and kind of people are going to prison for that. And I don’t think, you know, these cases are kind of there’s a line between all these things. And I think.

What I would love to see is this profession thing. I would love to see, you know, the equivalent of chartered accountants and things like that, but I don’t think that can happen when things are shifting so quickly and stuff, you know, there’s still so much need for development. I think maybe, you know, we were talking about tools bringing productivity and things that maybe these tools really bring so much productivity in the next 20 years.

There’s not going to be a need for so many developers and so much kind of work developing software, then you can actually create something like a child’s profession.

Jim (59:35.182)
Yeah, I mean, Zuckerberg said, I think last week or the week before that they’re seeing the benefits of being a leaner organization. So I think two things are going to probably affect this. One is I think a lot of large companies are realizing that they don’t have to be doing as much. Like there’s value in being leaner and getting out the red pen and the scissors to our roadmaps and plans and saying,

trying to find that 20 % of the things that we should be doing and somehow letting go of the 80%. But when it affects real humans, because those companies are terrible at doing that and then start to do it, it’s a problem. And that’s why you see mass layoffs and all these things in the headlines. But I was in IT during Y2K. And you referencing February 29th is interesting, because what I realized years after Y2K is,

There’s always these periods of extreme innovation and then that leads to new problems. So like Y2K led to a bunch of problems and it led to a bunch of new solutions and consulting and all this other stuff. And then the dot com era led to a massive influx in growth, but then it also led to a massive influx in identity theft and, and.

commerce issues and money moving around and all these different things. And then there’s a shift, right? So it’ll be interesting to see what the post -COVID world and the AI, the new generative AI, LLM world will indicate. And like, if we’re in the middle of the bubble, like you normally don’t know if you’re in the bubble until after it bursts. So I have no idea and I’m not some expert if we’re in it, if we’re looking at it, if it’s behind us or what, but it will be interesting to see what.

the next 3 to 5 years brings, I think.

g (01:01:29.11)
Yeah, yeah, and you know, I think you’ve mentioned, you know, you create something and then, you know, it creates completely new things. And, you know, we, who would have imagined like, you know, such a proliferation of mobile apps and everything going digital and things like that in, you know, 1995 or six or seven, you know, when the dot -com bubble was…

starting and there’s all these things that are now changing the context. There’s these two UX laws, like joke laws, I really like. Larry Tesler had this law of the conservation of complexity. And his law was that you can’t really reduce complexity, you can only shift it around.

So, you know, you can make the front end more complicated and the back end simpler, or you can make the product more complicated and simplify the user workflow, or you can create a simpler product and keep the user workflow more complicated. But kind of you’re saying that product development and UX people talking about reducing complexity is a lie. Complexity just kind of shifts around.

And then Bruce Tonazzini, who worked for Microsoft, created like a paradox to that. He said, you don’t like, yes, you don’t reduce complexity, but what’s actually happening is you give people a tool and they become more ambitious because they now have more power. They can complete more work in one hour. So they start doing more complicated things. So complexity actually increases. And I think that’s one of the reasons why, you know, this

Jim (01:03:09.44)
Mm -hmm.

g (01:03:15.668)
Perennial thing where software developers complain that users don’t know what they want. Of course, part of it is lack of understanding and analysis communication, but there’s also a big part where when you give business users a tool, all of a sudden they have more time, but they still have eight hours a day to fill in with work. So they start doing more complicated work and then they have new requirements that need to be put into the tool that you’ve built because they want to…

or they can do more complex workflows now and they have more power. And then when you automate those workflows, the cycle continues. They can do more complex stuff and they have more power. So I think what you’ve described is kind of that happening, but on a societal scale where we have, we didn’t have internet before, but now we have internet, we can do more powerful things. And then we didn’t have…

internet or mobile phones everywhere, but then once we had that, we can do more powerful things. And all these things are kind of changing all the time with the cloud, with AI. And I think it’s going to be interesting to see what are the new use cases, what are kind of the new things we do and where complexity grows from there.

Jim (01:04:34.446)
Yeah, absolutely. Thank you so much. Like, we could talk for hours. I just want to thank you again for your time and Sundar, you want to wrap us up?

Sander (01:04:43.557)
I’ve got one last question that has been stuck in my head since the beginning of this conversation. When your bank in the UK said, you cannot open a bank account because you’ve been to prison, what went through your head?

g (01:04:57.43)
No, I knew it was some kind of shit software. So, you know, I started arguing with them. I had a flight ticket that showed that I came in two days ago and said, you know, I wasn’t in this country, you know, more than two days ago. You know, how would you even know if I was recently released from prison somewhere else? And then, you know, the lady was, I mean, these people know that their software is shit. So, you know, she called somebody who came 10 minutes later, pressed some kind of weird key combination to proceed to the next screen.

and that worked out. But it’s, you know, really, and then, you know, that person explained why the software was saying that. But yeah, I think.

Jim (01:05:39.054)
Sounds like Sandra Bullock in the net trying to like hold down the mouse button and click on the weird symbol.

g (01:05:44.886)
Yeah, I think, you know, horrible software affects people’s lives. And, you know, as a software professional, somehow I feel that, you know, we should be taking more accountability and responsibility for that as an industry. But as you mentioned, it is a commercial thing. So if you can get away with a small fine when something like that happens or even, you know, completely shifted to the user, there’s no incentive for people to build better software.

Sander (01:06:12.933)
Exactly. As long as the benefits still outweigh the consequences, then this is going to be perpetuated forever. Gojko, thank you so much for being here. Really appreciate it. And again, I second what Jim said. I think we can go on for hours talking like this, but we also realize it’s Friday afternoon. So we’re going to let you go. Thank you so much for being here. Likewise.

g (01:06:30.582)
He’s not talking to you.

Jim (01:06:32.27)
Thank you very much.

g (01:06:34.004)
Bye bye.