In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Ivar Jacobson, originaror of Use Cases and pioneer of component based development about the craziness of methods and frameworks, and what we can do instead.
Key Takeaways
- The method prison that results from the commercialisation of methods and frameworks is crazy, and causes harm to the software engineering profession
- All the branded methods and frameworks have much more in common than people think, however it is in the interests of the authors and “gurus” to exaggerate the differences
- Rather than a branded method, we need a library of practices from which teams and individuals can select the practices they need for the context they are working in
- Methods or frameworks are not only successful because they are good methods, they are successful because of fantastic marketing
Subscribe on:
Transcript
Introduction [00:21]
Shane Hastie: Good day folks. This is Shane Hastie for The InfoQ Engineering Culture podcast. I have the privilege today of sitting down again with Ivar Jacobson. Ivar, thanks so much for taking the time to talk to us. It's been a while, how you doing?
Ivar Jacobson: Very, very well. I have survived COVID and am vaccinated. I'm sitting out on an island in the Stockholm archipelago and basically working from here.
Shane Hastie: That sounds like an idyllic place to be in, what I gather is, a wonderful Northern hemisphere summer. So, you and I know each other well, we were just reminiscing. It's been 20 years about since we met, but I imagine there are some of our audience who probably know your work, but might not recognize you. Can we get the quick two minute, who is Ivar, and why should we be talking to you?
Ivar Jacobson: I am Swedish simple. And in Sweden, we have a motto, a law, which is not a formal law, which says basically, "don't think you are something special." So that law is deeply rooted in my backbone and everywhere, but I am very passionate about making things better, to improve things. And I have been criticized in my previous life, when I worked at Ericsson for as soon as I had succeeded to make a change, I wanted to change my change. Meaning make it better, and better, and better, instead of stopping and we have that. I can say that 20 years ago or so I was a rockstar to say, have an analogy. I travelled around the world, I was speaking to big audiences, people call me a guru. And I felt very uncomfortable with that because I didn't feel that I had that kind of competence.
I don't think there are people that can have competence about everything. In for instance, software development, such a big area. So I decided at that time, I'm not going to get another method. Instead, I wanted to do something. So we go rid of an organization, a way of working that was more accepting of many different ways of working. And that was no one single branded method that would cover everything. And that is basically what I have spent 15 years on and what my company has been working with. We have been doing great, but not very famous.
Shane Hastie: Prior to that of course, you were one of the founders of the RUP. You are known for bringing the idea of Use Cases to the world and way back in the sixties, component-based development, but moving forward, so the Essence. Just a very quick reminder, and we'll include in the show notes, the link to our previous conversations about Essence, but just a quick overview. What is this Essence thing?
The Craziness of Methods and Frameworks [03:22]
Ivar Jacobson: On one hand it responds to getting rid of a lot of crazy things we have in our world. I use the word crazy because I've got to the level of frustration where I feel any other word doesn't really work very well. I could even use.... There is a little devil in me, that would like to scream when I see how crazy we are when we work with methods and frameworks. But my Swedish nature and my civilization tells me, you don't use these words and they have not used these words until now. Crazy is not as much of a screaming, but it's a strong word. So basically, on one hand, the Essence address the crazy things. On the other hand, it's trying to find a common ground for all of the things we are doing. All the methods we have heard out there and frameworks, they have much more in common than people think. Various very differences, but the differences are exaggerated.
And instead of having no common ground, meaning that when you talk about the method you only have one thing in common, that is the alphabet. The reality is that you're close to that level. We don't even have terms like software development commonly agreed upon. That's a simple thing we could agree on. And so having a common ground would make it much easier to take ideas from different methods. We don't believe one single method has it all. We believe that there is, ideas from all methods, basically, because if a method exists and is named and popular, there is something good in it. And if you can take and pick ideas from different methods and compose them to something that works as a method for your team. Then you can do what is most successful. I think we have too few methods today, because we have only the branded.
Have a Library of Practices and Select What Works in Your Context [05:23]
Ivar Jacobson: Whereas I think the branding of a method is not needed. We need, instead a library of practices from people can select the practices they need. Starting from something very simple, because some teams don't know much about software engineering. So we cannot have too advanced a method, but as they should grow, they should be able to add more and more ideas, more practices to that method. And basically every team should be able to have their own method. With some constructs because some practices need to be the same in an organization. For instance, architecture, just to give an example. Whereas if you work with Kanban or you use Scrum or use Scrum variant one or two are three, that can be something that the team can decide the exception. Do something, I mean, not a hundred percent. So that's the idea, find what is really the common ground, and that is non-controversial. And use that to describe your practices and your methods. Practices are first-class citizens in this world. Methods are just compositions of such practices.
Shane Hastie: One of the most read articles that we have in the culture space on InfoQ, is your 2017 piece about escaping method prison. It was also selected as one of the best articles that year. What's a method prison?
Escaping Method Prisons [06:54]
Ivar Jacobson: It is a term that I came up with, seeing that practices are basically locked in a particular method. Because as soon as the practice is a method, for instance, Scrum, if Scrum is used in a number of methods, for instance, in SAFe, it's a reading scout. And defeat, the language being used in that method, for instance, we use in SAFe, we use the term iteration instead of sprint, if I'm not misunderstood something. And that means that we're practicing SAFe, it's locked into SAFe and cannot easily be taken out and used somewhere else without rewriting. And reason is that every method author, or practice author use his own way of describing the practice. Whereas now, Essence is such a standard. Essence allow you to describe it so it can be used with other practices. So if everybody used Essence to discover methods. We would have a fabulous ecosystem of practices. You could just take because if you know a standard, you would know how to understand the practice. So now it's not like that.
Shane Hastie: So this does lead to your fairly recent article, Some of the Craziest Things in Working with Methods and Frameworks. And as you say, that fairly passionate term, craziest, what are some of the crazy things that are out there?
Crazy Things in Working with Methods and Frameworks [08:24]
Ivar Jacobson: Yes, and almost all of them are ideas I've been thinking about for 20 years. I mean, take method prison thing, practice, user story. And so on. These practices, user stories in Scrum are so generic, are not the big problem. But if you take a more exotic practice where test is maybe only available inside one of the big methods, then it cannot be taken out from that without rewriting and used in another method. That is the method prison problem. That is, it's just a big waste of energy. And we've early such writing of a practice, the new guru who has taken it into his own method, will do improvements and some of the improvements are not improvements, they are destroying it. I have heard several of the famous guys tell me that, his or her practice has been borrowed or stolen and completely misunderstood by some other guru.
Ivar Jacobson: So this creates animosity and instead of working together and improving, they fight one another really. I mean, I heard terrible wordings from one methodologist about another one, and so on. Personally I don't get involved in that kind of thing because of course we're humans, but we all have weaknesses. And unnecessary to deal with these small fights. Instead collaborate, collaborate and improve the work instead of improving only your own stuff. So that is method prison. When it comes to method war, I can't for my life understand why people swallow it. There are of course, some things basically a method war like this. A guru has created a new, fantastic method and with great marketing. I would say that successful methods are successful, not only because of their content. Methods or frameworks are not only successful because they are good methods, they are successful because of fantastic marketing and support. I would say 80% is other things than the actually fact method. Just to give you an idea. That is why we create wars because it's not just the normal competition.
Shane Hastie: In what way is it not normal competition? But surely that's just the market in action, isn't it?
Ivar Jacobson: Yes, to a big deal, it is. Still, we have normal marketing and support are important for it. So that is similar to any product, but the difference is more like, this is intellectual property, it appeals to the intellect. It is about written things. It's about, you create basically a sect around your method. It seems it's not scientifically based in easily measurable methods.
It's a lot of preaching and it reminds on religious sects. And you know, of religions wars they are also not based on factual comparisons. So that's why people have used the term, this is a methods war and not the normal competition. You see, in some cases, some situations, similar situations, in more normal products, for instance, Apple and Microsoft operating system at least 20 years ago when that was a big deal. And if you today compare Tesla, with non electric cars, now we have it. So picking up, so it will be more fair. But you get fan clubs around it or a sect fan club, or sect. That is the difference, and that's why we call it more method wars than method normal competition. And this term has been going around for 20 years or 50 years. I don't know, many years. It's amazing. I cannot use strong words enough to express myself, but the fact that we still do these kinds of things and accept it is unbelievable to me.
Shane Hastie: And to use your term, the “gurus” would say, but we need you to follow my terminology, my language, because then there's a common language within the organization. And oh, by the way, that doesn't give us the method prison, how do we break out of this?
Breaking out of Method Prison through Building an Ecosystem of Practices [12:58]
Ivar Jacobson: We have maybe 10 branded, quite well-known frameworks, methods. And like Jeff Sutherland has done, he has re described both Scrum and Scrum at Scale, with our help actually, we did it on behalf of him, but it's his work, the owner of it. Both Scrum and Scrum at Scale are Essentialized, and similarly Disciplined Agile has done it for some of their practices, but they have so many practices. So it's very hard to do it at once. We need to be an ecosystem before they can really jump onto it completely. And then we have the Spotify model where one of the founders of the Spotify model has adopted Essence. So what we get is that we get the ecosystem of practices. These practices can then be composed. And of course we still have homonyms and synonyms, but that can be expressed when you select the practices. You can say that what, for instance is a backlog item in Scrum, is a user story in user story practice. That way you can merge practices so you get consistent wording.
In the long-term of course, when you have this kind of a library or ecosystem, we will find ways to reduce the number of homonyms and synonyms. And so it will be synchronized, over the library. But there will still be differences, but they have to be solved when you compose them into method. And the Essence has that kind of mechanism to do that.
Shane Hastie: So take a practice, distil it into its Essence, put it into the library and then think about, okay, what are the bits that I need in my context, and draw from that library to build your own method? What stops that becoming a method prison?
Ivar Jacobson: Yes, that's a very good question by the way. There is a difference, we can imagine that where we get an alternate, a different Essence, so to speak a competing Essence so that would be in two groups. If you have a competing Essence, then there'll be two groups, but at least we would use the number of competing methods because they will be described using one or the other of these two. Or they use both, it depends. So I think the difference is that a standard like Essence, this has gone through very rigorous examination by hundreds of people before it became a standard. We have taken away anything that could be controversial because then, it's not a standard. Okay. It has to be something that everybody can say, yes, this is a standard and we have not heard anybody express anything since six years that there is something that shouldn't be in the standard.
So we have rather been conservative when that standard was created. So given that if people start to adopt Essence to describe their practice, in particular, people creating new methods, because they don't have a history of having something old. But then we would get a much longer time before we have to throw out what we have, to go to something new. I don't believe anything we create today will live forever, of course. But I would say that the standard, like Essence, if I compare with other standards in my methodology space, like UML, they live many, long time, long time, whereas an individual method may only live five, 10 years. There are some exceptions, roughly probably 15, 20 years and SAFe is in a very good way. We don't know if there is an end to it. I don't see it myself.
Shane Hastie: But if I build that method, I want to be the guru don't I?
Experts not Gurus [17:06]
Ivar Jacobson: No. I think, yes, it may be some people want it, but we, others think that is a marketing salesperson. We need experts. And that's a big difference. You can be an expert on Scrum. You can be an expert on any practice, or group of practice. But you cannot be an expert on everything related to software engineer or software developer. Then you become a priest. And as I said, I was one.
Shane Hastie: In the article you talk about the Achilles heel of method adoptions. What is this fatal flaw?
Ivar Jacobson: We actually didn't know, we would get when we created Essence. Originally Essence was more like a common ground, but we added to Essence, we felt we want to make it more dynamic. So we identified a way to describe dynamics in method. For instance, we start arguing right now, if you look at what the current situation, imagine you are some kind of manager, for a hundred people, and they have X teams, let's say 10 teams. Just to take, problems was not to big essentially. You can go up even higher. If you want to understand what the team is in regard to your question, I've asked many people. How would you find out where a particular team is? Yeah. I would ask them a few questions, but they hit the systematics in that asking. Have you done the requirements? Waterfall asking, that's one approach and there are other approaches. With Essence, we have identified seven dimensions along which you need to progress your work.
Ways to Communicate Progress Towards Goals[18:55]
Ivar Jacobson: One is typical requirements or the intent. Another is about the system itself. Helpful about the speed, but then there's stakeholders, you need to have stakeholders. You need to know that this product you're building really solve a problem, that is ambitious. And so on per seven such dimensions, that Essence identifies each such dimension, have a state. And for every state, there is a checklist dependent on how far you have come. This checklist has nothing to do with what method you use. You can use any method. So as a manager or as someone who's responsible for a hundred people, you can go in to the team and ask them, how far are you when it comes to this critical dimension? By the way we call these dimensions alpha, because alpha is the first letter in the alphabet, it's the most important. We talk about alpha humans and so on. So, this is the most critical things to measure.
So we can actually come up with, in what state a project is. To a level that is much more than a simple question and it's not difficult. We do these things easily with a team, in one hour and get a fantastic reaction. So we can measure our team. Now, one of the problems, when we talk about development, there are two cycles we have to go through. First people have to learn a practice, learn a method, learning cycle. And then you have to apply what you have learned, to do it. The gap, we are quite good on the learning cycle. Companies have training, we write books, we write blogs, we have websites, they have videos and all kinds of stuff for training. They certify people, make money. So that is something interesting.
But now we move over to the delivery cycle. We have to do something. That's where the problem come because people scratch their head. What am I supposed to do? What did the methods say? How many times have I heard, but what did the method say? So, they need support to really implement the method. Traditional that has been done with coaches or Scrum masters and so on, but there not so many good Scrum masters in the world. The world needs many, many more. And there are not so many good coaches, agile coaches.
So to fill that bridge, that gap, the beauty of Essence is that if you have described practices using Essence, you can generate to do lists. Dependent on what state you're in. And these to do list's can then be transformed, broken down because you have it to do, and there are bigger tasks in the to do list. It come directly from the practice. You break them down into smaller tasks, that you feed into Jira, Gitlab or whatever you have. So for the first time we cure, I call this the Achilles heel, this gap and we have cured that gap. Of course, you need tools to be efficient, but the idea is built in to Essence free for everyone to harvest.
Shane Hastie: Thank you so much. Some intriguing thoughts in here. If people want to explore these topics and continue the conversation, where do they go?
Ivar Jacobson: They can go to CMaT, is an organization that has been working with a standard and so on. Or there are many people that help implementing Essence around the world. We do that. We help clients, big clients. We have case studies showing the fantastic results that people get. So it's my company. Ivar Jacobson International. Tata Consulting Services has gone a long way to adopt it. I cannot quote exactly now, but my feeling is that basically every new project starts, has to be based on Essence, but there are some quotes you can find about this from Tata. We had just a couple of weeks ago a meet-up, with three companies, including DFINITY. DFINITY is a very small, young company, with a good venture capital and they are building an internet. We use the internet to be the computer. So you can use the whole internet as your computer, with their software. And they are using Essence to describe, I think it's in some practices. I'm not sure exactly what they do, but the meet-up talked about it. So people want to see the meet up they can.
Shane Hastie: Ivar, thank you very much for taking the time to talk to us today.
Ivar Jacobson: Thank you. I enjoyed it as usual.