ericlefevre

I always make a point of using an application or a website in English. This helps getting the “real” experience, as the developers intended it, and avoid crappy translations. I don’t go as far as changing the local settings of my machine, though I do remember one instance where a Java application running on a Swedish PC was failing, while it was working smoothly on British PCs (since the application was to be deployed only on British-based computers, it was not an issue, so we never looked into it).

Just today, my friend Guillaume Tardif was pulling his hair out. He was sending emails with text attachments, and those attachments would never appear in his email client, though they were perfectly visible in the email source.
However, those same emails displayed fine on my email client. And my email client is EXACTLY the same as his (it’s webmail, run by our ISP)!
Fortunately, I had the good luck of thinking about changing his language preferences from French to English, and voila, text attachments visible again!

I checked: there does not seem to be a bug for that recorded in IMP.

Seriously, when you hear about things like that… can you still afford *not* to use a piece of software in English?

Eventually, I logged a bug with free.fr (I cannot do that directly on bugs.horde.org, as I do not even know the version being used). We’ll see.

Update (05/07/06): Free.fr has now fixed the issue! Excellent responsiveness.

As I write this post, I am still under the shock.

In French, we have sayings that go like this (I’m sure they translate well in English): “we had reached to bottom of the pool… and we have started digging”, or “we used to be facing a cliff, but we have made a great step forward”, or “we were reaching a wall, but we are gaining speed now”.

On our project, in the past months, it became more and more obvious that things were not going right. Basically, we were missing the iterations’ targets by 10-20% each time, despite aggressively recruiting, and no signs of recovery. Relations with the customers were ok (sort of) until the end of the last iteration, when we had to admit that we were falling short (it was also the case for the other iterations, but this time we did not find any good excuses).

So, naturely, a lot more pressure was put on us for this iteration. 3 or 4 new guys joined the project, to a total of 21 (onshore and offshore combined). Widly optimistic assumptions were made in order to reach an scope acceptable to the customer (new joinees up-to-speed from day 1, Team working 6 days a week, mainframe computers available at all times, though it has been made clear that there was a high probability of them been offline for a entire week).

And, just yesterday, the offshore manager dropped a bombshell. “Why are you keeping the Save feature in the scope? we did put it in the iteration plan.”
What do you mean it is not part of the plan? it *is* the plan, or close to it! It’s the main feature that we want to work on! It is exactly the reason why the Delete feature was forced into the scope! It is at least HALF of the total iteration effort!

What on earth happened?

Well, the dear man simply never said that they would not implement it. For weeks, we sent him our view of the scope that included the Save feature, and he happily responded with a plan that did not include it. And nobody even noticed until now. (note: do not tell us that we were not following the Scrum process; we know that)

So, the estimations that I thought were ridiculously optimistic did not, in fact, even touch the surface of the iteration scope.
A scope that we had, of course, already communicated to the customer.

This morning, a status meeting with our CEO is taking place. I can only guess at the name-calling, finger-pointing and the scape-goat searching that took place.

Thank god I am not a manager.

Could we have done better if we had been religiously following the Scrum process from the beginning? I believe so, yes. That said, the larger issue here is that, on a fixed-price, fixed-date, fixed-scope project, the probability to reach the goal is small. And I don’t see how Scrum would have helped making that clearer than the way we did it. Even if it would, I suspect that someone would have done his best to hide it to the customer anyway.

Last Monday, we held the first retrospective meeting on our project. I had pushed for it to take place, and I thought it would go better than the Sprint Review. As it happened, it did not.

First, I contacted people much earlier. For the Sprint Review, I only told the customer on the very same day. This time, I told my onshore and offshore colleagues well in advance. I did keep the customer out of the loop, on our delivery manager’s advice, considering that we were not sure how it would go anyway.

In a Scrum Retrospective Meeting, all the stakeholders (Team, ScrumMaster, Project Owner) get together. Here how it is supposed to go (if I got it right):

1. split in small groups, listing positive things that have taken place in the past iteration (”plusses”), plus things that can be improved upon (”deltas”). Hence, the “plus-delta analysis”. Some people also like to add any significant events that have taken place in the past iteration;
2. show & tell about their findings to other groups;
3. the group members get together again to discuss possible actions;
4. show & tell the actions to the other groups;
5. finally, voting takes place.

Here is how we did it wrong:

1. we first met on our respective sites, discussing only the negative aspects of the past iteration;
2. then, we presented them to the offshore manager;
3. then, we (onshore) discussed possible actions;
4. then, we presented those actions to offshore;
5. finally, we published them on the project wiki;
6. voting is supposed to take place in the days coming after that (though I have no clear idea when or who will do it).

