BT

Mik Kersten on Current and Future ALM Trends
Recorded at:

| Interview with Mik Kersten Follow 0 Followers by Craig Smith Follow 6 Followers on Nov 07, 2015 |
28:42

Bio Mik Kersten is the CEO of Tasktop Technologies, creator and leader of the Eclipse Mylyn open source project, and inventor of the task-focused interface. His goal is to create a collaborative infrastructure to connect knowledge workers in the new world of software delivery. He has been recognized with awards such as the JavaOne Rock Star and the IBM developerWorks Java top 10 writers of the decade.

Sponsored Content

In its 14th year, the Agile Alliance global conference is the leading international, noncommercial conference on Agile methods in software development. At the heart of each Agile Conference is connecting and sharing. Attendees gather, many for consecutive years, to meet with peers and the foremost leaders in the Agile space. The relationships made, support received, and knowledge gained provide an enriching and long-lasting experience that fosters both individual success and the collective advancement of the industry.

   

1. [...] For those who do not know who you are or what your background is, could you give us a quick summary of the Mik Kersten story?

Craig's full question: My name is Craig Smith. I am an Agile editor at InfoQ and we are at the Agile 2015 Conference in Washington DC. It is my pleasure to be sitting here talking to Mik Kersten. For those who do not know who you are or what your background is, could you give us a quick summary of the Mik Kersten story?

The story? Yes, OK. I am the founder and CEO of Tasktop and I guess the story is that I have been involved in application development since graduating from college at the University of British Columbia and then I went and worked a lot on programming tools and technologies at Xerox PARC in the Bay area and realized that we were kind of hitting these diminishing returns and how much more productive, how much better, how much easier we can make the developers’ days just with better programming language and tool kits. Not to say that there is all this innovation that is needed, right? We are still making incremental evolution on languages, we have got more than incremental evolution on some of the ways that we manage infrastructure deployments – Docker is a really big deal, virtual machines a while ago and infrastructure as a service made a really big difference in how we deploy.

But that ultimately - first they get these 10x productivity gains that is about how we manage the lifecycle of these applications and that can be in very small pieces of it where now that the applications have gone so much bigger and more complex, the way that we can deploy them in an automated way. What has been happening to DevOps is key to automate, But Tasktop my own interest, first as research interest and then as Tasktop in our product line and in our vision are all about putting in place that automation, that collaboration, that layer of flow in the end-to-end software lifecycle so that developers can spend their days doing what they love doing, which is getting work done, rather than entering information into 18 different systems and filling out reports and then sitting in endless meetings. So yes, I guess the whole story of Tasktop is just that.

It started out with developer tools through Eclipse Mylyn and putting in place that automation, that flow, so that as soon as you commit a line of code, your JIRA message was populated automatically, it was linked into your build in Jenkins and then everything was deployed. You got a message right in your IDE. We have kind of taken that and expanded it to the whole software lifecycle through this new infrastructure layer that we have been building with the Tasktop platform. So that is kind of what I am up to.

   

2. Mylyn, I remember when that first came out, was a breakthrough, particularly from a developer perspective. [...]

Craig's full question: Mylyn, I remember when that first came out, was a breakthrough, particularly from a developer perspective. Do you think the success of that product was driven by Agile techniques and Agile processes because we were doing things like updating stories and tasks or would it have just naturally occurred anyway – it was just a tool that developers needed regardless?

Yes. I think that’s a really interesting question. I think it is a combination of things because I think Agile definitely helped. I see software delivery as this conversation between the different stakeholders, between you and the users and you need to have some kind of artifact to anchor that conversation to. It’s the same with Facebook, the conversation, the killer app is anchoring them to photos because people like to have conversations around photos.

What Agile did is it gave out the equivalent of photos, but as user stories. There was this thing that you could attach the conversation to and all of the software conversation flowed from that. It was actually, the interesting thing was that with the case of Mylyn it was this kind of convergence because Mylyn grew out of open source. All my background was open source development and I really wanted to make a much more effective way of collaborating in open source.

