Sunday, July 30, 2006

"Papa Oscar Sierra do you copy?"

And now to get back to the subject ... ah yes the project

So we are pass our magic date, the 28th of July.

The girl that I introduced 2 weeks ago to the team is very capable and intelligent. She learns fast and is eager to do stuff. Maybe Monday she'll get to accept her first task, she'll still do it in pair with a senior programmer but it'll be her estimate and responsibility, I think that will help her grow.

As I observed and measured the velocity of the project, i.e. the number of Gummi Bears completed each week I reported them back to the executives this value together with the (Gummi Bears left) / (velocity) = projected number of iterations needed to complete. What really amazed me was that the speed, was quite constant and the projected finish date was about the same last week and the first time I reported i.e. a month ago. I just hope that we will actually finish by that date :))). That would be a great proof of effectiveness and accountability of this team and this method for the rest of the company.

The thing that bothers me most right now is that although we will finish, there are possible integration problems on the edges of the other projects, as our project is a part of a bigger whole. Unfortunately I was put to work here too late to be able to pick all the loose ends and tie them together, I had to concentrate on one team and help them to it's best. I guess if I would've tried to do too much at once I would have failed on all the fronts. We're starting to integrate early as possible given the completion state of the other modules, and the other teams' work styles. When we get through all this maybe I'll be given a chance to help the rest of the teams as well.

As for now my motto is:
"We'll never make it out alive"
"Nonsense. You're just saying that because no one ever has."

We had a jolly meeting with the customer's representative. :) That was really fun. Not the type of "ha ha" fun though. It turned out that none (as in "zero") of the executives from our side have shown up (everyone was, on vacation, too busy or else). And the most interesting part of that was that we were the ones to tell him that "we aren't gonna make it". Though I reported that for the first time over a month ago no information was passed to the client. I can't supervise my supervisors (otherwise they wouldn't be my ... you get the point ;) ), but I really thought they would do something else that just sit back and wait. Maybe there was something in that tactic, we just don't get the strategy behind it. Maybe they deliberately kept that news to themselves because the slip was not to severe and they wanted nature to handle those little difficulties, but even then I expected that they would inform us about that strategy and the tactics in use.

Anyway, as we often say in Poland, we had more luck than intellect and on that very meeting the client introduced, the thing that we programmers like the most - changes :). Maybe not so drastic ones as my wall 40cm shorter than planned, but still. So, the customer's representative is willing to play on our side and cover for us, and he'll cover those 2 weeks that we're short of in the time needed to specify and implement those new changes. I don't like that too much, as I prefer openness to covering up, but at this particular moment that was politically the best option to be taken, and so we did. At least at that moment I was convinced by the rest that this was the case. We'll see, and learn.

We encountered one severe problem while trying to unit test a particular system component, a quite basic component that is part of the system's framework. The base line is that it is untestable. Two sets of programmers attacked this problem twice without effect, so we decided to pick the lesser evil that postpone the unit tests, and catch those possible mistakes in the higher planes. We wrote ourselves a User Story saying we need to be able to unit test this component. We'll pick it up when all higher priority stories are complete. Actually we're still thinking on a good name for such a story to be a true User Story, not a Developer Story. I know this is the "internal quality" issue and we should not cut corners here, but I really didn't feel like loosing another day or two just to find that there is no way to do that in the current design. And the refactoring needed to do that is just too expensive right now. Those kinds of things just happen when you get a in touch the Test Driven Development practice with a project that ran without it for the last half a year. I'm not proud of it, but I just didn't know any better way to proceed. I'm really open to suggestions (as in "please enlighten me").

OK there are may matters that I would gladly blog about and I surely will in future entries but as for now it's getting late, too late for me to see, I feel like I'm knocking on the nighty night's door ... hey! hey! hey! hey, yeah!.. knock, knock, knocking on the ...

2 comments:

Anonymous said...

Do you use any software supporting XP process management or team collaboration like XPlanner? Or just e-mail + wiki + MS Project...? ;)

ilfrin said...

Like I blogged earlier, we do use XPlanner BUT it's just for backup, history, analysis and feedback support (charts, metrics, etc). It's also handy for remote the executives to see exactly what we're doing here.

Bottom line is that for our internal purposes (excluding those handy charts and stuff) we very much appreciate the use of physical User Story cards, laying them out on the table, decomposing them and accepting tasks on a whiteboard and having that whiteboard in our workspace for the iteration's duration.

It's really simple and it's really effective, much more than any software tool.

Forget MS Project. Really forget it. It's one of the most illusive tools I've ever seen and used. Use your table, a bunch of cards, a trash can (for torn User Story cards), a pen, and a whiteboard. Visit that whiteboard together everyday at least at the daily standup, and whenever you don't know which direction to proceed.

We use wiki for documentation and persisting common knowledge, and email for notification and some communication tasks, but we prefer immediate and direct communication.