Skip to content

JurgenAppelo's blog

Book Review: Agile Management for Software Engineering

April 28, 2008 by JurgenAppelo

AgilemanagementI have finished reading Agile Management for Software Engineering, a book by David J. Anderson, and I am very impressed. Granted, the book is already four years old (I'm a little behind with my reading) but it's still relevant. It is the first book I've read that tries to back up the agile approach with solid theory. In this book David uses the Theory of Constraints to explain why lean/agile project life cycles lead to success, and a higher return on investment (ROI), more often than traditional life cycles. He also presents an interesting in-depth analysis of Scrum vs. XP vs. FDD.

However, since I am Dutch, you can usually expect me to have found something to complain about (or disagree with). And, being the considerate person that I am, I would never try to disappoint you. So, here are my three gripes:

Not Repeatable Results but Repeatable Success

April 24, 2008 by JurgenAppelo

BrainI don't believe in repeatable results. I only believe in repeatable success.

Repeatable Results vs. Repeatable Processes
In his recent Agile Newsletter, using the results of the latest Dr. Dobb's survey, Scott Ambler showed his readers that most developers, project managers and IT managers prefer repeatable results over repeatable processes. Not surprisingly, according to his survey results, people in the agile community lean more towards repeatable results than those working in traditional organizations. Most respondents of Scott's survey also reported that their personal preference for repeatable results is bigger than that of their organization. Everything considered, it seems that there is a global shift towards a growing importance of repeatable results vs. repeatable processes.

Fooling Myself with False Velocity

April 21, 2008 by JurgenAppelo

Writing2I'm an idiot, I have fooled myself. I'm usually quite good at fooling others, but this time I have fooled myself. And I did it with what I might call a false velocity.

Velocity Defined
Velocity is the rate at which you complete your work, in a certain period of time. This might refer to the number of stories completed, the number of issues processed, the number of exams passed, the number of kilometers driven, the number of hamburgers baked and served, or (for some guy I know) the number of girls dated and dumped.

The Velocity of Writing a Book
I might have mentioned earlier that I'm trying to write a book. It's a book about managing software development, and the things we can learn from complexity science. Last year I did a lot of research, a tremendous effort that will continue to the end of this year. And I started writing my first pages of text in January this year. I am planning to write around 350 pages in 1.5 years, which equals to an average of 5 pages per week. After 15 weeks I have completed 75 pages of text, which is... 5 pages per week! It's exactly the velocity I need to finish the book as scheduled. Right?

Why Managing Small Projects is Harder

April 17, 2008 by JurgenAppelo

DedicatedserverSome people think that managing small projects is easier than managing big projects. They are right, unless the economies of scale require you to manage a number of those small projects at the same time. In that case, managing small projects is a lot harder than managing a big project!

Dedicated servers vs. shared servers

Many web sites are too small to run on their own dedicated servers. I know, I've built a lot of those sites. They usually run on shared servers (together with other web applications for different customers). As many system administrators know, management of a shared server is a lot more work than management of a dedicated server. On a shared server, the applications are fighting for the same resources (memory, drive space, database connections). And we must try to make sure that, when something goes wrong in one application, it doesn't bring down all the others too. Unfortunately, this does happen occasionally. One time it might be because of a Denial-of-Service attack against one particular site, another time it's simply because I screwed up again with one of my infamous infinite error loops. Customers often complain when problems with another site causes a failure on theirs. We then kindly suggest that they open up their purse and get themselves a dedicated server. Or, as a bus driver might say, "If you can afford yourself a taxi, sir, then why take a bus?"

Scope, resources and processes: change everything!

April 14, 2008 by JurgenAppelo


As an agile writer, I like to write articles in multiple iterations. Feedback from readers is essential to me. There's no such thing as gettings things right the first time around. Not for programmers, and not for writers. So I've decided to give the readers of this site a chance to be the first to read my latest article.

The article is called Project Change, a Way of Life (PDF, 2.27MB)

In this article I try to link complexity science with agile software development. I attempt to show why there is no such thing as a best software development method, why managing scope is a too simplistic interpretation of “embracing change”, why corporate standards for processes are a bad thing, and why you will never get things exactly right.

The article includes comparisons to biology and other types of complex systems, several little nuggets of wisdom, and some personal experiences involving my car. Here's a little sample of what you can expect...

A Product Is Successful Until It Fails

April 10, 2008 by JurgenAppelo

When is a software product successful?

We all know industry reports (particularly the infamous CHAOS report of the Standish Group) are always saying that only a small number of software products are “successful”. But what does that mean? People have been struggling to find a proper definition for years and they are still not in agreement. One traditional view has it that a product is successful when it is delivered on time, within budget, and according to specifications. Others say that a product is successful when it matches a customer’s expectations, paying back its investment in the form of business value created, as laid down in a properly defined business case. Another view, often advocated by agile experts, is that a product is successful when the stakeholders are happy, whatever this may signify at the time of delivery. But I think they are all wrong.

Specialization is Good

April 7, 2008 by JurgenAppelo

I think specialization is good, and cross-functional teams are not. Here's why...

Suppose you are the publisher of a magazine about cooking. It's a glossy magazine, with recipes, restaurant reviews, and lots of pictures of expensive cutlery and celebrities tasting trendy oysters. The magazine is released every month and you have a huge list of recipes, restaurants and celebrities waiting to make their appearance in one of the upcoming editions. Getting a new edition out the door is always a stressful experience. The celebrities never commit to any culinairy photo shoot. The chefs always complain about the way their food is described. And some of the recipes are so bad, you wouldn't even want to cook them for your neighbor's dog. But still, despite the bruised egos, and the meat clevers flying around your head, a new edition is published on the same day of each month.

Best of