The interesting thing with open source is you have this very small number of people who are having a conversation with 10,000 people. We were getting, I think, 100 bug reports a week. Effectively a bug report is a user story saying “I want it to work like this”, whether it is a Bugzilla bug back then or a JIRA issue. And it was just a way to manage that conversation and link it up to the changes in the code and only see the relevant context and to be able to push that fix and deploy it. We basically came up with a process where if someone contributed to the conversation, they said “I want an icon to look like this”, they could submit a patch, which would now be a pull request and then it would go out into that nights build and then there would 100,000 people who would get that nightly build and then the next big release of Eclipse, there would be millions that would get it.

So, I think all of this stuff was driven by the fact that we now have these artifacts that connect us in software - us to our users, us to our management because user stories -- in open source it’s really about connecting to the user base. With Agile, it really is more about connecting to management as well because you are connected to the business side. But we’ve got something to anchor those things too and so that is really what drove Mylyn, because we had something to put all that context around and to link up and to make this rich IDE UI around. Then with Tasktop we just took that concept and said “OK. Let’s make that the way that we anchor together all of the different stakeholders because, as you hear in this conference, the conversation now has to have business analysts in it and has to have operations people in it and help desk people in it” But it’s all that same concept, I think that it was driven by Agile in the sense that Agile gave the business a way of talking to development because of user stories and sprints and these units of value that developers deliver as well. It has those two things coming together, I think.

   

3. [...] Tasktop seems to be driven from more of a developer perspective. It is thinking more about me than it is about the process or others around, but gives you still the output that is an ALM system. Was that the intent of Tasktop?

Craig's full question: An interesting thing about Tasktop as a product to me is a lot of ALM tools that I have been, let’s say, forced to use over the years, have been very much around the process and around perhaps what management and other teams want ,whereas, to me at least, Tasktop seems to be driven from more of a developer perspective. It is thinking more about me than it is about the process or others around, but gives you still the output that is an ALM system. Was that the intent of Tasktop?

Yes, the intent was really to, when you go into large-scale software, , not a start-up with 100 developers, but once you get into large-scale software you get, exactly what you said, these ALM systems forced on you and you get into this world where you are needing to update multiple systems and the amount – and we are doing some studies on this actually, Dave West and Murray Cantor have been collaborating on this – and the amount of non-value added work, so the work that we hate, like the filling out reports or time sheets or entering defects or entering knowledge, known issues into the service desk and so on, it just piles up, and up, and up and we hate the tools more and more and more.

The really liberating thing from these light-weight issue trackers, like the back then Bugzilla’s, but now the JIRA’s, the GitHub Issues and so on, is you just stay in the flow of your work: you are coding, you are doing code reviews and so on. So there is a structure to it, but you are staying in the flow of your work. So, really the intent was about lets achieve that feeling and it started out very developer centric and it still is in many ways because so much of the conversation and so many of the people in these organizations, the large organizations, are developers.

It is happening around developers and there is just not enough developers on the planet right now to build all the software that the planet needs or ultimately benefits from. So, yes, it is centered around or it started centered around developers, but now we are doing almost the same thing for someone who is in a service desk and the service desk people, they like Zendesk or ServiceNow and they do not want to be told to log into JIRA, Rally or VersionOne three times a day. So we have been able to take that same idea of keeping us in the tools and the light-weight processes where we are productive, while making sure that our activity is connected up to those other stakeholders who then get to stay in their tools. So if a tester creates a test case from a defect that you just started working on, you will actually see that link to that test because it might be interesting to you or you might actually care, and you should care about how many tickets – you just released this new feature that is represented by some epic or user story and it might be nice to know that no one can og in ever to your system because there is something weird about the UX of the log in experience.