I was reasonably pleased with our findinds and our actions. Though they were not many, and though we did not list positive aspects, at least the actions were quite concrete and easy to assign.
However, I found that the actions from the offshore team were not very good: actions were not well identified (”we should get more information on what onshore is doing” to which I responded: “we are already doing that, what do you want us to change or do instead?”. They did not say.) Strangely enough, in some cases, they *did* have actions in mind, but did not communicate them. For example, they mentioned that “bug management should be streamlined”. OK… but that’s not an action. Well, after some searching, it appears that the action was to define a process and that it was to be done by offshore. Alright, then!

Much of the conference call was spent trying to explain what each other meant (not easy to make a French team and a Indian team communicate… with each speaking English with a funny accent). Some more was spent on justifying and some (limited) finger-pointing. In the end, only a small portion of the time was really spent on productive activities. Most concerning was the fact that the onshore project manager thought that it was a waste of time (I did my best to explain her that we’ll do better on the next iteration).

Here are some suggestions from Craig for next time:

• do the entire plus-delata analysis and action finding before the proper Retrospective Meeting. The results should be published, preferably on the project wiki, before the meeting;
• show & tell all this to the other team;
• vote (offline).

We’ll see.

Yesterday evening, I attended a internal presentation on Project Metrics (if you’re interested, the promoted process was QGM).
As a technical guy, I took note of an important thing. We were in the middle of a part describing the goals of a project. We were fed with the usual triangle of Price/Time/Requirements. But the presenter, my colleague Ludovic Legros, had one additional thing: team morale. For him, “a project that has been badly perceived by the development teams is not considered to have been performing well.” This reminds us of the sustainable development promoted in Scrum (and many others).

A thing that strikes a chord in our (onshore) team, merely a week after the offshore managers took the decision of making the offshore team work 6 days a week on a regular basis (so far, they were “only” working from time to time on Saturdays).

As part of the actions for this iteration, the offshore managers (the ones based in Bangalore, not the ones based in Paris) have announced that the development Team will work on Saturdays from now on. My colleagues and I, in France, are not concerned by this, of course, though we are officially part of the Team. Note that nobody from the Paris office asked them to take such a decision.

It is important to know that offshore Team was already working on Saturdays from time to time (they even worked on a Sunday once). However, they never billed onshore for this (that always baffled me), and the offshore manager always reported that individual people were working 40 hours a week (the extra hours worked most days are not counted as well).

I believe that the management in France will be getting the worst part of the deal. Here is what I think will happen:

• people will work on Saturdays (I mean by this that they will probably not try to cheat and pretent they cannot come. They will be there.)
• productivity per day will decrease (as was painfully demonstrated the WE before last, when they worked the 2 days)
• productivity will probably decrease on week days as well, as people will be tired, will go home earlier, and or will report being ill
• onshore will be billed for the extra day worked per week, ie. 20% more

In the end, onshore will be paying a lot for only a marginal (or even negative) return. Not only that, but the development Team will soon get tired of it. July being traditionally a delicate period (this is when the appraisals take place), we should anticipate some departures. And it’s usually the best who get hired first by the competition…

My webhost, who is also my ISP, now offers free upgrades to 10 GB for all (free) personal websites!

No idea what I will do with that, considering that I have yet to reach the 1 GB threshold, which was offered 1 year and a half ago.

Today, I organized the first Sprint Review for our project. This was not something that we had planned in advance. I did mention it a couple of weeks ago to the people in Valtech, but I did not take the time to tell the customer in advance.

Anyway, the delivery had been made the day before, and I thought it would be a good, Scrum-friendly idea to get the customer (that is, their Project Manager, plus the testing team) to look at our application in a controlled environment before they start playing with it on their own machines.

For this, I contacted 3 people outside our Team, mentioning that any other people would be welcome:
- their Project Manager (not a Product Owner)
- our own Project Manager (not a ScrumMaster… but could be called Delivery Manager, though there is another person who might be with that role on our side)
- the head of the client testing team (you would call him the Product Owner; we consider him that way, though he does not know it)

The reaction:
- our Team (3 persons) agreed it would be useful to give it a try
- their Project Manager liked the idea, and mentioned that he would join, but didn’t
- our Project Manager didn’t mind either way; by chance, she was in the room at that time and kept a distracted ear open, but worked on other things
- disappointingly, the Head Tester (our Product Owner) was not interested at all. He kept refering to the fact that any live demo will not be as committing as the Release Notes and other documents. I did make the point that it would make it easier for us to convey information, and also that we will happy to have a live reaction on our work (I didn’t say that it might also make it easier for us to make them swallow some shortcomings). Still, he didn’t care. However, he did talk with the other 2 people in his team, and they agreed to come over.
Important note: this Head Tester (”Testing Head”? ;-) ) is *not* an employee of our customer. In fact, he is himself an external contractor, which must explain why he is being this rigid, by-the-book (or rather by-the-contract) guy.

