“If you don't deploy some kind of Agile delivery that's the right size for your organization, you're not going to thrive. Your organization will decline over time. If you don't succeed with DevOps, you will decline and some start-up's going to eat your lunch”
Mik Kersten, CEO and Founder of TaskTop, has an interesting story to tell. While most DevOps initiatives are built around the idea of toolchain automation and cultural transformation, Kersten wants you to think deeper than that. He wants you to be able to create a value stream, giving you the ability to determine the real business value of your DevOps initiatives. In this Innovator’s Journey to DevOps, we talk with Mik about his path to DevOps, his current projects and what he hopes to accomplish in the coming year.
Mark Miller: How did you get started in technology? Were you a geek as a kid?
Mik Kersten: It's bit of an interesting start, I suppose. When I was 9 years old, my parents decided to escape communism in Poland. We made it through Checkpoint Charlie. I didn't even realize we were leaving. I thought we were going on a brief vacation. In Belgium, we were staying with some people who were helping us out because you don't get to bring much out of the country in such situations. The people who were helping us out gave me, as a birthday gift, a Texas Sinclair 1000 computer which was this 2K computer that you hooked up to your television. It had a manual in Basic, and I didn’t even speak English.
I thought this was the coolest thing ever. I've never seen any such thing. My father was a professor in Warsaw, so I had seen in his office a System 360, which I thought was incredible. Now I had this thing that was on my own, and so I just started hacking with it. The manual was in English. It was a BASIC manual since BASIC was the programming language for it, so I translated it from English to Polish, and I learned BASIC. Through the process I learned English as well.
Mark Miller: You were 9 years old, what year was that?
Mik Kersten: That was '84.
Mark Miller: When you moved through learning English, teaching yourself, did the school system help at all? What was going on with that?
Mik Kersten: The school system was tricky because, when we escaped from Poland, we got stuck in Belgium for a while. We got accepted as immigrants into Canada. My father got a job as a professor six months after we got there. It was hard until he got one.
It was 1984, so the Mac had just come out. I wasn't understanding anything in school because it was all in English, and I didn't speak the language. My father ended up with the original Mac. That just completely blew my mind, so I think that that's when everything got cemented. My passion for what technology can do in terms of the creative side of building things, building software, and then connecting people. Those original Mac DOS programs were awesome. I got to meet some of the people from the original Macintosh team at one point, so it's been an interesting thread. That's really where it started.
In school, I think I learned a lot. I got my science background, but it wasn't really until I got to the university that I started taking this stuff more seriously. Back then it was just a bit of a passion.
Mark Miller: It was an exciting time. I remember getting that first Mac, too, in '84. It was interesting because IBM came out with the PC, and they had that going on. Then the Mac came out and just blew it out of the water when you first saw it. It was so exciting.
Mik Kersten: Yeah, it gave you that glimpse of what technology could do. It was amazing what it was, but also where it could go. I think that got so many of us excited, and that sparked the flame that's still driving a lot of our passions today. That's where it started for me.
Mark Miller: Then you moved quickly into the university in the mid-'90s it sounds like. Where was that?
Mik Kersten: At that point I was actually more interested in culture, so I started anthropology. I did an honors thesis on anthropology a couple years in at the University of British Columbia in Vancouver. Then I started doing evolutionary simulations because I thought it was just very slow to study evolution in real time. I started using a lot of software to do that, and then I just got really interested, through that process, in complex software and what it actually meant to do a large simulation and how difficult building complex software was. I just started taking all these computer science courses, and got sucked into computer science. I became very passionate about it, especially around complexity.
Mark Miller: That's fascinating. I don't think anybody I've talked to in the whole series started out college saying, "I'm gonna be a computer scientist." Nobody did. They found that the technology was as interesting as the subject they were learning. Then they would move into the technology. I think that's fascinating.
Mik Kersten: Yeah, I think that's the case for a lot of the interesting people I talk to and work with as well. Technology is a means. You need to learn it to do something that you really care about. I'm very interested in manufacturing complexity and human progress. I think there are a kind of people who see computer science and programming as a means, and I definitely fall into that camp myself.
Mark Miller: Did you get any lifelong relationships at the university?
Mik Kersten: I did. I'll tell you a really quick story. There was a professor of the software engineering course. My first real software engineering course after you do a couple programming courses. She just gave all these real-world examples, some of which blew my mind. Her name is Gail Murphy, and she was a computer science prof. She took us through all the latest and greatest ways of thinking about software, architecture, and all that stuff that was going on with objectory and UML and all these ways of making software more visual. To me it was especially interesting because I'm a very visual person.
She also told all these real stories and had us implement things around that. A story that stuck with me that I just told our whole team last week was the story of the Boeing Triple 7. Boeing, whenever they create a plane, they bet the whole company. If the Triple 7 had failed, and at that point it was unclear whether it was going to succeed or fail, Boeing would have massive and potentially cataclysmic problems.
Gail, at that time, was telling all of us young undergrad students just how important software was becoming in these machines. In this case, it was going to be the first commercial airliner that was fly-by-wire. There are no physical linkages between the controls and the flaps and such.
There was all this complexity, and she told the story of the decision that Boeing made to put the engineering heads on the maiden flight of the Triple 7. Basically, how everyone had to get bought in to this transformation that Boeing had to go through to become a software company, and how dramatic that was.
They actually experienced some significant turbulence, and they had to correct some of the software mid-flight on that maiden flight. It just completely shifted my thinking into how critical software is and the way we build software and the way we manage software delivery. It blew my mind that you put all these people on the first flight of this aircraft that might crash and is all flown by software. This was a profound shift we were seeing. I think what's amazing is it was clear back then, and we're just seeing more and more of it now.
Gail Murphy has absolutely been a life-long collaborator. She was my PhD thesis supervisor. She's Tasktop’s chief scientist, and we're doing all sorts of cool stuff together every week still.
Mark Miller: She's been working on communication patterns in open source component supply chains for a while with Mark.
Mik Kersten: Yes, exactly. We've had this common thread, Gail and I, of not just looking at the architecture of software in terms of how to make hard scale software effective, but really the social aspects and the collaboration aspects. These emergent structures that span software architecture that really have to do with the way people and organizations work, the way organizations form and evolve, and the columns they fall into.
I think that's been one of the most important collaborations to me. It all started back then. Taking that different approach to software and software architecture in terms of how we really make it work in scale and how we take a different approach to it.
Mark Miller: A lot of the terminology you just used relates directly to DevOps. Do you remember the first time you heard about DevOps?
Mik Kersten: Yeah I do, and I think the interesting thing at that point was it was not anything new. I I'd been building on my projects in open source software that way for a while, so I thought, "Oh, wow, this is happening more now." The notion of not deploying multiple times a day when we were doing that, working on things like the , was just bizarre, but it was really interesting to see that this movement was coming from collaboration and breaking down these silos between the way commercial software was built.
With open source software you just had to do this. If you didn't iterate that quickly, you wouldn't have an open source project that was successful because no one would use it because people thrive on consuming features, consuming cool new stuff. It really helped me understand how far a distance there was from that idealized way of developing things to the reality that a lot of professional developers and release engineers were living day-to-day. I did get interested in it fairly early because of that. Less because it seemed new, but more because it identified a problem that I hadn't even, to that point, realized how big a problem that it was.
Mark Miller: It's interesting, again, the consistency in the people that I'm talking to. When DevOps first came on the radar, everybody goes, "Oh, yeah, yeah that's the way to do it. That's the way we've all been doing it. Now it has a name." It's been interesting to follow that trend.
When you've got your comp any now, does the work that you did with Gail influence how you're structuring your company?
Mik Kersten: Every week. Well, every week might be an exaggeration, but I think it absolutely influences how we think about the organizational structure of the development teams and the company as a whole. There's been work done by Gail and other researches on socio-technical congruency and those kinds of things, yet, we've also seen other things in industry take hold. Things like the notion of feature themes and so on. For me, the core thing around DevOps and around the right ways of doing Agile and Scrum and all of those things that we've seen happening, is that we need to think in terms of how we structure teams and architecture and so on.
I think that the core concepts of Lean need to be applied to end-to-end software delivery. In the end, it's around the notion of pull. I felt this in a way that'll continue to shape my career.
In open source you've got all this pull from people that you're interacting with daily. In my case, with the Eclipse Mylyn and AspectJ projects, it was thousands of people creating bug reports and feature requests. We were always dealing with this immense pull of things that people wanted from your open source that they were using more and more.
In open source it's interesting because you'll often have a small number of core committers and then ten, a hundred, or a thousand times the number of users just wanting more stuff. You can ask them to contribute and so on, so you can do very interesting things with that. There's this very strong pull, and that pull, in the end, is the value stream. It's taking resources behind your software project that can be the late nights that you're spending coding cool features and basically delivering them to the end users that you're trying to delight.
The core thing for us has been to orient the entire organization around that value stream. In the end that means that your teams must be aligned around value streams, which often, the way that we market products, means they're aligned around applications or, basically, products. Completely the opposite of so much of what we have seen in large scale software projects in industry which are aligned around projects and so on.
We've also learned a lot over the last decade with what effective team sizes are, and how to make teams effective in the fact that they autonomy and so on. We need to align around the value stream, where the software value stream is defined by collaboration. That's why DevOps is so important, because you're establishing the right lines of collaboration between the people managing at the point of offering the application and the people building it. It has to be a very tight feedback loop.
We have to shifting away from architecture centered thinking, where you somehow align your organization and teams structures around your layered architecture. I think that is completely wrong. That is Conway's Law, and that is the effect you saw when you opened up those first PCs that you mentioned.
Align your organization around the value streams to optimize for the value stream and give the people who are delivering all of that the autonomy they need. Make sure they've got the right collaborations across the value streams, because those will always be across your functional divisions. That's what's so key, and that's what Gail and I discovered in research. That's very much what we're applying at Tasktop and the view that we have for the industry going forward as well.
Mark Miller: How much were you influenced by your work at the Eclipse Foundation? I know you're still on the board there, I think, but you've had a long span with them. How has that influenced you?
Mik Kersten: The Eclipse Foundation influenced me tremendously because I'd worked a lot on open source at the Aspect project, which then fed into the lineage of the Spring Framework and the collaborations we had around that. That definitely shaped my thinking on a very effective way to build software. The Eclipse Foundation helped me understand that at scale because, all the sudden, we were sitting on 60 million lines of open source code on Eclipse, which formed the core IDE. That's the scale of an operating system like OS10 or Windows 10.
It shaped my sense in terms of how you scale this collaboration and this continuous delivery but also managing the feedback and the feedback loop at scale between end users and the development teams. Then blurring that feedback by having actual users contribute and so on. You see how you end up with this very interesting pyramid.
I think the main thing on the Mylyn project was we were able to establish such a closed loop and a scaled out closed loop that we were able to innovate very quickly. Every year hundreds of thousands of lines of code were produced that delivered more and more value very quickly when the project was at its peak and Eclipse was on the rise as a Java IDE. That still inspires me today is how you create that tight of feedback loop and that level of personal, team, and organizational productivity within today's large organizations.
Having seen it work and lived it for years, it has been a huge motivation for me because it's not easy, but I firmly believe you can reproduce that level of productivity within a large organization. I also believe that most large organizations are not even 1/10th of the way there in terms of the amount of business value delivered per IT staff.
Mark Miller: I would agree with you on that. You've been doing this for 20 years now.
Mik Kersten: I have? I guess I have.
Mark Miller: When you look back, what's the thing you're most proud of? Is it a project? Is it a concept that you help people understand? What are you most proud of that you've done?
Mik Kersten: Right now, and this could be some recency talking, the thing I'm most proud of is this notion of value stream thinking which has tied together a lot of the things I've been trying to get our teams to do, I've been trying to get our customers and our partners to think about.
Effective software's not about architecture first or Agile being the core thing or just getting your DevOps automation done. For me the really interesting thing is, when you get those things done, it's obvious you have to do that. If you don't deploy some kind of Agile delivery that's the right size for your organization, you're not going to thrive. Your organization will decline over time. If you don't succeed with DevOps, you will decline and some start-up's going to eat your lunch eventually or some 20 start-ups.
For me, the key thing right now, the thing I spend the most time thinking about and collaborating with people on, is once that's done, what's next and how do you make your organization more effective? How do you connect software closer to the business and so on? The whole notion of value streams thinking coming together as the way to shape the way you approach your architecture, your Agile transformation, your DevOps transformation is right now the thing that I'm most proud of.
The problem is it's not quite done. I'm still very much working on the core ideas and concepts. With Tasktop we've got a platform that supports that, but just the feeling of all of this coming together in terms of looking for a better approach, making developers more happy, more productive, and keeping them more in the flow of their work. Then extending that from developers to having different people involved. There're testers and support people and ops people and business analysts and people to design screens, so coming together with a conceptual framework around value stream integration and visibility and value stream thinking. That's the thing, at this point, I'm most proud of.
These ideas are coming together, and not just my ideas, but all these different people's I've been collaborating with. More recently Gene Kim and Nicole Forsgren. These things coming together both on the product side and how we think about improving software delivery once we've got Agile and DevOps deployed.
Mark Miller: That's a great segue into what your plans are because I'd like to know, when I talk to you a year from now, what do you hope to accomplish?
Mik Kersten: That's an interesting question. A year from now, the most important thing to me is that we've got a value stream framework that organizations can quickly apply. What I'm most interested in is how this works at scale, because I think we have so many companies right now, even the start-ups, growing up and then hitting these complexity limits. Another one of my close colleagues, Dave West, recently told me that around the hundred people mark is where you start seeing Agile break down, and it's exactly what we have seen happen.
That we have a framework for scaling DevOps and Agile to thousands of staff. I really think that is this new approach to a value stream framework where it's not that we replicate the ideas that work for manufacturing, because software's a slightly different beast than the nuts and bolts that make a car, but that we take that same inspiration. In fact, a lot of what we've done in terms of DevOps and Agile is the lean thinking in the theory of constraints and so on.
We have a framework for scaling DevOps and Agile deployments and identifying where CIOs should invest. Is it really the knee-jerk reaction everyone has right now of just hire more developers, or is that not the constraint? What happens if you actually have got continuous delivery deployed? Are you delivering more business value, or are all of your problems up stream now because everyone's waiting on wireframes or something of that sort?
A year from, I think what will be success for me is that there's a clear framework on how to do that. All of the conversations we are having right now will yield that, and organizations can just take it and implement it. The interesting thing is I wouldn't believe this could be true if I hadn't seen organizations do that. Those are some of my closest collaborations right now with people like Carmen DeArdo from Nationwide who are implementing this today.