That information, and that was the thing, in open source, in the place where you are very close to your community, all of that information is captured in your issue tracker, in one tool. And in large, in enterprise software it is not – it is off like two or three hops away, but it needs to flow back into development. So, we want to give that lightweight experience, but still get all that knowledge that is happening on the operational side, in the field, back into development as well, showing up on the backlog. Every ticket that’s a software issue, that should be on your backlog and you shouldn’t wait six weeks until you have some status update, shouting match thing meeting. That is, I think yes, you nailed it! It is about that and then reproducing that same experience for the other people.

   

4. [...] What are your thoughts on DevOps in the lifecycle?

Craig's full question: The buzz word for the last few years has been DevOps, and you referred to containers and Docker and a few of those things earlier. How does that now all fit into this whole application lifecycle. Whilst we were deploying before it was this very throw it over the wall mentality. What are your thoughts on DevOps in the lifecycle?

There is DevOps in the large where a lot of marketing you see from various vendors is that DevOps is the end-to-end ALM, what ALM was supposed to be, I think we more we commonly see, at least organizations, speak of DevOps as just a way, way faster way of pushing things over the wall, to the point where you’ve got highly reliable, completely automated process of delivering stuff into production, rolling it back when you need to. So, the same way that way back, when Unitask gave developers a parachute, we now have that for getting stuff running into production. I think that level of automation is absolutely critical. Anyone who does it, our engineers, anybody, who can’t imagine, the same way you can’t imagine how scary and weird it would be to write software without tons of automated tests and great coverage and being told where you don’t have coverage by someone or something else. You can’t imagine not, having an unreliable or manual process for shipping that software.

That is critical and that is DevOps and the thing that we are very much focused on is that as soon as you’ve got that, because it is a critical step, the feedback loop is what’s important because one thing – there might be some kind of Maslow hierarchy of automation and integration that you need in a lifecycle and DevOps is critical where is is at the bottom because you need to be considering that feedback from the operational side from in the end, what is a user or a customer. So, now we are thankfully getting to the point where organizations see the need for that, they have done some DevOps and now it is all about “OK. This release failed. We actually need to get that information back into development.” The released management features are being aligned with DevOps.

What is even more critical is that feedback on the application is getting into development and that is partly happening through the application performance monitoring tools, the New Relic’s of the world, and that partly has to happen through basically the support systems in management. Connecting up those tools so that if there is user experience issues, those are showing up on the backlog. I think in the end a lot of the DevOps activities just familiarize organizations around that automation with this aspiration that if you can ship 1,000 times a day, if needed, you are doing great! But if you are shipping 1,000 times a day, you don’t have the feedback loop, again, as with Agile, if your development teams are Agile, but your business, your requirements management is not, you are not delivering more business value, you are not delivering more value to the market.

So, I think we are getting to that same point of maturity, hopefully, with DevOps now, where people have stopped caring about, the automation is in place, it’s a solved problem, you pick your technologies for automating those deployments and then you start thinking again about the big picture – the feedback loop. I am hoping that is what is happening because that is certainly happening in our customer base where we work with the organizations doing the largest scale Agile transformations in world, or DevOps transformations in the world and sometimes those words that get used interchangeably. Or ALM, or Lean SDLC or whatever it is. But fundamentally, what you care about, is the end-to-end feedback loop, that you have got information flowing from operations and forming your decisions around what is interesting to build, maybe part of your portfolio has a mass amount of technical debt and it is never going to stand up to having all those mobile clients hit that API. And you get this feedback loop that is centered around development, where most of the people are.

   

5. From a tooling perspective, the other thing that we have been hearing over the last couple of years at these conferences is large scale. We have got frameworks like your Scaled Agile Framework, your Large Scale Scrum. How does all this fit into the world of ALM tools, particularly Tasktop?