The setup:
- our functional champion took over a computer that was not used for his tests. This is because the official test machines (target systems in the contract) are in fact painfully slow and we thought that they would not show the application in a good light. Also, another problem is that the Contract signed between the customer and us still referred to obsolete computers that are now being retired. So the actual computers will be much faster than the ones provided to us by the customer. Note that the testing team also uses these new machines.
- our functional champion was sitting at this machine.
- the 2 guys from the test team sat behind him.
- I got caught into looking at other things by our Project Manager, though I did manage to keep an eye on the demo most of the time.
- the last member of our Team was following the demo, standing behind (in fact, the functional guy was using his desk, so he had no choice but to watch).

The demo:
- the functional guy basically went through all of the implemented screens, commenting quickly on what had been done, and what was still missing (all information already in the Release Notes). Occasionally, the rest of the Team (the other guy and I) stepped in to provide more details that were being forgotten.
- the test guys asked about a few features that they were interested in, with a slightly derisive tone on their voice. That was not very pleasant. That said, it is probably an improvement, compared to them criticizing us on their own (presumably).
- one or two screens failed to open, which was a bit of a blow to our self-esteem.
- at the end, we asked a couple of questions, not directly related to the delivered application
- in total, it took about 30 minutes

Was it useful?
- well, most of the developers were actually missing, since they are based in Bangalore. So it certainly was not very useful to them.
- one key person (the PO) was missing.
- I believe it did help in creating a link between us and the testing team, making them ‘feel’ for the fact that they are now taking the baby in their arms
- since it is taking not very long anyway, it’s worth trying again

Possible improvements:
- get the Product Owner to come (maybe he will come by himself next time, depending on the feedback from his team)
- make the offshore team more involved by keeping a webcam open for them to see how it goes
- I sent an email to the guys who did come over (with the PO and Project Manager in copy), explaining why we did that demo, and why we’ll do it again at next delivery. With a tentative date.

Here is another in a series of well-established books lent to me by my friend Thomas Chuzeville.

This one is supposed to teach you all the things learned in an MBA (surprised?). Sounds like one more of those ‘do it yourself in 3 easy steps’, right?

Well, yes, that’s exactly what it is. But in a good way. There actually is quite a few things to learn in it, especially for someone like me who might not have the inclination to attend a one-to-two-year, eye-poppingly expensive course.

The book is organized in 10 (still surprised?) chapters, one per main subject addressed during such courses.

The best two are by far Marketing and Strategy, which made me go “so, that’s how it works!” Seriously, my own graduate studies did not cover this, far from it, and it’s not like my employer is going to give me free training, just for the sake of it.

Organizational Behavior is another one of those. It explains why managing people is complex (not something everyone is aware of). Lots of interesting bits, though not in great detail. At least, now, I know that I know nothing about OB.

Same for Operations, which is an excellent introductory course on Production, with a nice overview of the management tools available to control and steer. I feel that it misses more detail on Lean Production and the like, though there is a quick mention of Theory Z and kaizen.

The parts that were more difficult for me to absorb were the “harder (as in, more technical)” subjects such as Accounting, Quantitative Analysis, Finance and Economics. It’s just that little bit too hard to concentrate on those things while on the subway.

The last two chapters are one on Ethics (disappointing, on only 7 pages), and one gathering references for further reading.

What’s in it for me, then?
Well, it is an excellent book for you to learn whether you really want to join an MBA course. But even if you don’t, you will have an idea of what the people that do go there, learn. Which will help, next time you are facing such an animal, be it your boss, or a customer.

This gives the list of the 5627 known certified ScrumMasters.

I see about 35 SMs in France (none from my training session yet). Meaning that, if things go as planned, once we at Valtech are included, we would eventually represent a third of the French total. Not bad, I guess.

Update (22/12/07): the list is now here.

As per Craig Larman’s recommendation, I read Agile Project Management with Scrum before attending Craig’s ScrumMaster certification course.

Overall, I am slightly disappointed. This book does not really help getting the basics of Scrum. Instead, it focuses on providing real-life feedback from projects that Ken has been involved with. Well, that’s all well and good, but I need to know the basics first. And I would add that, in retrospect, Craig’s training session could provide more complete details on that as well.

Anyway, back to Agile PM.
The good:

• short and well-written, an easy read. I feel that I can remember a larger proportion of it than many other books.
• seems honest. It does not hide difficulties with certain projects.

The disappointing:

• unlike Craig’s implication, this is not the best first book to read on Scrum. I think Agile Software Development With Scrum would be better (but I haven’t read it yet), and only then would you get the most from Agile PM.

I’ve just attended a training session on the Scrum method, provided by aforementioned Craig.
The objective of the session was to get a Certification as a ScrumMaster.

Not being on of the most senior consultants, I had to trade 2 days of holidays (we have plenty of those over here anyway). But I dare say that they were well spent. Though I have not received confirmation of whether I did achieve the certification level (not clear how that happens), I am now much better aware of what Agile methods really stand for.

And I mean ’stand for’ literally: in Craig’s words, ‘in Scrum, you have to stand for its values. Even if that means losing your job.’