Interview with Mike Cohn

Mike Cohn: I graduated from college with a master´s degree in economics. At my first job I was doing financial and economics work. This was in the early and mid 1980s and every company I worked at needed more help with the software systems than they needed one more economist. I already had decent programming skills so I took on projects to do things like creating financial forecasting systems. I was having more fun programming than doing what I was initially hired to do. I eventually got a second master´s degree, this time in software development. I´ve had the fairly typical progression from programmer to manager and eventually to vice president of development in a handful of companies.

Mikael: What sparked your interest in agile processes, and when did it happen?

Mike: Back in 1994, I was hired by a company to rewrite an application.  The first thing my boss did was ask me how long that program would take to write.  I looked at the existing application and decided that with the enhancements needed in the new one it would take about a year.  I went back to the boss, told him that, and he said, "I can't give you a year, but I will give you five months." He wasn't being a complete jerk.  What he meant by that was that he was going to give me five months and also thirty days of notice. 

The 30 days notice came into it because we were selling this to large insurance companies.  My boss knew that it would take about thirty days from when the contract was first signed until we had data from the insurance company to load into the new system.  So, what he was telling me was that I had five months to do what ever I wanted. After that he would come back to me and tell me the 30-day clock was ticking. That scared me. 

I had never done a system like that. I was used to the type of development where we threw a hundred balls up in the air, caught them all on the same day, and released the product - the typical big-bang delivery.  The concept of keeping a system consistently thirty days from shippable was quite scary. 
So what I did was I went back and read everything I could find about different software development processes.  One of the things I went back and read was a book from 1990 called Wicked Problems, Righteous Solutions.  I had bought the book in 1990 but never read it.  It is one of the ugliest books ever produced - a great book, but very ugly.  In 1994, I had to read the book. I needed to read anything I could about different processes. So I dug the book out, read through it and it had a very short description of Scrum.  That got me started with agile. That project was one of the most successful I´ve ever been involved in and led to the company doing extremely well.  We started to buy other companies.  As we were buying other companies it gave me the opportunity to introduce Scrum to those organizations.

Mikael: Why do you think agile has taken off the way it has?

Mike: I think of agile as the second wave of the object revolution. Agile would not have taken off the way it has if objects hadn't come first. I think this is why so many of the early OO thought leaders were right there as the authors of the Agile Manifesto.

Mikael: What about agile do you see as most exiting today?

Mike: I'm excited about two things—first, the extent to which companies are adopting agile. It is no longer the small pilot or the process we use on trivial projects. Last year I helped Salesforce.com and they transitioned 250 people all at once to agile. No pilot to “try it out" first. They just plunged in. Second, I'm excited at seeing agile start to go beyond development organizations. We have a chance to impact how entire businesses are running themselves.

Mikael: What is the biggest challenge you face in implementing agile processes in companies?

Mike: One of the biggest challenges is that a transition to agile must include elements of both top-down and bottom-up change. An organization attempting to transition to agile without support from the top will encounter resistance as soon as the new process begins to affect how areas outside the originally adopting team like to work. Top-down support will be needed to remove the impediments and obstacles uncovered. Bottom up participation will be needed because it will be the individual team members who work through the issues of discovering how agile will work best within their organization.

Mikael: What do you see as the biggest gain for companies implementing agile development?

Mike: There are the obvious answers—faster teams, doing more with fewer people, greater likelihood of delivering products that users want, increased developer job satisfaction, and so on. But the biggest gain in my mind is that an agile approach helps the development and business sides of an organization learn to work together to pursue solutions that best fit their objectives. I don't understand why some project stakeholders think that the best way to achieve a desirable result is to tell the developers, “We need this much by that date with this many people. Make it so." That is just asking for trouble as it often leaves no choice to the developers but to cut quality. If we can align the business and the development sides through the rapid iterations of an agile process we can get rid of those problems. All parties can learn that the goal is to explore the solution space and find the best achievable solution.

Mikael: What do you see as the biggest threat to agile software devlopment processes today?

Mike: I worry that it becomes watered down. I see teams take their first steps toward agile, see some great improvements, and then they stop. But they're not there yet—they aren't even close to being agile yet. In most of these cases the teams have learned how to work iteratively but that's it. They don't change any of their engineering practices, they don't really get closer to their customers. It's as though they view agile as a destination rather than a journey and forget that agile is about constant improvement.

Mikael: How do you divide your time between teaching and consulting? Why this perticular division?

Mike: I try to split my time in thirds. One-third is training, one third is coaching teams in a more hands-on manner, and one-third is writing.

Mikael: Why did you write your book about User Stories?

Mike: After a few years of doing Scrum I was noticing that teams that invested effort into their product backlogs seemed to do better than teams that didn't. Then in 1999 or 2000 I came across user stories as described as part of XP. We experimented with those on a few projects and were seeing good, consistent results from the approach. I started writing the User Stories Applied because I needed to explain user stories, how to write them, why, and so on to product owners at my various clients. I wanted to take the advice I was giving one discussion at a time and turn it into a book.

Mikael: Could you also tell us more about your book about Agile Estimating and Planning?

Mike: As I was writing User Stories Applied there was so much I wanted to say about estimating and planning with user stories (or any product backlog) that I knew I needed to write a book just on that topic. Agile Estimating and Planning came out only eighteen months after User Stories Applied because I didn´t take any time off between the books. The need was apparent and I just kept writing based on all the things I'd learned about estimating over the prior eight years spent trying to get good at it.

Mikael: What is your view on the need for engineering practices such as TDD, continous integration and so on? Is it widely adopted in the companies you work with?

Mike: I'm a huge fan of all of these great agile engineering practices, mostly innovated by early Extreme Programming teams. I remember back in 1992 I was working a fairly large PC-based C++ computer telephony application. There were only six of us developers and I don't remember how many lines of code there were but the ratio of lines of code to processor and compiler speed back then wasn't very good. I wrote a little program that would let us programmers add compile jobs to a Novell print queue. Novell's print queues were quite flexible and you could use them for anything. I then had another program that monitored the “print queue" and would pull jobs from it and compile them. That served us well as a simple, half-automated form of continuous integration. We eventually added a bunch of automated unit tests. I can still remember the excitement we'd get when builds would run and those tests would kick off automatically. We felt like we had a ton of tests back then but it was probably only a few hundred. Seeing Cruise Control—the first continuous integration tool—for the first time was such an “a-ha" moment for me. That was many years after my print-queue-based compiler but I remember thinking that this was what I'd been after all along.

I'll tell you one story about test-driven development. Last year on Christmas I gave myself a Christmas present of four quiet hours of programming locked in my home office. I was starting a new project I'd wanted to get going on for awhile. Only my wife and two daughters (10 and 6 at the time) were home. I was doing TDD and having a great time, making great progress. I then needed to write something that I couldn't think of how to write a test for first. Admit it, we all have moments like that every now and then. I didn't think too hard about it but I tried to come up with a way to write a  test first but couldn't. I then looked around to make sure no one was watching and cheated—I wrote four or five lines of code before going back to TDD. I have no idea who I thought was going to catch me cheating—was my six-year-old daughter going to remind me, “Red-Green-Refactor"?

As for adoption, I do see pretty good adoption of continuous integration or at least “very frequent integration" at most companies. This is a pretty easy improvement at most companies. Plus, it's hard to argue against. TDD is a different story, though. Unfortunately I don't see it adopted as widely or as early as I wish. I can understand why - it is very, very hard to do on some projects with existing code. Still, I wish every developer on every project did it.

Mikael: Do you see any trends regarding what programming languages are used? Is any particular language "winning"? Does the programming language matter anymore?

Mike: I think there are so many good choices that it is largely a matter of what skills exist in the organization. I don't engage in the “Java vs. .Net" debates. Fortunately most of those have died down. Personally, I'm a big fan of Ruby on Rails these days. About two and a half years ago I rewrote the Mountain Goat Software site in Rails just as a way of learning it. I had a blast and became sold on the productivity advantages of Ruby and especially Rails. We've since done other projects including www.PlanningPoker.com, which is a popular free site for estimating agile projects.

Mikael: What is your next professional goal or challenge? Are you writing a new book? Are you devising a new course? Do you wish to revolutionize the software development industry?

Mike: Yes, I am. I'm working on a book on transitioning to agile. I've been collecting notes for over three years on what I've seen work, and not work, in the companies I've worked with. I'm hoping to present some essential advice for teams on both how to transition to and then improve at being agile.

Mikael: Why do you invest time in the Agile Alliance and the Scrum Alliance?

Mike: I was a founding member of each of these non-profit organizations. I spent five years with the Agile Alliance and wanted to do all I could to help it succeed. It was a lot of work but there were a lot of good people involved. I left the Agile Alliance Board last year and haven't done much with that group since. They are in good shape and in good hands and don't need my help right now.

The Scrum Alliance is a bit newer group. I'm still involved as a member of its board of directors and we have a lot of goals still to achieve within the Scrum Alliance so I'm still quite involved. For example, we recently held our annual “Scrum Gathering" in London and it was quite a success. We're in the process of planning one in Stockholm in the fall because of all the interest in agile and Scrum here.

Mikael: You say your favorite tool is the index card. Why is that? What about software tools?

Mike: I like things I can touch. I resisted index cards for a long time. I'd done the usual thing of writing simple websites or two-tier client-server programs that would manage backlogs over the years. We'd write a nice, simple system customized specifically to our needs and that drew just the charts we wanted in just the way we wanted. But then I had a project where for a variety of reasons we chose to use index cards. I thought, “I'm a software guy, I use software. I'm not going to like this." But I loved it.

It is so much more beneficial to be able to stand in front of a wall of index cards instead of looking at something similar in a tool. I've seen the use of a physical task board really help teams too many times to not want to use them whenever I can. I do, however, acknowledge that not every team can use index cards. Distributed teams, especially, find tools helpful.

Also, while I am a huge proponent of putting the sprint or iteration backlog onto index cards, I do think that almost every team benefits from having their product backlog in a tool. The product backlog persists over a much longer period than the short 2-4 week life of a sprint backlog. Product backlogs often get shared among larger audiences and it's often useful to do a lot of what-if scenario planning when prioritizing.

Mikael: What do you see as the "next big thing" in software development?

Mike: Unfortunately, I have no idea - I'm too busy working on the current “big thing." I don´t really think in terms like this. I've been doing Scrum since October 1994 and I named “Mountain Goat Software" a few years before that based on some agile concepts Tom Gilb wrote about in one of his books. Agile is what I do and what I plan to continue to evangelize even if the world moves onto some “next big thing."

Mikael: Thank you very much for your time and some very interestng answers! We look forward to seing you in Sweden again in May!

Learn more about Mike Cohn and Scrum

• http://www.mountaingoatsoftware.com/
• http://www.citerus.se/scrum