The interesting this is, I was at the Agile Exec thing on Monday, which was actually a really great little sub-conference and one of the more interesting talks referred to the fact that a lot of these Agile transformations right now, the large scale ones, there has kind of been in vogue to talk about those here, for the last couple of conferences at least since Scaled Agile framework came around. They are not working. The ROI is just not there. The teams want it, the teams want the Agile tool, but the business benefits, the very large amounts of spend, very often in the millions for these large companies that we are investing in Agile, are not delivering those promised results because in the end, you need to have a value stream in the company that delivers more to your customers, to your end users, delights them more, by going Agile.

It clearly works, we all believe it, but it fails at large scales. So I think the need for that, for large organizations to get that same benefit, it’s resulted in one of the smartest people who understood how the business side represents things in software they call them still requirements and so Dean Leffingwell made the Scaled Agile Framework and it really took off. It hit the really sore spot. The challenge is that these companies can’t deploy the Scaled Agile Framework. There is no tool that does Scaled Agile framework. They want that simplicity, so you need multiple things. The conference focusses a lot on the culture, like how do you do Agile when you’ve got 20,000 developers – the culture stuff. But the bottom line is that developers want this. Agile is designed to be developer friendly, those tools, those Agile team tools, they are developer friendly.

You need the process pieces, because, in the end, Scrum worked because it struck this balance between being sufficiently development people centric, so it wasn’t like those tools that you hated, that we all hated, but it was enough of a process to work for the business. And then the bottom line is you need the tool infrastructure to do this and you can’t get that right now. So we focused entirely on creating this integration infrastructure layer so that you could plug in those tools and implement the Scaled Agile framework or some variant that you are doing: if you do Scott Ambler’s Disciplined Agile delivery or the Ken Schwaber stuff you alluded to, the Nexus.

But you can’t do that in one tool, you have to do it across tools and that has actually become a huge part of our business right now – is to allow organizations to do large scale Agile transformations while plugging into their old school requirements tools, or best-of-breed requirements tools like the Jama’s or Blueprint’s of the world or the iRises, if you are doing more visualizations, right to the operations side. So, there is this need for it, but it is interesting that the companies just try to do it. Their rate of success is not great right now, so we are working very hard on solving that.

   

6. What are some of the new and interesting things that are coming along in the ALM journey, particularly for Tasktop? Are there any new features or interesting experiments that you are doing?

Yes. I think that what we release is a sign for where the industry, especially the large organizations that we work closely with, are going through because we are an integration vendor. So the things that you see us integrating are a sign of where the market is at. So at last Agile conference we basically hit critical mass in all the Agile tools. We have got every Agile tool out there that has got significant market share supported as far as we know. So this year, what is bizarre and interesting is that our last-week’s release of Tasktop 4.3 we’ve got critical mass with the releases of support for Blueprint and iRise, we now have critical mass in all the popular requirements management tools. So, old DOORS, DOORS Next Generation, Req Pro (Dean Leffingwell’s original requirements management tool), legacy tools like Serena Dimensions Requirements Management which is still there because requirements management tools never go away.

The federal government uses a fair amount of, as you can imagine, a fair amount of, older requirements management tools, they are still trying to modernize in their software delivery practices. Key parts of the government are going Agile. So, we now have almost all the requirements management tools supported and the reason we had to do that is because of this interest in the Scaled Agile framework because everyone uses a different requirements management tool, it is very hard to get off it because it captures the whole business side of the application portfolio. So, we focused a lot on that and being able to synchronize those to the Agile tools. So, you have got hierarchies of requirements turning into epics and user stories and tasks and so on. So that is for the key focus. Then the other key thing that we have been getting asked for a lot - and again this is by the larger companies; Tasktop is now implemented as the integration infrastructure by 24 of the Fortune 100, so we are how these large companies, at least the ones succeeding at going large scale Agile or going Agile along with all of these other great vendor tools that they are selecting.

