"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 ...

"How not to get bored" or "XP is about social change"

Sorry again, I promised I'll write and I didn't, my only excuse is that the people that are finishing off you apartment also didn't make it on time, and as for the moment the sky gently but steadily lowers itself towards my head. Next weekend I'm supposed to move, this weekend I was supposed to paint the walls etc, but I can't because other work is not finished yet.

To summarize, when you feel a bit bored, or you feel your life is too predictable, or feel otherwise odd please do yourself a favour and buy a new unfinished apartment and then set a firm unmovable date by which you have to move to that place. Then 3 weeks before that deadline have your wife buy a new dog, and then have a team of "talented"(past tense as in "maybe there were times when they were talented") pros start working to finish this apartment. Don't forget to fasten your seat belt and hold on tight (and be sure to take your heart pills) ...

It that's not enough please try this:
Measure the place for your new kitchen, put the numbers all over the blueprints, but many more numbers there, measure every detail and put the numbers as close together as possible. Then after a week cursorily read that blueprint, put it aside, never look at it again and then carefully design your kitchen. Go to IKEA, buy that damn kitchen, bring it over, unpack, put the LEGO parts together, and have your friend carpenter come have your kitchen put in place. Then at the beginning of a brand new week, when you stand with him and explain where you wish which part to be realize that one of the walls doesn't have 355cm but 315. Remember the blueprint part of this exercise is the key part, otherwise you'll find your mistake soon enough to change the plans in the planning phase.
Unfortunately this is not a software project, and kitchen parts are not Java classes. Unfortunately in the real physical world it's not easy to apply such changes. But feat not!. Life shows that even then if you have a master carpenter at your side he'll find a way to seamlessly shirk a few parts here and there and after a few hours of looking at your life passing before your eyes you see a bright light that illuminates your brand new kitchen.

So actually this is a case study of an agile technique put to use in the real world that seemed very BDUF-like :). My friend, if he wasn't my friend, could say: "Hey dude, get lost! I have better things to do than to cover for your mistakes, call me when you have all the parts fit the plans". But he didn't say that. Instead he said "OK, so let's see what we have here, this part has 50cm not 60, we can shrink that other part another 20cm, and the one over there we can also rebuild a little".

So all you agile non-believers this is hard evidence that this kind of work style actually works, the key thing is the state of mind and the attitude. "XP is about social change".

"Is there anybody out there?"

Fortunately there is :) Thank you Johanna! (see comment to my previous entry)

I have had some major disruptions lately both at work and at home. A few interesting projects are emerging, and I'm moving to a new apartment in 2 weeks so e.g. today our kitchen was put together :)

I promise tomorrow evening I'll blog an extensive update on what has happened in the project since last time.

Thanks again for keeping me blogging, it's easier when I know it's not just for myself :)

What a weekend ;)

Wow, I have to go to sleep, but before I do that I have to report. So the last iteration ended a day earlier because Friday we all taken by the company for a integration party in the country. We integrated with another company that does a system we have to interface with. It was really cool :), the lake's water had 25*C, it was a really pleasant swim.

Then I came back Saturday evening with a little hangover, and Sunday I had to drive my wife 1100km so she could buy a dog. That was really crazy, I vaguely remember anything from this trip, although I was the driver ;)). The puppy is really cute and adorable ;)). It's a samoyed, for now a white and fluffy snowball. The dog is intended to be trained by my wife and then used for children's AA (Animal Assisted) Therapy. She's a really great woman.

Anyway Today morning, after the third night barely touching the pillow I went to work. To tell you the truth we did really well last week. Although we lost one day, we still managed to keep up the speed and maintain 15 Gummi Bears. That leaves us in a steady 2 week overdue with the project, but at least that's something I can be fairly certain. The project peers got the message today, and my head didn't fall yet, so I guess they do feel OK about it.

Today was also a very important day as a lady joined our team, a student from the local university. She's really smart and in spite of being without any professional experience I foresee she'll be a valuable asset to our development team. The first sign of that was that the fact of her coming forced us to move today to a bigger room down the hall, so now we have more space and the air is not so ... intense anymore ;).

Anyway as I said, I ought to go to sleep,
bye for now!

It's hot!

Oh, my! It's hot! A friend told me that he heard on the news that Warsaw just below Cairo on the list hottest cities this day. Good grief, why did it come to that, if I wanted such temperatures I would gladly do to Cairo in person. It didn't have to come to me instead...

Well, anyway yesterday we did manage to have our Planning Game, it went well, in about 2hrs we were up and running. Interesting though that I still have to ask questions like:
- is this decomposition of this User Story complete?
- Think, if you do all those tasks will it be all?
- In your estimates do you account for test-driving the code and possibly writing some mocks on the way?
As I ask those questions I see that they do add new tasks or change estimates after giving if a thought. Maybe there always needs to be someone to remind that, maybe, I just thought I wouldn't have to constantly keep reminding that.

