ericlefevre

The nice guys at VersionOne have put together a simple / simplistic rating system for Agile organizations.

Let’s be clear: this is not, and cannot be, an effective way of measuring your agility. There is no such thing as a pure Agile organization, one never stops improving, yada yada yada. But well, it’s there and it’s better than nothing. Give it a try.

Yesterday, we’ve had a presentation made by Serena (ex-Merant, ex-Intersolv), editor of such gems as Dimensions, PVCS and TeamTrack.

I have not had much exposure to Serena’s tools, but I’ve worked for a company that used PVCS. It was incredible slow and heavy, enough so that the remote teams ended up using their own local version management system. Guillaume Tardif and I promptly replaced it with Perforce (thanks guys for such a good tool). I was also involved in an audit done at an insurance company. They were apparently the first French customer using TeamTrack. I remember them complaining that it was heavy and buggy…

Anyway, the funny thing is that Serena has plenty to say about Scrum! Half of the sliders were about what Scrum was… and how well their tools (especially TeamTrack?!) fit into it. Well, the guy did admit that they would need time to configure the tools first. But, after that, they can be *so* light and adaptable to each Sprint!

Seriously, do we still need such beasts nowadays? Please tell me only companies foolish enough to aim for some CMMi level still buy that.

OK, these guys do seem to have one interesting thing to say. Apparently, they were the initiators of the Eclipse Application Lifecycle Framework (ALF). Sounds reasonable interesting.

It is often say of Scrum that it is the Art of the Possible. In fact, Ken Schwaber even calls it a fundamental principle of Scrum.

Today, Ron Jeffries reminds us on the ScrumDevelopment mailing list that it is too tempting to use it as an excuse to stall and stop making more progress.

If [an organization] uses the notion of being “pragmatic” to permit themselves to be stagnant or nearly so, I find that troubling.

Thanks Ron.

How many Sprint Backlogs do you have? We have one for the entire project, and I must admit that there is no good reason for that. As it appears, the general recommendation is to have one per team.

Benefits:

• each team feels more committed to the document and to the burndown chart
• delays specific to a team would not get hidden by progress made by other teams
• designing the Sprint Backlog would take less time
• one Track Master (if applicable) per team can be in charge of the Backlog, as opposed to one person in charge of the entire project

Cons:

• more documents to manage, but responsibility is clear and one person is still in charge of no more than one
• document styles may diverge (not a big deal)
• when starting from the Product Backlog, it is more difficult to figure out where to look to see progress on a particular feature; this should not be much of a problem, considering that stories are usually clearly assigned to particular teams; it might help to add a column in the Product Backlog that gives the name of a team in charge of each story
• no synthetic view for PO & management; this might be the real difficulty. For example, in our case, management and customer have been sold on the idea of applying Scrum because it would make it easier to see progress during in the course of an iteration. This should be mitigated by the facts that

• a Sprint Backlog is made for the Pigs (the Team), not for the Chickens (management) or even the Product Owner; it is the team’s own tool, not anyone else’s

• it is probably not too hard to combine automatically the teams’ Sprint Backlogs into an overview document

All in all, it seems that the benefits are much higher than the disadvantages. So, what are you (& we) are waiting for?
Check out the complete discussion on that very subject in the Scrum Development mailing list.

I discovered only yesterday about Pandora (yes, I know, I’m late; it’s being talked about since 2005), a really neat website that is able to play songs similar to those you suggest.

You suggest a song (or an artist); it figures out the characteristics of it (tone, rhythm, instruments, style) and plays automatically more like it. Later, you can tune the selection by approving or rejecting suggestions. It works really quite well. Well, they apparently have an army of 50 people analysis every single song with hundreds of criteria (!). A bit reminiscent of the beginnings of Yahoo!, though I doubt they will make it as big.

Give it a try with songs in the style of Brian Eno.

In Lean Software Development: An Agile Toolkit for Software Development Managers, Mary & Tom Poppendieck mention “Make decisions at the last responsible moment” as one of the 7 rules. I’m happy to report applying it in my current project.

Two examples:

1. as we are rewriting a legacy application in Java, we were supposed to recreate a link to an external website that helps sending automatic text messages to mobile phones. In the past 6 months, my manager kept asking me to get details on how it had been implemented in the legacy application. To which I usually replied: “are we going to implement this in the next iteration? no? well, let’s wait then.”
2. another feature was to open the local email client. A guy from systems mentioned that someone (?) had said that it would be necessary to be able to configure the type of email client in some properties files, for the cases were the customer would be using a different email client from the one configured by default. I thought “what the…??” and mentioned that I would wait for him to get more details, but in the meantime would implement the simple opening of the default email client (using mailto:)

