Well, I always say my first „Agile” work was 1997 because I clearly remember exerting a whiteboard above my desk to track work on, switching to a monthly release cycles and doing some test first development. But that was before the word Agile was used. And actually, when I think about it some work I did in 1994 had a distinctly Agile look too it too!

It just goes to prove that Agile has never been new, what we call „Agile” today is a collection of practices which good developers have used in a long way. Agile just provides a useful name to group these by.

L.E.: From you professional experience, what are the advantages in using Agile?

A.K.:

People feel better about their work. They see progress, they get regular reinforcement that things are going in the right direction.

Development groups find they can actually meet deadlines, they can deliver working software at approximately the time they need to. And the more they do it the better they get!

And companies find that sofwtare development isn’t a glass half empty, it a glass half full.

L.E.: Agile methods are very appreciated, but could you tell us the disadvantages in using Agile methods?

A.K.:

When you start doing Agile things look worse before they look better.

Some of the Agile tools just make you better. Take iterations, they simply make you better.

But most of the Agile toolkit helps you see your problems more clearly. Many of those problems are already there but maybe you’ve become dumb to them, you live with the pain and have give up trying to change them. Introduce Agile and all those problems are seen clearly. If you don’t address them you won’t get the best out of it.

If you are lucky the Agile toolkit has a solution for the problem you have found but it might be that you have to invent your own solution or face up to hard realities.

One particular problem I’ve seen Agile highlight very painfully is when you have someone on the team who is no playing their part. Maybe their skills aren’t there, maybe they half lost belief in the team, or maybe they want something different. It can become painfully clear when someone isn’t right for a team.

L.E.: How did you change your perspective about software during your visit in Sillicon Valley?

A.K.:

I was very lucky in that I was in Silicon Valley jus as it went from .com boom to .com bust. For a couple of years all sorts of crazy ideas were funded just because technology made something possible. Once the bust started you had to make actual sales.

So the first thing it taught me was: it doesn’t matter how clever the technology, soon or very soon you have to generate revenue. If you can’t generate sales then maybe you shouldn’t be doing it.

The second thing I learned was that the problems of the software industry are universal. There is no land where programmer write perfect code, where testers don’t need to report bugs or product people don’t get frustrated with the pace of development.

L.E.: What are your impressions about this place, known as home to many of the world’s largest high-tech corporations?

A.K.:

Well I’m really glad I went, if you ever get the chance do it. It is the heart of our industry and I expect it to remain so for the rest of my career at least. As a place to live its fantastic – if you ignore the earthquates and traffic! – and that must be part of the reason that what happens there happens there.

People say you can do technology anywhere, well you can but it helps a lot, an awful lot, if there is a big community of similar people around and many potential investors. Technology people and investors have found one of the nicest places on earth to live and as a result of them being there is gets to be even better!

Now the flip side is: it has these advantages but it still isn’t any different! Coders still write bugs, people still search StackOverflow. We should all strive to have a little bit of Silicon Valley inside of us.

L.E.:Regarding your professional history, you worked with Virgin Atlantic Airways, Merrill Lynch, lastminute.com (part of Sabre Tavelocity), BBC, Fugro, Thompson-Reuters. Looking back, what was the experience working there?

A.K.:

Big companies bring on so many problems themselves. I much prefer working with small companies. Small companies have their own share of problems but it is so much easier to trace through to customers and what is really needed. Big companies wrap themselves in procedures, budgets, change programmes and what not and make it so hard to do the right thing.

That doesn’t mean its impossible in a big company, you can do some cool stuff, and the resources available means you can do things totally beyond small companies. Thats part of the reason why big companies look to partner with and even buy start-ups. The start-ups can run fast, do the innovation the the more established companies buy in the innovation as they need it.

L.E.: You wrote two books about software. What is the main focus on each book?

A.K.:

Well its three now actually! Xanpan is the latest, my own blend of Exteme Programming and Kanban – you have to look at the name. Xanpan is different because I wrote it with LeanPub which is a very different writing and publishing platform.

My first book, „Changing Software Development” is a deep look at the role of knowledge and learning in software development. It really sets out my philosophy: creating software is a learning activity. If we think about it like that everything else falls into place.

Now the traditional way of developing software – the so called waterfall – attempted to segment learning into distinct phases and stop learning at specific points. Of course when I put it like that its obvious that it isn’t going to work!

And its also clear that the Agile approach, lots of little feedback cycles with work across the board, is a much better learning environment.

The second book, Business Patterns for Software Developers is completely different. It hardly mentions Agile or Lean at all. Its a book of tactics and strategies used by successfull software creators to achieve business success. In some ways its misnamed, people think the „Developers” in the title equates to coders and testers, it doesn’t, it really means „teams who create software.”

L.E.: What are your future plans regarding writing?

A.K.:

I regularly say I’m going to stop! But I keep doing it!

After Business Patterns I said „No more books!” but then I started playing with LeanPub and along came Xanpan. Actually Xanpan was an accidental book. Having completed it there was more to say so I’ve had Xanpan 2 on the LeanPub system for a while but progress is slow.

Partly that is because I agreed to write a series of articles on User Stories for Johanna Rothman’s Agile Connection community (http://www.agileconnection.com/). It now looks as if those columns will get rolled into another LeanPub book.

L.E.: You are specialized in the business side of the software development. This autumn, you will participate at the Masterclass “Agile Day”. What will you teach the developers and Software Managers at this Masterclass?

A.K.:

Glad you asked, I just finished putting the slides together! Actually, there are slides but this is an interactive course, I want people to experience user stories, requirents and backlogs so I’ve got several exercises planned. Most of our time will be in exercises.

At a most basic level I want people to come out really having mastered user stories. These are the most common Agile requirements technique but it is so often used badly. I sometimes joke that user stories are so bad because they are so easy!

Beyond user stories you have to keep the overall objective in sight, understand requirements as distinct from specifications, and more important than anything else: know the benefit.

Its easy to write requirements and stories but how many people know what each story is worth? What benefit does it bring? Can you put money against a stories? Thats one of the things I want to teach people: how to estimate value. Its an exercise I’ve done many times before and I guarantee people will be laughing.