Ola Ellnestam, along with co-author Daniel Brolund, wrote the book The Mikado Method, which describes an incremental approach to code refactoring, as well as project management.  In this interview Ola discusses the application of the technique, common pitfalls and objections to it, and provides insight into how the technique can be used to help communicate technical debt and dependencies with non-technical stakeholders.

Resources
Book: The Mikado Method by Ola ellnestam and Daniel Brolund
Blog post: test && commit || revert by Kent Beck
Video: The Mikado Method: Increase Productivity, Workflow Management, and Sex Appeal! by Jonathan Hall
The Mikado Tool

Guest
Ola Ellnestam
Twitter: @ellnestam
LinkedIn: ellnestam
Email: ola@agical.se

Transcript

Presenter: Ladies and gentlemen, the Tiny DevOps guy.

[music]

Interviewer: Hello everybody. Welcome to another episode of Tiny DevOps, where we talk about dev and ops, and all things related, for small companies and small teams. I'm really excited today to have Ola Ellnestam, who is the author of a book that I've really enjoyed. The book has been out for several years. This isn't the most timely interview, perhaps, but it's still a good book. I'm really excited to have Ola on today. Ola, welcome.

Ola Ellnestam: Thanks very much. Thanks for having me. It's an honor. I think maybe it's very timely, I don't know, picking up where everybody's maybe forgotten about the method, I don't know.

Interviewer: Maybe so. The book is called The Mikado Method. We'll talk about that here in just a second, but before we do that, Ola, why don't you tell me a little bit about yourself? What do you do professionally that maybe led up to writing this book almost a decade ago?

Ola: I'm a software developer with passion for working together with others. I've been trying or attempting to coach people on several layers of an organization, technical coach in a small team, coaching several teams, and also coaching sea level roles. Over and over again, I come back to what I really enjoy the most, which is programming. I think it's the craft and creating something from an idea, and then giving it back to the person who had the idea, and see the reaction in their eyes when a problem is solved automatically for them.

Interviewer: Let's talk about this book. The book is called The Mikado Method. Do you want to introduce it, maybe what the method is in a couple of sentences? Then we'll dive in a little bit.

Ola: It's a structured way of reorganizing your code, basically. It's a strong emphasis on experiments and visualization. You start out with, you want to achieve something and maybe that's not possible in your first try when you code and it's like, "Okay, I need to do something beforehand, something that's in my way", you can also describe it as a to do list on steroids.

Interviewer: I like that. I read the book, probably 2016 or 2017. I think it was published in 2014 if I'm not mistaken.

Ola: I think so too.

Interviewer: I have used aspects of the method in a lot of my daily work since then. There's a visualization aspect of drawing a Mikado, I can do color chart, I think?

Ola: Yes, graph or [crosstalk], diagram.

Interviewer: I don't usually do that. I do that when I'm teaching the method to other people, but when I'm using it myself, I usually just keep it visual. It just serves as a reminder to keep my iteration short and small, and keep in mind my next steps, so I don't forget what I'm doing. Do you want to maybe walk us through briefly? Not in so much detail that nobody has to buy the book, but just enough detail that somebody wants to buy the book. What does the Mikado method tell us to do, how do we accomplish this?

Ola: First of all, you need something that you want to accomplish, we call that a goal. Usually, when I program, I'm trying to achieve it in the fastest, easiest, simplest possible way. But very often, something gets in the way. You need to move a method, you need to move a class, you need to move a library, you need to upgrade a third-party library, or something like that. Then you're in trouble. Then it's very easy for you to lose track of what you're doing.

What I found is that I need to remind myself what am I doing, and how am I supposed to get there is another problem. I immediately write down the goal on a piece of paper or a whiteboard. Then I try to achieve the goal in the simplest possible way. Something hinders me, I add a bubble or a node to the graph, and I draw an arrow there. Then I revert the code or see what's in my way.

Then after that, I try to achieve that goal and the oldest subgoal, or a sub prerequisite, we call it. After a while you're usually-- most often I do this in my head as you described. After a while, or sometimes it's hard to keep track of what I was doing so I need to look at a piece of paper, otherwise, I'm lost. Essentially, it's a map over what you desire most in the world when it comes to your code. The Mikado Method is a structured way of exploring that map.

Interviewer: I like it. That's a good description. How did you come up with the name, what does The Mikado Method mean?