Well, we learned in the past week that the external website had closed down. We are expected to integrate with another one, but not for a couple of months. Good thing that we didn’t spend time investigating that, right?
As for specifying the email client, the guy never came back to us. After 6 months, we can safely assume that it was not that important after all.

A BarCamp is taking place in Issy-Les-Moulineaux, near Paris, this WE. The topics include Web 2.0 (of course), as well as social networks and other things. As always, attendance is free, though participants are expected to contribute by coding, throwing ideas in the air, debating, etc. You could say it is rather geeky ;-). I notice Eric Mahé from Sun France among the attendees.
More details on BarCamps.

Register by editing the official wikipage.

Just yesterday I visited a client (who had actually read this blog!) who was interested in hiring me to write the data access layer of their application.

When they asked me if I write detailed UML diagrams with a CASE tool before coding, I remembered that the project was based on Spring, Hibernate, JUnit, mocks (I managed to put a word in favor of my favorite mock framework), etc. They had also mentioned working together with end users and clearly said that they didn’t feel forced to follow the company’s official development process. Clearly, a bunch of open-minded people willing to try new things.

I then explained that, when possible, I preferred drawing just enough on a white-board to get started, and maybe a bit more later if it can help me deliver for the next iteration. Both the project manager and the tech lead (who already writes those diagrams… and did agree that they couldn’t be very detailed and would change anyway) were slightly shocked and wondered aloud if I would be able to work with them at all.
In the end, they said something on the lines of

“we are definitely willing to improve our process and your opinions would be a valuable addition to our team. However, we are not sure that you would be happy working with us”.

The fact that our daily rates are a bit high compared to the competition may not have helped either ;-)

I had the hardest time finding in France some of those giant office post-it notes that Craig Larman recommends in his Scrum course.
My first guess had been the usual office supply stores in Paris such as Gibert Jeune and various small stores. The best I could find was repositionable whiteboards.

One thing that did not help was that the US name for those beasts is easel pads (or rather Self-Stick Easel Pads), which does not translate well in French. But I did manage to figure out that the name in French stores in something like tableaux POST-IT géants or meeting-chart post-it.
So, where does one find them? Well, I did find 3 online stores (prices are for a set of two packs, taxes not included):

• http://www.vikingdirect.fr: real cheap (less than 20 euros), though only the smaller kind is available (2×20 sheets, 50,8 x 58,4 cm); 0,5 euro a sheet (direct link)
• http://www.busiboutique.com: have the largest kind (2×30 sheets, 63,5 x77,4 cm), though a bit expensive (more than 70 euros); 1.16 euro a sheet (go to the website and run a search on meeting chart post it)
• finally, for those who prefer buying from well-known stores, http://www.officedepot.fr/ offers the smaller ones (2×25 sheets, 50,8 x 58,4 cm) for 30 euros; 0,6 euro a sheet (direct link)

A few month ago, free.fr, the second-largest ISP in France, stirred things a bit in the French server hosting arena when they introduced their debibox solution: a dedicated machine with unlimited bandwidth for 30 euros per month!

Just a few days ago, the response came from OVH, one of the largest hosting company in France (and a partner to free.fr through their FreeIX interconnection service). They now offer a similar machine (with the exception of RAM) for 20 euros per month! The amount of RAM in this one is 256M, while dedibox has 1G. But 256M would be more than enough for a personal or semi-professional usage, especially when using Linux (Windows 2003 is also available).
20 euros for your own machine! In the US, I couldn’t find any offer below 65$ / month. I admit I didn’t look very much, and the machines are usually more powerful. But where are the cheap options?

This is also a valid alternative to Amazon EC2 for cheap hosting.

In a previous post, I mentioned that Paul Julius was seeing a 30% turn over after Agile practices are introduced.

Apparently, this is also expected by Ken Schwaber. This sounds quite contradictory to one the reasons for adopting Scrum, mentioned by Ken himself:

“Why should I be thinking about adopting Scrum? If you develop software and are unhappy with the turnover of staff[…] you should consider adopting Scrum.”

Well, as one can expect, the plan is that Scrum introduces disruption. Some people will leave, some will join, and hopefully the result will be a more stable team. This graph explains it better.

But that’s still hard to hear, isn’t it?

Jason Yip pointed me to an interesting post by Kathy Sierra: Don’t make the Demo Look Done. Also a nice reminder of Joel’s Iceberg Secret.
That brings back fond memories of the beginnings of our project. Our client wanted to see a running Use Case as early as possible. The problem became that they demanded to see a perfect front-end… down to the pixel. So we kept going back and forth, releasing to the client and then tuning those nasty pixels, for months. All that, of course, while we knew we would have to redo most of it since the graphical framework was still under development. Of course, we explained how useless it was, but hey, it was in the contract, right?!