So, the other thing that you need in that is some way of knowing, of getting visibility across your lifecycle and right now the vendors have these great metrics and analytics things that they are creating, but they give you the perspective of that one tool whereas your end-to-end lifecycle is five, or six, or eight different tools and if you are doing Java or .net it is at least two different Agile tools because TFS or Visual Studio Online is the best tool to do Agile issue tracking for your .net projects, right, or Agile project tracking. So, Tasktop Data, we have a completely new and much simpler and completely visual user experience for basically being able to take all of that data that is flowing through your life cycle and then stream it to your data warehouse, to your existing data warehouse where you might have your business data, you might have your website hits and all of that, and then use your existing visualization tools like the the Tableau’s of the world, you can point Excel at it to see what is going on with your lifecycle. So you can actually find that the really amazing thing is that you can actually get your meantime to resolution, all those things that people talk about.

You can get your cycle time across tools by hooking up Tasktop Data and that’s really our goal: whatever your tool chain, whatever your best of best-of-breed tools choices that you are empowering your developers or your other stakeholders with, you are still able to report back to the business and to see how you are improving because this conference is about improvement and measure that, because if you can’t measure it, it is kind of hard to improve it. So, the other really big thing is Tasktop Data and that we always have, again, a sign of what is happening with the market, we are releasing integration between Agile tools and legacy tools that we didn’t yet have. So we have new support for ClearQuest so that you can connect - there is still plenty of Clear Quest out there, right – speaking back to tools you previously didn’t love if you used it. Connecting that to an Agile tool actually gives you a reasonable experience. CA Harvest we have support for with this release as well. So again our whole goal is to allow this modernization to happen with this backdrop of the legacy or the enterprise grade tools or the large scale requirements management tools that are there.

   

7. What about the future? What are you seeing, thinking of looking forward to of where ALM is going? Are there some interesting things that you are thinking about right now?

In terms of where ALM is going, yes, and I think a lot of it just has to do with thinking of the lifecycle end-to-end because I think we have, even with DevOps itself - it has been around fixing this particular piece already. This is great – we are fixing bottlenecks because in the end, software delivery, you have to think about as this end-to-end system of delivering value to our users, to the market and learning from that. The companies that will be the best at that will be the companies that they are the most successful. So, while all the software is getting so much more complex and you don’t have enough developers, you actually care about their productivity and happiness more than perhaps we did in the past, which is great. So we are fixing these key bottlenecks because DevOps and the automation of continuous delivery and continuous integration are key.

If you don’t have your build system, you don’t have your automated deployment with Puppet and Chef and some kind of reasonable runtime infrastructure to deploy it to, that’s a bottleneck. So, we are fixing individual bottlenecks and I think the future of ALM, of Agile, of DevOps, whatever the terms turn out to be, is about looking at that big picture, that collaboration-information flow across all those things because what is happening is I think that we have actually fixed a bunch of the bottlenecks. One of the bottlenecks used to be that teams were very unproductive because they had such a rigorous, crazy process and terrible tools. One of the other bottlenecks is that we couldn’t ship code quickly when now that things have gotten complex, or that things took too long to manually test. Those are going away. So if we now look and it’s interesting that you mention this, because if I look at the history of my history around programming languages and so on, you got to this point of diminishing returns where all the interest was around making the JVM run faster. Nobody – well, there is still some people at infrastructure companies that care about making JVM’s run faster, so I would not say that – but you can only make the JVM run 10%, maybe 20% faster over the next few years by doing some very clever tricks.

But no one is going to notice, other than the infrastructure vendors because they will get slightly better margins. We are going to get into some of those diminishing returns as we do these local optimizations and then, in the end, we just now need to start looking at that whole value stream, that whole flow. The funny thing is we don’t even have words to describe it properly. We have Agile for development teams, we have DevOps over here, we haven’t even started transforming some of that – it is still ITIL is for enterprises, as the common way of looking at support desks, rather than looking at it as a feedback loop into development. But I think the good thing is SAFe is a counter example. SAFe actually is or DAD or the others is a way of looking at the end-to-end process. So I think that is the future.