Ola: The Mikado is a game, the European version of the pick-up sticks game. I think it was under that brand. We were at a conference, me and Daniel, and we were talking about a way how we beheaded a software beast. After the talk, [unintelligible 00:05:56] came up to us. He's a French guy, very agile in XP world. He came up to us and said, "Well, I see there's a method here. This is a structured way. Also, you should name it, because methods have a name. It reminds me of the pick-up sticks game, which is branded as Mikado in Europe, at least the early versions".

We thought about it. It's a good analogy, because the Mikado, the Emperor stick is always at the bottom, and you want to reach that stick and get the most points out of it, so to speak. That's the metaphor, the analogy.

Interviewer: Nice. I imagine you've heard of this if you follow the literature, whatever, but I think Kent Beck mentioned a method he calls test and commit or revert, which has some similarities to the Mikado Method. What do you think about that, and the similarities there?

Ola: You touched at it in the beginning here. I really enjoy it. It's how I evolve to-- I have a small Mikado graph in my head nowadays. I do that. I try something, if it works, I commit it, and make sure it works beforehand, run the tests, or whatever I want to do. Then I commit it, and then I push it to the central repository using Git usually.

Then I do another experiment, try that out. This is the smallest cycle of the Mikado Method, you could say. It's very similar. It's a style of programming that I enjoy the most, and I feel very secure doing it. Very small Mikado iterations in my head at first when I saw them, I think, can't express it in a tweet or so. I was like, "Yes, that's it".

Interviewer: Good. Are you a TDD practitioner?

Ola: Yes, I am. From time to time, I'm very strict about the TDD. Sometimes I do test after, sometimes I do a big integration test, but I need super-fast feedback. I feel very insecure without the fast feedback. I get bored, I get lost. I need something to rely on. I need something to rest upon, and that's usually tests.

Interviewer: How do you feel about somebody trying to do the Mikado Method without doing TDD, in other words, is it a prerequisite, do they go together or can you do one without the other?

Ola: Yes, you can do the one without the other. It's not a prerequisite. It's fun, though, to see people getting the idea of small experiments. That's what gives me the most pleasure when people's like, they've been working so long, like four or five hours, trying to push something into the repository, and then they realize, "Well, we don't know what we're doing." I feel that way very often too, but the revert, it's so liberating. It's like cleaning out your garage. I can't imagine pushing that to the repository. I'm very glad we reverted this.

Interviewer: You just touched on a feeling I have had many times. I don't have a specific example, but I can definitely remember times when I've been working on something that led to something, that led to something, that led to something. I have these six different generations of change in my editor and they're all alive, and I don't know which one broke the thing.

[laughter]

Ola: I had that yesterday, but I knew I had committed, and I reverted and still the test failed. I was so frustrated. It was getting way past six o'clock yesterday evening, and I want to go home. Then I was like, "This worked five minutes ago. What's the--?" Did another revert. I was like, "No, no, you're in the reverted state already." Then I refresh the clips and was like, "Okay, it was the clips this time." Because I could have chased that ghost for, I don't know, well over one hour if I hadn't had that commit.

Interviewer: I would like to hear from you if you have some examples of a time, maybe on a personal project, or maybe with a team you've been coaching where the Mikado Method made a difference. Do you have a story you could tell us about that?

Ola: I have two stories. I wish Daniel was here to tell the best one, but I can try it. It's not a wow story, really, but it just shows how effective the Mikado Method can be. Daniel and a colleague, he was working at an internet gaming company, a poker company, or something. I don't know what they were doing too. I think they were trying to replace configuration with the code. It was a huge restructuring, and they threw up the goal and then explored the Mikado graph, created the map. Then they rehearsed every step on the way.

They had the map. Before they did the most critical change for restructuring, they had rehearsed it for well over a week, and then when they finally did it, they were so certain that they had done the correct thing. They were able to pull it off in under a day. Probably as a restructuring that would have taken them-- I don't know, maybe the same time to do, but the aftermath was nothing compared to what you usually experience when you do a huge restructuring well over 10,000 lines of codes affected.

That's a real-- I enjoy it every time when Daniel tells it, and he tells it a lot better. I can feel the mechanic steps that they're doing. It's just smooth. I know it helped them, immensely. He also, I know, made a very good friend during that restructuring period.

Interviewer: How big was the team that was doing this refactoring project?

Ola: I think there was just Daniel and another guy. The team, though, was between seven and 10, but they set out to do this as a task force to do this restructuring.

Interviewer: Do you find that the Mikado Method works better when you're working alone, or when you're working on a team, or maybe both are just as good?

