ericlefevre

Some time ago, I was involved (along with much more respected people) in a thread on the XP mailing list where an editor for CIO.com asked about communication tools in the context of an Agile project. I thought my answer was quite balanced, arguing that it was not as good as face-to-face conversation, but still could be useful.

(more…)

At CITCON, I was quite happy to see one person suggest the topic “CI and offshore”, as I am involved on an offshore project myself. Unfortunately, this person didn’t show up, and just we were just 3 in the session.

At any rate, it seems that the same old problems appear with offshore when using Continuous Integration. Basically, the distance is simply too much of a problem when trying to spread the word.

Someone from Nokia did report that he had good success in encouraging people to use CruiseControl and unit tests. But it must be said that he is not part of a particular project, so presumably he has less pressure to deliver immediate results. Though, he did have to travel extensively to get people to use and keep using CC and JUnit.

I’ve left more detailed notes on the CITCON website.

I have older posts on CITCON.

You might remember from a previous post that I was regretting the fact that the development team had not wished to split into feature teams. I even suggested that it should not have been an option to them.
Well, be careful what you wish for, lest it come true. It appears that my words have arrived to the ears of a boss (3 levels above me, 1 level before the top of Valtech), and he diligently demanded that the team be split into these feature teams of graalic proportions.

…not that I have noticed any difference so far. It happened 2 or 3 weeks ago, and I still have a single person to talk to in Scrum meetings, and nobody has identified themselves as part of a particular team.

On our project, there is a total of 21 tech people (plus managers and translators).
3 of us are onshore.
18 offshore.

You would expect this to lead to a natural split into 4 teams, right? 1 onshore, 3 teams of 6 offshore. Or maybe 3 Teams of 7 people, considering that we onshore are officially there for support (and not particularly for implementing features, though we do occasionally). This would nicely fit in the “7 plus or minus 2″ rule, right?

Incredible as it may sound, that is not what happened.
A couple of months after Craig introduced Scrum, I was wondering why there had been no mention of Feature Teams.

As it turns out, Craig *did* explain to them very clearly the benefits of splitting in feature teams. During the Retrospective Meeting, the Team (of 15 people, at the same) took the clear position that they did not want that to happen.

Craig’s opinion on this is that, in Scrum a Team takes its own decision. And if they do not want to follow a rule, then they shouldn’t be forced to.

Is it really so simple? For me, refusing to split in Features Teams is akin to flatly refusing to do Scrum at all. In the literature, I don’t really remember Ken Schwaber mentioning that it was optional, or even strongly recommended. It’s more like: “split the people in Teams, and then get them to choose tasks from the backlog”.

Now, I agree that once the team has decided *not* to split, then it is probably already too late. But why give them a choice at all? There are many other things they had no choice about, starting with using Scrum. I am convinced that, if they had been made to split in Teams, then they would have happily followed along without thinking twice about it.

Last week, I attended a 3-hour session on wine. It wasn’t just wine tasting; the guy (only gave his first name, Alexis) also gave plenty of details on how wine is produced, etc.

He also explained the differences between wine-making in Europe (in general) with wine-making
in the New World (US, Latin America, South Africa, Australia, etc.). For him, it’s actually a philosophical difference.

• In the New World, wine-makers are artists (almost) that consider that they can (and do) produce any kind of wine from any kind of soil. Preferably the kind that sells.
• In Europe, from the concept of terroir derived the idea that the wine-maker should play by the strength of his environment and attempt to magnify the characteristics that are naturally present. If it doesn’t sell, well, too bad (I’m exaggerating a bit, here, of course).

Both attitudes have, of course, their own merits.

What does it have to do with software project management, you ask?

Well, here the idea (slightly far-fetched, I agree). Suppose that you are working in a multi-cultural project. Not with many different people in the same team, but rather with different teams in different countries. For example, our offshore colleagues are certainly more disciplined than we are (agreeing to work on Saturdays, for example); on the other hand, they are much less able to work without external help.

So, should one work with their strengths, or despite their weaknesses? A complex question that I will not try to answer in this column.

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.

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…

I have been involved in an offshore project for Manpower for more than 6 months.
Well, we have recently learned that Craig Larman was going to coach it and lean more towards Agile methods. Craig is Chief Scientist with my employer and author of various books in our industry. He is going to spend 6 months in Bangalore, starting from early April 2006. He will be involved in 3 projects in total.

I am all for Agile methods, of course, and I think they are the greatest thing since slice bread.
That said, we are already under great pressure (especially as the deadline is considered fixed by my management; keeping to deadlines in not the focus of Agile methods). Also, one can wonder to what the cultural clashes this will lead to with our colleagues in Bangalore.

It will be interesting for me to watch.

I made it back from Bangalore yesterday. The journey back was not as bad as the journey in (where we were re-rerouted to Bombay, with a connecting flight to Bangalore), but we did have a 5-hour delay before taking off because of bad weather.

I’m happy to report that the team in Bangalore has made a lot of progress and can be considered as experienced enough now. The project has now much better odds of succeeding.

I think spending quality time with individual developers, basically pair programming, was what made the difference. It allowed us to commit near-perfect code to CVS, which allowed to boost confidence for some developers. It is so rewarding to see someone who was struggling 3 months ago now spontaneously undertaking new tasks and refactoring other parts.

Arrived in Bangalore this morning.
I had done my best to take the direct flight from Paris, but we got overbooked, so we had to change to another flight going to Bombay. Let’s just say that it did NOT go very well. Eventually, we arrived around 8am in the hotel (as opposed to 2.30am, as planned before).

Just had a sip of the prepared tea in the cafeteria (mostly milk, little or not water, strong taste). Still as good as ever, though my fellow Indian developers insist that it is barely average.

Just came back from visiting the development team in India. My employer now has more than 400 people working in the Bangalore office.

Other views of the city.