Agile Software Development

I'm in the process of reorganizing and streamlining job descriptions in our company, and now the HR manager wants me to define the differences between a junior software developer, a medior software developer and a senior software developer. Ehm... ok, that's a tough one. My first thought was that juniors need coaching, senior don't, and mediors end up somewhere in the middle. I would be perfectly happy with such a fuzzy-logic definition, but I'm afraid both our HR manager and our employees want more tangible function profiles.

Oh boy...

It doesn't happen often that I keep silent about anything. Whatever the subject, my opinion is usually formed before I have finished thinking about it. However, with source control techniques, this is apparently not the case.

Two Great Articles
I know two very good articles on source control that every software developer on the planet should read. OK, I admit that is an opinion. But once you've read them, I'm sure you will understand why I feel that way.

Version Control for Multiple Agile Teams (Henrik Kniberg)

The Importance of Branching Models (PDF) (Chuck Walrad, Darrel Strom)

Jurgen! What's your opinion on Scrum books?

For many agile practitioners, particularly the ScrumMasters among us, books by Ken Schwaber are a must-read. I can explain, using a wide range of both original and lame excuses, why I still hadn't read Agile Project Management with Scrum. But I won't. Let me just tell you how this book compares to all those other agile books out there. There are plenty of alternatives to choose from (by Cockburn, Highsmith, Anderson, Coplien, Poppendieck, Larman, Beck, Fowler, to name just a few...) so it's interesting to see what Ken's unique contribution is to this crowded field...

1. The book is very rich in case studies, and I think this is the best reason for reading it: there's a lot we can learn from real-life examples. Theory is always important, of course. But sometimes it's even more important to see where theory has failed in practice, and how Ken has managed to solve some problems in ways you won't find in the standard Scrum process descriptions.

A good team building exercise which (at least to me) is preferable over helicopter droppings, mountain climbing and mud wrestling, is to invite a bunch of colleagues for an evening of cooking.

Team Building
I regularly organize these team building events so that employees have a chance to get to known each other, to improve communications, and to show off my Italian kitchen. On such an occasion six of my colleagues come over to my place, usually straight from work, and when they arrive I hand out some copies of different Italian recipes (after hiding the expensive wines and having made sure that all ingredients and cheaper wines are prominently displayed and ready for use). These team members have no experience in cooking together, while some of them have never had to cook their own dinner at all. And on top of that they are working in a kitchen they have never used before.

Project evaluations (or retrospectives) are a nuisance. Everybody knows they are important, but nobody performs them. With at least ten new projects starting every week in our company, how can I instruct our people to get all project stakeholders together (in ten different settings) and construct a "lessons learned" list of the ten projects that were delivered the week before? Nobody is available for such meetings because they are all too busy making sure the new projects are initiated properly. Sure, this is no excuse. But it is reality.

Automate the Process
To get around this problem I have decided to automate the evaluation process.

Many authors have elaborated on the importance of iterations and increments, particularly in the last ten years. Unfortunately, only few of them have made serious attempts to explain what the differences between iterations and increments really are. Even worse, methodologies like RUP and SCRUM have muddled the waters by making iterations and increments equivalent to each other, which makes it difficult for project managers and development managers to decide how to handle temporal cycles in their software projects. And communication among agile practitioners doesn’t get any easier when authors of agile methods like XP and DSDM don’t agree on definitions and terminology. The 16-year old definitions of increments and iterations, provided by Alistair Cockburn, are as follows:

• Incremental development is a staging and scheduling strategy in which various parts of the system are developed at different rates, and integrated as they are completed.
• Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system.

The experts in our industry have an amazing ability of inventing sexy names for simple things that are as old as my cooking pots.

An example:

I am responsible for our company's intranet application, of which I try to release a new version every month. I have more or less given up on planning of this project, because I work on it whenever there's time. And time, unfortunately, is always in short supply. One month I may be too busy managing dual, triple and quadruple monitors for developers, following up on SharePoint upgrade disasters, or seeking the best tool for tracking surprise features (others call them bugs), while another month I spend all my time training mandrills to mimic the behavior of senior software engineers. All in all, just your typical CIO stuff.

Advertisement:

I 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:

I 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.

I'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?