Ola: The steps that you want to take goes a lot faster if you work as a team. The visualization of what you're trying to achieve helps immensely because if you're taking a step in the wrong direction, or the correct direction when you look at a look at the graph, and then, "Okay, am I going to decide to do this class, move this method this way or that way?" You look at the graph it's like, "Okay, we're trying to achieve this. Okay, it's obvious what we're trying to do".

I usually say if you want to travel fast, you travel alone, if you want to travel over a long period of time, you travel together. I think you can go faster working with the Mikado Method alone, but I don't think you're-- It's not as sustainable.

Interviewer: I remember in the book, you talk about using the Mikado Method, the chart. You could almost turn each node into its own user story or its own [unintelligible 00:14:28] node to really parallelize the work as well, right? Assuming there are no unmet dependencies, of course, on the graph, but then it's completely obvious looking at the graph if that's the case or not.

Ola: Yes. I think, if you want to parallelize work, that's how you should do it. You're trying to achieve a bigger goal, and then you're achieving sub-goals or prerequisites. What's interesting though when you visualize stuff, people that are not very used to programming, they walk by the Mikado graph and usually sparks their attention. It's like, "What's this? What's this huge thing doing on the wall?"

"This is where we are now, and you can maybe have a little avatar there." It's like, "Okay, that's me. Okay, what you're doing?" "I'm doing this. We're preparing for that." "Oh, that's why it's taking so long?" "Yes, that's why." "But if you're willing to negotiate on the functionality, we can cut all this." "Oh, let's do that. Let's do that".

Interviewer: That's amazing. I never thought of Mikado in that regard. That you could use it as a negotiation tool with stakeholders, for example. That's really nice.

Ola: Yes, that's one of my finest hours. I saved a lot of money that way. Maybe even earned a lot of money negotiating with a product owner. I think it was seven, eight years ago, and it was super easy to make a calculation of that.

We were trying to go live with a special type of save account so we could work for a bank at the time. We could lower the interest on one account but open another account. The sooner we could open the new account type, we could lower the interest on one account due to regulations that extra account.

I said, initially, "Well, maybe we can go live in six months." Then we had a conversation, and it's like, "Okay, can you guarantee this? Can you guarantee that?" I was like, "No, I can't but look at this", and I drew up the graph, and said, "Okay, this is what the code looks like today. This is what we need to do. If we skip out on this functionality, I think we can go live in three weeks".

He was like, "Three weeks? Are you kidding me?" He pulled out his HP calculator. He's like "Ola, do you know this is three millions, three millions. We can save three millions by doing that." I was like, "Okay, well, it's an easy decision, then." It was.

Interviewer: Nice. That's great. I can see this being a useful tool during, say, Sprint Planning if you're doing Scrum, and you set your Sprint goal. That could be the center of your graph, and then you can from there workout. Maybe you already have some of the stories in your backlog, but certainly, you could put them on the graph and really decide how you're going to do your Sprint, or if your Sprint goal is even reasonable in the timeframe given.

I never thought of it as a project management tool in that sense but it sounds like it really is. Obviously, it is when you think about it.

Ola: Yes, me neither. I remember when I realized this. I was standing at a platform on the subway and was like, "Oh, my God, we can turn actual user requirements or whatever into--" Well, it explodes into sub-stories in a sense. I was like, "Okay, I just need to tell someone about this." When I told people, it was like, "Yes, well, yes, but it's a list." It's not a list. It's because it has some requirements. It's like, "Oh, yes, yes, you're right." Another colleague, a friend of mine, he used it to renovate his old house.

Interviewer: I wanted to ask you about that. How can you apply this to non-software projects? [crosstalk]

Ola: Well, I've seen it apply to-- No, I haven't seen it apply to. I've heard it described by Sandy Mamoli, a friend from New Zealand. She did the organizational restructuring this way. There's an interesting story she wrote on a blog post. I can send you the link later.

Interviewer: Yes, great.

Ola: She has very good insights on how to do it on an organizational level. My friend, he renovated his house. I've been planning parties this way. Also, big, I don't know, tasks that seems to go on and on forever, and then you lose track. Why am I here? Oh, yeah, it was that old piece of furniture that I wanted to do something with ,but then you lose track. [chuckles]

Interviewer: [chuckles] One of my first YouTube videos, it's a very embarrassing low-quality video, but one of my first YouTube videos is about the Mikado Method. It was based on a presentation I did at the place I was working at the time. My promise to get people to come to my presentation was that it could improve your sex appeal.

Ola: I remember that, I've seen it. I think it's one of the-- What do you call it? The bait and switch trick ever applied using the Mikado Methods. I constantly think about that.

Interviewer: I don't know if it actually worked for anybody to do that, but like you said, that was bait and switch. Definite clickbait. Have you ever experienced whether it's individuals or teams that have struggled with the Mikado Method? Why?

Ola: The first struggle is usually in the revert. People do not want to throw waste stuff. I've heard it several times and it usually comes in the form of, "Well maybe we could stash it and reapply it", and maybe you can but it's such a-- The thought process it's what's hard, I think. The first struggle is the revert, the trying to come over the fact that hard work was put into transforming the code or the text into one form or the other. I think the thought process behind it is the work and then you remember it.

The other thing is the-- What do you call it? In the beginning, I think you need to be very deliberate about the steps and you need to learn how to break down your tasks. From what I heard in the beginning here of this recording is that you do what I do, you do it in your head, but in the beginning, you need to be very deliberate about how to shank your work. That's the two big hurdles. People also tend to not want to-- If it's a tool, if the Mikado Graph it's in a tool, they want to keep it, they want to, in a data hoarding way, keep the graph.

But if it's on a whiteboard, it's a lot easier to just erase stuff and is more-- That's the three big ones that I've come across. Also, we can't do the Mikado Method because we don't have appropriate tests. We don't know how to restructure and I just go, "How do you restructure today?"

Interviewer: Do they? Do they have an answer to that one?

Ola: Well, they just, "Well, of course, you're right. We could use the Mikado Method".

Interviewer: Good. You talked about tools. Obviously, you could use a whiteboard or a piece of paper. Are there online tools, especially now that we're in this remote working, hybrid working stage of the universe? What tools do you recommend if you want to do this remotely?

Ola: If you work asynchronously, if you're not online at the same time, you could use Graphis and commit your Graphis files in the same repository as you use in the code, or you can use-- There's an online tool, it's not very evolved yet. We're trying to figure out how to make money out of it, but I don't think we can. But there's a tool on the Mikado Method info sites. I can also send you the link to that. You can also download the tool. It has no real-- The Mikado Graph has no real memory. We don't guarantee that, but if you run it locally, it uses your web browser's local storage.

Interviewer: I don't know how long you've been doing the Mikado Method, but you wrote about it almost 10 years ago. Presumably, you've been using it for longer than that.

Ola: I think it came into the-- Well, I think the birth of the method was at that presentation when Daniel and I were in Gothberg 2010, I think it was. No, it was before that. It was maybe 2009 when we did the presentation. Before that, we struggled, at least we had a practical problem when we came up with this solution, or how do you-- This method, maybe 2008. Before that, I don't know what I was doing, but it was way bigger, the restructuring that we initially thought.

Maybe I've worked this way more or less since 2008-9. It has modified a bit since, I'm not as formal with the drawing unless I want to share it with someone or I know this is going to take a long, long time. In fact, I've come to think of it, on the backside of a whiteboard at work now there's a huge graph that I haven't looked at for a while, but it's there in my mind. I know that I can cross it off-- I can erase some notes there now, but it's been running for two years.

Interviewer: What have you learned in the process, and especially since the book has come out? What new revelations have you had about this?

Ola: One of the big things is how early decisions-- This has more to do about code, and then I'll hop into Mikado Method-specific stuff, but code lives a lot longer than I initially expect it to. Maybe this code will just live for, I don't know, three months, but it doesn't, it's like three years and then it's five years. But when it comes to the Mikado Method, I've got confirmed that how much I love visualizing stuff and point at stuff when I talk about it.

If it's not visual, if I can't visualize it to someone, either drawing up a picture in their mind or drawing up a picture in front of their face, I have a hard time talking about things. It has to be concrete in some form. I think the Mikado Method helps me a lot there. It helps me as a person focus as well, lose track. It helps me relax. I also learned that talking about new ways of working takes a lot of energy for-- I can describe the Mikado Method in a few minutes, but actually getting through and getting someone to get the full benefits of something, you need to practice it, and really in a deliberate way.

Interviewer: That's true with so many things, isn't it? Learning the rules to checkers is easy, but mastering the game can take a lifetime.

Ola: I don't want to force some stuff onto people. I don't want to coerce people into using something they don't see value in. I think that's a-- Neither me nor Daniel wants to coerce people into things. You could argue that marketing is trying to convince people that, "This has some use", but maybe that's why the Mikado Method hasn't had a huge spread, or at least I tell myself that. Maybe it's not.

Interviewer: How has the reception been by the way? Before we started recording, you were talking a little bit about that.

Ola: Well, it's two polar opposites really, or maybe three. It's one that's like myself and other people are like, "This is really useful." And some people it's like, "Well, to the useful", but it said, "This is very natural. How can this even be a method? That's my style of working. I've always done this. I knew this long before the first demo tape"m and there's the other aspect of, "Why bother? I have my style. This is not useful." It's so ingrained in my work, it's a part of my style. It's very useful to me. Maybe it's not even the Mikado Method anymore. Maybe I've eaten up the Mikado Method and become--

Interviewer: Somebody else.

Ola: It's a part of my [unintelligible 00:29:26] I don't know.

Interviewer: The method is deceptively simple. I've read a number of books that talk about something simple. I'll even pick on Kent Beck here, his book Test-driven development by example is an example in my mind of a method that needs about three pages worth of explanation. At the surface, you might think the same about the Mikado Method, but honestly, I enjoyed the whole book. I didn't feel like-- One chapter in, I was like, "Now I'm done". Of course, that's me. I don't know if anybody. I can't speak for anyone else. I felt like it was a benefit to read the entire book. It's not a long book anyway, but it was a nice thing to read.

Ola: I'm happy to hear that. I was going through the book yesterday and trying to see if there's something that I am not very fond over. I'm very glad that you say that. Some of the critique that we've had is that this is a long book. It's too long. It's actually just you can explain it in just a pagewise. Is this even a book? Well, come to think of it. Me and Daniel had a long conversation. We wanted to destructure the book so you can stop reading at any minute and have gotten something out of the book. That's how we wanted to structure the book. Having said that, there's a hidden gem there, but it's very rough, I think. It's about technical debt. It's in the appendix A, I think.

Maybe it's not. Maybe it's a framing problem. Maybe it's not about technical debt, but it's about where change comes from. I read that yesterday again, and I really enjoyed that part. That's usually how I talk about big structural change for changes with stakeholders. Now you're asking us to do this, which has this impact and change that comes from the inside of a technical kind. I know how to deal with this. I know how to try to avoid that, a steer away from that. The purpose of that chapter was really to put people's attention to where does all this stuff come from. That's in my way all the time.

Interviewer: That's good. That leads me to what might be my final question. If you were to make a second edition of the book, what would be different?

Ola: I think maybe more examples with dynamic lead-type languages. I don't know, that's some critique that we had, even though there's an appendix. I wanted to point on this, the non-technical aspects of the Mikado Method. How you can use it as a product owner or a project planner or something like that. Maybe it's not, but I think there's a follow-up book. At least in my head there is where, instead of talking just about software development, it's something that I call active stewardship, active software stewardship.

Where you go from a function factory where you develop functions to software system stewardship where you develop stuff. Where you maintain stuff and where you retire code and data. Which is been a huge insight for me that if when I retire code and functionality, the rest of the stuff becomes simpler. When we add stuff, it becomes more complex and said, "Okay, what's the opposite of that?" Well, it's retiring code and retiring data. Maybe there's something there about retiring stuff.

Interviewer: Sounds good. I'll read it.

[laughter]

Ola: Yes, we have one reader. That's fine. That's great. Maybe you should write it. I don't know.

Interviewer: Yes, maybe [laughs]. Well, it's been fun. Of course, we'll have a link to the book for anybody who hasn't read it and wants to get a copy. How can people get in touch with you or follow what you're doing and find out when this new book comes out?

[laughter]

Ola: Well, they could-- I'm at Twitter still. It's just my last name. It's @ellnestam. I'm there. Not a lot, but a couple of times a day so you can reach me through Twitter. You can also hook up with me on LinkedIn, it's Ellnestam. There's only one that person with that name in the world. You can also send an email to me ola@agical.se. Sometimes I'm busy, but if you reach out to me, I will certainly respond to you. I love talking about code and the Mikado Method and stuff like that technicals questions.

Interviewer: Is there anything else you'd like to add before we sign off for today?

Ola: No, thanks for having me. This has been a real pleasure and thanks for being very friendly. I feel a lot more energized talking about Mikado Method, and you should. Thank you. I thank you.

Interviewer: Well, thank you so much for coming on. Like I said early on, it's a book that I've enjoyed. It's a real pleasure, personal pleasure to talk to you about the book. I encourage everybody to read it. Thank you for listening or watching today. Until next time.