Now Dean Leffingwell’s put out that flag out there, you should look at the end-to-end thing and it becomes a question of how to support that. Our view on the future of it is that it is all about the tools are good. These Agile tools are very good. The developer tools are getting better. There will be requirements, like I don’t think we have matured enough in terms of code review, for example. The good ISVs – you are either using GitHub Flow, you are using Gerrit, you are using Crucible, you are using some kind of code review, that is not common enough yet. I bet you they will be coming up more at these conferences later. There is still a few corners that need to be fixed, more Git options, those sort of things. But in the end, it is time to start looking at that thing as an end-to-end process. And what is that called? Is it Lean delivery or whatever it is. So I think that’s kind of the future. and that will be defined by integration, which is why we are completely focused on that.

   

8. One other thing that has just occurred to me is there is now a rise of new languages in the community – we have got functional programming, we have got embedded languages – how does that affect the ALM? Does it still hold true?

Yes, that’s really interesting and I think we have seen more language innovation that has actually taken hold. Where you have got JVM-based innovations like the Scala’s of the world, you have got the embedded languages which are becoming more important, there is more Internet of Things and basic embedded device or connected device which is being programmed, but what I’ve really noticed from our customers’ experience from the last couple years is the way is that they have used our ALM, Agile, DevOps integration technologies is that we almost can’t tell what they are doing. So a few of our big customers they do a lot of simulation and they are programming in MathLab and that is the environment that I have no idea how to program in, except that I know they write a lot of simulation code and their source code is actually these models of physical devices and how they work, and if it’s a device that moves through the air, what its aerodynamic profile is.

Did they mess it up by adding some GPS antenna to it or something? So, the actual lifecycle management part of that is so similar and the way it is all going into Agile and they are running almost the same kind of continuous integration-continuous delivery stack because you can run all that with Jenkins, you source code is now these models. When you build fails, what Tasktop sees from that is if it is an IT system, a Selenium failure indicates there is a defect which should be a defect in the right issue tracker iof the right Agile tool. For this it is exactly the same. A model simulation fails, we get notified on the Tasktop spouse and we create the right defect for the right failure point in the model which is, again, is just a reference of source code.

So I think the really neat thing – I think this is really helpful in terms of ongoing innovations that we have abstracted that lifecycle management part from the language. So you can have an application that is very polyglot, made from multiple languages, you can be experimenting with newer languages, like the more functional oriented programming languages, but you have got one ALM, one lifecycle to lay over that. I think that is actually going to help with programming language innovation whereas before we were very stuck to all Java programming being done just in the Rational tools and Microsoft programming, .net programming being just done in TFS.

We now have this mixture and actually the runtime platforms are almost encouraging that. If you look at the way that Microsoft is wooing Java developers onto Azure, that is shaking it up even more which is really interesting. So I actually am a big fan of the ongoing innovation in languages as well as in deployment abstractions like the Docker’s of the world and the ability to script that in a way that’s like called the Puppet’s and Chef’s of the world.

I think this is really a point to continue, that we continue to abstract the way that we manage requirements and how an application should function from the actual languages and not have those overly vertical integrated because that is when we get the ability to do more experimentation in by adopting these new, better suited languages. We are not going to adopt platforms of service for an entire enterprise scale organization software portfolio, but you should try it for your new mobile project. So, yes! I think having those things isolated from each other and abstracted is happening, again another kind of integration layer – and I think it is very helpful to drive that kind of ongoing experimentation that we need on the language front.

   

9. So, if people want to know more about Tasktop and all the features that it brings, where do they go to find out more?

Just tasktop.com. You can check out what’s new in the new release and let us know what other integrations or crazy experimentation and points you need.

   

10. And if they want to find out more about you, Mik? Where can they find you on the interweb?

I think just somewhere on the interweb. I think Google is sufficient, I haven’t done it in a while, but it should be somewhere there. My email address is mik@tasktop.com so feel free to reach out.

Craig: Excellent. Thanks for taking the time today. It has been a pleasure to meet you.

All right. Cheers. Thank you.

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT