Artisanat du logiciel et méthodes agiles

In English

Chattering on the international agile news

Fil des billets - Fil des commentaires

Architectural Design Challenge by James Shore : a review

A few weeks ago, James Shore had initiated an architectural design challenge for which I submitted an entry.
Some other people also proposed an implementation. I have listed 4 :

I wanted to review these implementations. I tried to look at them from various perspectives and the exercise was quite interesting.
Here is what I found for 3 of them. I will not talk about James Shore implementation. It could be the topic of a dedicated blog post in the future.

The perspectives that interested me were :

  • the global workflow of commands
  • the coupling between software units
  • the unit testing method

Here we go.

Software Craftsmanship Comic Revisited

Last week, I drew a comic about software craftsmanship and I asked for feedback on the software craftsmanship discussion list.
The main output was that my drawing could be interpreted as "software craftsmanship is superior to agile". Since it was not my intent, I'm trying to come with something better.

When you step into the agile world, you start a journey. It is up to each practitioner to find her path. Software craftsmanship is the way I'd like to go on this path because it features values and principles that I like.

Actually, just as a software developer might follow agile principles without claiming to be "agile", one might follow the software craftsmanship principles without labeling herself as a "craftsman".
This might have even happened before the words were invented.
To me, the biggest change with agile a few years ago and software craftsmanship today is that one can read a few word on a manifesto and says "Hey! That sounds like me! This is the place I want to go!".

Software Craftsmanship Path

Software Craftsmanship

craftsmanship_en.png

An Architectural Design Challenge by James Shore

James Shore proposes to experiment a design challenge to deal with architecture issue. It was posted a week ago and some answers already came out. I haven't looked at them yet and I wanted to try on my own. So, here it is.
My solution is coded in C# with basic tooling : Monodevelop IDE, NUnit testing framework and Moq mocking framework.

How does design get done on an Agile Project ?

I watched a great presentation by Jeremy D. Miller : How does design get done on an Agile Project ?.

Jeremy shows through multiple examples the kind of design issues you inevitably face during an project and explains how to handle them in an agile way.

Pod pod pod pod

Thanks to Jeremy D. Miller I just discovered a place that is worth a web surf: Process, People, and Pods. Fred George started to blog less than a month ago and, in a few articles, he described the very nature of agile software development.
From agility inner secret to encounters of the third kind (of developers) and path to development wisdom, we go through all what we would like to tell about our jobs if we knew the words for that.

Oh, and did I tell you about the pods? You should really read those ones too!

The Time Dilation of an Ideal Day

Ideal Day, Story Points, Load Factor, Velocity... Lots of concepts for a simple goal : predicting the amount of work that will get done for a given date. Anybody who went through this kind of measurement system probably tried to grasp its validity. Dave Churchville wonders "How long is an ideal day ?" in calendar time. Ed Gibbs rebounds on the difficulty that people have with story points when time units come more naturally.

I'm no exception. I used plain story points for a while but I recently started to trick this tool to get (I hope) a better matching between the developer estimates and the amount of work units.

Black-box project management

I love metaphors on project management. I just read a good one by Tom Looy : "How Long is a Piece of String?". You can get an estimate by looking at it but you will get a more accurate value by measuring it with a ruler. Estimating is not an easy job, especially when it comes to predicting when a piece of software is done. In the early stages of a software project, when you can barely estimate and certainly not measure anything, fixing scope, cost and dates is impossible.

Years ago, I was appointed software project manager for the first time. Being a software developer, I intuitively knew that I should be careful with scope, cost and dates issues. I was reluctant to draw a full gannt chart too early in the project because I suspected that people would rely too heavily on it. The projects director I was reporting to told me : "This is not a way to run a project. You must list every task for the project, estimate them and put them in the chart then you will get a release date. From there you will start tracking the team progress". I complied with the order.
Any experienced project manager obviously knows what happened : as the first tasks were not completed on time, the release date started to slip.
The estimates were indeed very bad. Half of the developers had just graduated from university and relying on their estimates was the worst thing to do but the rookie project manager didn't know that.

Now imagine this project is a big black box with 3 levers...

To Fix or Not to Fix : That is the Question

Dave Churchville talks about things you should care about when planning bug fixes. I totally agree with his point. On one hand, it does not make sense to implement more and more features without fixing serious hazards first. This is sometimes called creeping featuritis. On the other hand, stopping any shipping till every bug is fixed can make more harm than good : a buggy software can provide more value to the user than no software at all.
I must confess that I had not fully understood the arguments in his first post. Indeed, one of the biggest misconception in software development is that bugs don't need to be prioritized just like any other feature.
That being said, it is a wise decision to let the business, the customer or the product owner, decide if the development team should implement new features or fix a few more bugs. Now the problem is : does the business have enough information to make a good decision ?

Every Process is an Iterative Waterfall

Dave Nicolette raises concerns about organisations moving to agile development while appointing "traditionally-minded" managers. Risk #1 is that these managers turn the agile processes upside down by transforming them into a Staggered Iterative Waterfall as described by Kane Mar.
I deeply agree with the key statement of those articles : agility's main duty is improvement of interactions between individuals with the help of suitable processes. It is not about focusing on a well-polished process aimed at eliminating every possible waste in human activities. However, I do not subcribe to the RUP-bashing movement that seems to result from it.