I updated the executives this new estimates, we'll see where will that bring us ;))

After an hour of work in this tropical climate, two of the programmers said they're going home to work there and at least have a shower every two hours. There was no way to stop them, and I don't blame them. There is no way to get air-conditioning because the building is quite old and it's electrical system is too weak for that. There are no showers. I just hope temperatures will fall soon, if not then we'll have to look for an other office, as the project may b in serious jeopardy. The rest, including me, stayed as home we wouldn't be any more productive home, although we would feel better we'd have our wives and children all over us ;)

See ya soon, if the temperatures wont kill me...

Velocity goes up

And today we ended the third iteration. I was happy to record 15 Gummi Bears done this time, that compared to 9 last time, and 15 the first time is a good sign. I'll post this information to the executives on Monday directly after our Planning Game

What we noted was that 30% of programming time was done in pairs, I think of it as a good thing, and hope that it'll increase. We also found that all the cards from this iteration were underestimated. Some even by 100%. Lesson learned, hope to do better last time. All those numbers I took from XPlanner and that's one of the good things about this tool, it's simple and gives such numbers on demand, e.g. at the retrospective to see and comment for all.

One more thing that we talked about was a new member of the team. I talked a few days ago with a student of the Warsaw University, and she made a very good impression on me, disputing with me about various subjects. The woman has potential, we'll see how she'll fit the team. I asked them if they have nothing against her joining us, what they think about this idea, as I would like to pair her with somebody. At first she'll of course be just learning as the has none professional experiences and we're thight on schedule, but as I said, she seems bright enough to catch up and commit to the project soon. Anyway the team reacted positively and said to give her a try. And that's what we'll do. I'll call her tomorrow. It was important to me to talk to them first not just put her there, for the team to feel as one, and so be sure that it wont be a problem for anybody. Fortunately everybody was thumbs up.

They do listen!

I had a talk with one of the executives yesterday, I told him about my concern about the information I push to them, if anyone listens to it. To my surprise he said "yes" we (meaning other executives) are very happy to see those numbers and listen to that carefully. I don't see any business moves that they do, but then again that's non of my concern as long as they listen and understand what I say about the project, and it's status.

The estimates' update: not so shiny after all

At the daily standup we found that one card that was estimated for an hour or so took two days' work of a pair!. Well shit happens but thing had to be done, so we've shed a tear and moved on. Anyway our velocity isn't gonna be what I expected, too bad. As the last weeks velocity dropped from 15 to 9, I hove to stay at least at this level. This places us having 6 more one-week iterations to come, and the magical date is in 3 weeks. I can't do anything about it. Or can I? What I did was communicated that to the executives and managers loud and clear, I have no idea what they're going to do about it. I hope they're not blind.

I have to speed up my actions and publish the projected project path every Monday, not Wednesday or Thursday. It's 2-3 days lost!

The Matter Resistance: mocks and attitude

All progress is done in the light of resistance. Without it you don't have a real chance to refine your thoughts and check if what you believe is really something that you can trust. The discussions as long as they don't get personal and long as they don't become monologues are very constructive as you may find holes in your ways and only then you have a chance to spot them and in effect progress.

So yesterday I did have a chance for that in two areas.

First I discovered that I favor static mocks over dynamic too much. It started when a colleague asked whether or not he uses mocks correctly, because he found that changing some system behavior he has to change the dynamic mocks he uses as they are still set to the old way and the test fail. I said that it's perfectly normal and he should change them as well. Then he's shown me how he uses those dynamic mocks (dynamic proxies), and I said that in most of these cases I would use a static mock (a null implementation), and we talked a little more.
The conclusion was that there isn't a hard line which separates the use of static versus dynamic mocks, but more importantly I found that I got too friendly with the static ones, as e.g. it is a good thing that his tests didn't pass as it's a empirical proof that those tests really do test something, and that has built more trust in us. And that's good.
I found that the use of static mocks in such a case might have not cached the change and we wouldn't get that valuable piece of feedback, but what struck me was that a dynamic mock has a greater chance to uncover a badly written test (or mock), because you set specific expectations and not just a dummy null implementation that does not verify how it's been used. I certainly have to pay more attention to that and make more use of them.
But then my further remark was that on the other end the extensive usage of dynamic mocks may uncover, cause, or sanction tight coupling and an unclear architecture, so you have to stay alert and primarily use your head then mocks :).

The second thing was a chat with the leading programmer, he also plays a role of a customer proxy. He was the one to earlier refuse to work on some subject for now, as he has a different view on how do implement something from the rest of the team. He told me that although he sees that those things I've brought to the team are good and helpful he does not identify with them. He said he will not cause any trouble and will cooperate, but personally this is not a way he wishes to work, he has a long (10+ years) history of software and hardware development and he likes to work alone or with his partner who grasps everything just like him. Additionally he says that all the planning, story cards and stuff he has in his head and that suffices if he and his partner are the only one on the team. He says he has a history of happy customers that loved the products he gave them, done quite internally with little in-process feedback from the customer, and those programs are till today flawless.
Well what could I say to that? I said: "Well, let me treat that as one of the wonders of nature. I'm happy for you, but too many times I saw just the opposite to fall for that." What was I supposed to say? :)
We had an open talk so we assured each other that all your disputes are not personal and stay professional, so that we progress as a whole. Again he added that this is very interesting for him to realize that this style of work as advocated by XP is very useful and valid but it is not the style he wishes to practice in the future and maybe that's a sign for him to change some things in his professional life.
I'll never give up trying to convince him to those values but I know I'll have a hard time doing that. Nevertheless it was a healthy discussion and I hope it has set our attitudes towards each other in the right direction.

First pair programming experiences

Yesterday we started with a usual Monday Planning Game for this week, it took us approx. 2 hours, so I figure we're getting better at it.

We carried on the stories unfinished in the previous Iteration, and allocated a bit more than last week, but less than the first week, we'll see how that turns out.

Yesterday I encouraged the team to pair a little, so two of the programmers worked on separate things, and another two paired (a junior and a senior). They obviously did seem to take much fun out of it, I personally hope to have raised their productivity.

The people sat together at one laptop (I know it isn't how it's supposed to be, but I'll deal with that later) and so after watching them for a few minutes I told the other guy to bring his keyboard and mouse and plug it in, so they both were able to easily type and move around.

I have my personal doubts about Pair Programming to go over, and fears to diminish. I am quite sure that PP should be used a lot, I not sure how much, pairing for 100% of the coding time does not make sense to me. 50%, 70%, but 100%? There are many simple tasks that no matter how much heads you put together it isn't gonna make it nor faster nor better. I know the arguments, I just have that gut feeling (fear?) and some mixed experiences with that on previous teams that lead me to this conclusion. Though I'd be very happy to discover otherwise. E.g. I never got close to achieving the 15% overhead of PP as measured by Alistair Cockburn, I have some thoughts on why that might've happened to me but that doesn't change the fact.

First problems

Today we had our second Retrospective and the end of the second Iteration. Also today is the day we encountered our first problems. I feared everything was going so smooth, so I'm relieved to find that everything's quite normal.

The first problem is we underestimated two of the stories we committed to, and thus didn't complete as much as we wanted to. The raw velocity for this Iteration was 9 Gummi Bears, considering the half done stories about 13, but I know we have to stick to those 9 as only those stories were fully closed.

We also discovered that the task decomposition of one of the stories was overly bad, there was no way to implement it according to the tasks, the tasks should be aligned rather orthogonally to how we decomposed the story on Monday.

The second problem was (and still is) of a different nature. Yesterday one of the developers agreed to work with another one on a certain story. Today he found that his way of implementing this and similar stories is very different from the way proposed by the person who took responsibility for the story. I told them to have a positive discussion on that subject, so they did for almost an hour, then we brought the subject to the team's forum, so we collectively decided that the original idea was better. So that person said "OK, I'm sure this will not work (although he wasn't able to convince us). Do it the way you want to do it, but please, for the sake of the deadline we have in a few weeks, please keep me out of the implementation details of this story. After this deadline I'll be more than happy to learn that and maintain that part of the system (although I know it'll be a disaster), but for the time please take that responsibility and leave me out of it."

At first that scared me. Then again I said something like: "well OK, maybe it's a good thing, we'll pair you with other people so that everyone's comfortable, and we'll see after this deadline how things work out."

I really didn't know what to do. I knew that he was a very valuable asset in that area, and he could have helped a lot because no one understands this business as well as him. But then again I don't want him to feel brutally forced and pinned down to doing something that makes him sick. Out of two evils I figured that the latter is worse, as it could cause a lot of collateral damage if this person really feels that way towards this idea.

I dunno if I made the right choice, we'll have to wait, observe and learn from that. Maybe one reason for that in the first place was his absence on the Planning Game on Monday, but I'm not sure his presence would've prevented it.

We had a longer retrospective than originally planned but we needed to say things, I hope they were true. We agreed that we don't take those arguments and quarrels personally, and we don't stop to like each other, we just happen to have different opinions on many technical problems. Personally I think that diversity is a plus for the team, as long as it doesn't tear the team apart, which apparently didn't happen (yet).

Anyway, my wife and I are going to visit our parents for the weekend, so I hope to rest a bit for the next Planning Game on Monday starting another adventurous Iteration. So stay tuned...