There was a comment (by Pawel) to my last post that included a series of questions. I decided to pick them up and answer them in the open, so maybe they'll inspire you people to discuss this further.
1. How many users you expect to use the software you've been recently developing?
It is supposed to be deployed and used simultaneously at over 3 thousand locations.
2. Do you develop web software or desktop software?
This project is desktop software, but a previous one and one coming up is a webapp so generally this is irrelevant.
3.1. How do you test?
We have automated test suites. Well OK, we are aiming for those, close to the truth is: we are growing our test suites, automated of course.
The customer also does manual acceptance testing of his own, but that's his free will. As I wrote I came to the project late so it is not fully covered by both unit level nor acceptance level tests, but we have them exercised all the time. People are running unit tests locally as part of the Test Driven Development method. Of course they're supposed to be run automagically on the integration machine as well.
3.2. Do you have testers?
Not quite. There was no tester on the team. It's a small team, now having 3 full time developers and 2 half-time. Some time ago I asked one of the half-time developers to get to know FitNesse and now she's our acceptance test guru, so yes she may be thought of as a tester, but I wouldn't call her that. To my knowledge she's more a developer in the role of a tester. A full blown tester has more testing-specific knowledge than she does at this point. But she's getting there.
She's now in the process of educating the rest of the team about writing automated acceptance test, and will be the person to aid them later.
3.3. And how do you mimic production environment?
The integration machine is a production class unit. How did we make it production-like? Well we just did, I don't get the question. I think there is no generic answer to this, every project is specific in this matter so please tell me about your problem.
4. Do you deploy bit by bit to production so users can use the bit of software you finished and tested and give you some feedback?
Well not quite ;), The relationship with the customer was formed and agreed to a long time ago so I wasn't able to change that, so he's not on-site. We rather integrate the modules after each increment and our internal customer (customer proxy) does the checking. The real customer has longer response times and testing cycle than we require to keep on moving. But as for now it works well (I know it's a risk but we're handling it well for now).
5. When do you fix bugs?
Depends what severity and size. Severe bugs we fix on the double. Minor bugs we schedule according to importance like regular features during the weekly planning game.
6. Do you build software every day/night?
No need for that, this is also project specific. The build takes a few minutes, it's a small team, luntbiuld (or cruisecontrol) does the job of checking our VCS regularly (or at least it should, up until now we had this manual - don't ask me why) and building the project when changes were detected.
7. Do you babysit software you finished providing bug fixes, technical support and deploying new releases when needed?
Yes, depending on the agreement with the customer but in the vast majority the customer buys also maintenance support and/or has new feature ideas. Mainly it's because we need to babysit this software we go to all the lengths to have all those tests in place. It brings the maintenance costs down very quickly.
Monday, December 11, 2006
Tuesday, October 31, 2006
Still alive
Well I'm not dead as one might think (or hope), not yet at least. It isn't that easy to kill the beast. I haven't been posting anything lately because I've been away for a while (eg. at ENASE'06: Advocatus Diaboli Walk Through eXtreme Programming), furthermore there is a lot of integration work going on in the project now as a pilot deployment is being set up, so things are going well and forward. At least a few of us think so ;).
Next few months I will probably start a new project from the beginning for one of our old customers. We'll try the agile way of course, so you'll again be able to track what's going on. Next Tuesday we're having a planning game to see how big the picture is and to be able to formulate a legal agreement based on that.
About the current project I'll just say that now I'm devoting most of my time to one of it's components. My initial mission was to ensure that it will make the launch date and not explode. Now that this is secured I'm looking for ways to improve this components architecture, mainly the low-level (code style, object reuse, etc) architecture. There are two well skilled people working on that project, so the work is going quite well.
See you soon.
Next few months I will probably start a new project from the beginning for one of our old customers. We'll try the agile way of course, so you'll again be able to track what's going on. Next Tuesday we're having a planning game to see how big the picture is and to be able to formulate a legal agreement based on that.
About the current project I'll just say that now I'm devoting most of my time to one of it's components. My initial mission was to ensure that it will make the launch date and not explode. Now that this is secured I'm looking for ways to improve this components architecture, mainly the low-level (code style, object reuse, etc) architecture. There are two well skilled people working on that project, so the work is going quite well.
See you soon.
Tuesday, August 08, 2006
Last iteration (or is it?)
Again I apologize for not posting any new entries. The day of moving to our new home gets closer and closer (hopefully this weekend) and so every afternoon til late in the night I work hard to make it prettier ;).
At the project site we have just completed iteration 7, one story slipped to iteration 8, which started Monday. The project velocity dropped from 13/14 Gummi Bears to about 12 Gummi Bears, that is because more and more time we work trying to integrate our front-end system with the back-office system which is developed by an other team.
Nevertheless we just started our hopefully last iteration, though we packed it with 13 Gummi Bears we hope to finalize it. So that's really good, Friday is the date that I foretold 7 weeks ago :D based on one iteration's progress. Cool. Much luck I guess, ehh, hell with that, we're simple grrrreat! :D
The sad part is that this is not the end, the system is a part of a whole, and now we have to integrate it with an other part of the system, we developed the front-end and there is a back-end being finished as we speak that has to work with our front-end. We know the team, we like each other and are in contact, but the development method was different and we didn't plan things together. We started integrating a few weeks ago, little by little, that's why the velocity dropped a bit. Things are not that bad, minor changes and tweaks were til now sufficient so we hope (yeah, that's all we've got-hope) things will work out in a matter of a week or so.
I'm not too happy with that integration going on as a side topic, I know that according to XP, we should integrate every Friday. But that's as far as I was able to go given the time I had, the progress the project had, and the pressure there was. If I had the time and opportunity I would gladly bring those techniques to the other team, schedule even iterations, and have integrations in every iteration.
There is more work to be done, the feature list is not exhausted yet, these were just the primary-value features. So I hope I will get a chance to push the development process a bit further down this road.
As for now, next Monday I plan to have a planning game that will discover all the integration tasks that have to be done, so we can schedule then and track as we did with normal feature tasks. After all it's one of the customer wishes that the system is integrated as a whole, so I imagine a User Story: "The system parts are integrated and it doesn't fall apart when used." :D LOL.
Oh and our Mrs accepted her first tasks for the former and present iteration! Overestimated them by 100%. Sweet :). Brave young woman. :) She's doing a really good job.
One thing I think we have to do better is the retrospective. It's Friday afternoon, everybody wants to go home, and it's really hard to concentrate on reflecting. Coincidentally today I read a chapter from Testing Extreme Programming by Lisa Crispin et al. It was about retrospectives, how to handle them. She gave ideas and examples of how to use this idea brought by Martin Fowler in 2001.
I think I'll try to use the iteration grade card she provided. It's just a list of iteration activities and the team assigns grades to them, so we all know what we need to improve.
The original Martin's three questions list (what to start, stop, continue doing) also looks appealing, I'll think things through and hope to use something this Friday.
So stay tuned for more "of the battlefield" reports.
At the project site we have just completed iteration 7, one story slipped to iteration 8, which started Monday. The project velocity dropped from 13/14 Gummi Bears to about 12 Gummi Bears, that is because more and more time we work trying to integrate our front-end system with the back-office system which is developed by an other team.
Nevertheless we just started our hopefully last iteration, though we packed it with 13 Gummi Bears we hope to finalize it. So that's really good, Friday is the date that I foretold 7 weeks ago :D based on one iteration's progress. Cool. Much luck I guess, ehh, hell with that, we're simple grrrreat! :D
The sad part is that this is not the end, the system is a part of a whole, and now we have to integrate it with an other part of the system, we developed the front-end and there is a back-end being finished as we speak that has to work with our front-end. We know the team, we like each other and are in contact, but the development method was different and we didn't plan things together. We started integrating a few weeks ago, little by little, that's why the velocity dropped a bit. Things are not that bad, minor changes and tweaks were til now sufficient so we hope (yeah, that's all we've got-hope) things will work out in a matter of a week or so.
I'm not too happy with that integration going on as a side topic, I know that according to XP, we should integrate every Friday. But that's as far as I was able to go given the time I had, the progress the project had, and the pressure there was. If I had the time and opportunity I would gladly bring those techniques to the other team, schedule even iterations, and have integrations in every iteration.
There is more work to be done, the feature list is not exhausted yet, these were just the primary-value features. So I hope I will get a chance to push the development process a bit further down this road.
As for now, next Monday I plan to have a planning game that will discover all the integration tasks that have to be done, so we can schedule then and track as we did with normal feature tasks. After all it's one of the customer wishes that the system is integrated as a whole, so I imagine a User Story: "The system parts are integrated and it doesn't fall apart when used." :D LOL.
Oh and our Mrs accepted her first tasks for the former and present iteration! Overestimated them by 100%. Sweet :). Brave young woman. :) She's doing a really good job.
One thing I think we have to do better is the retrospective. It's Friday afternoon, everybody wants to go home, and it's really hard to concentrate on reflecting. Coincidentally today I read a chapter from Testing Extreme Programming by Lisa Crispin et al. It was about retrospectives, how to handle them. She gave ideas and examples of how to use this idea brought by Martin Fowler in 2001.
I think I'll try to use the iteration grade card she provided. It's just a list of iteration activities and the team assigns grades to them, so we all know what we need to improve.
The original Martin's three questions list (what to start, stop, continue doing) also looks appealing, I'll think things through and hope to use something this Friday.
So stay tuned for more "of the battlefield" reports.
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 ...
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 ...
Saturday, July 29, 2006
"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".
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".
Thursday, July 27, 2006
"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 :)
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 :)
Monday, July 17, 2006
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!
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!
Tuesday, July 11, 2006
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...
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...
Saturday, July 08, 2006
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.
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.
Thursday, July 06, 2006
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!
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.
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.
Tuesday, July 04, 2006
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.
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.
Saturday, July 01, 2006
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...
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...
Friday, June 30, 2006
Talking to executives
After measuring the velocity of the first iteration I summed up the Gummi Bears of all the rest of the stories to come up with a first impression of the number of iterations needed to complete those stories.
So Tuesday I felt brave and waltzed into by boss's office with good news and bad news. :). The good news were it's not as bad as it might have been, and to say the truth, not as bad as I suspected. The bad news was we are one iteration short for now, as I said in my previous blog entry.
His reaction was like: "OK", which scared me because I didn't know what it really meant. As I talked to him more we came to a conclusion that we have to observe at least one more Iteration.
I think things may speed up in some degree, because one of the programmers is now 3 days a week, and is willing to be full-time in the summer. Additionally I hope to finish other external things and also start committing to development tasks. I'd really like that.
We also agreed that every week I will publish project status and prognosis to all the managers engaged in this project. I did that yesterday. I also gave them access to XPlanner to see for themselves (those that are in a distant location) how the project progresses (or not).
I'm curious how they'll react.
So Tuesday I felt brave and waltzed into by boss's office with good news and bad news. :). The good news were it's not as bad as it might have been, and to say the truth, not as bad as I suspected. The bad news was we are one iteration short for now, as I said in my previous blog entry.
His reaction was like: "OK", which scared me because I didn't know what it really meant. As I talked to him more we came to a conclusion that we have to observe at least one more Iteration.
I think things may speed up in some degree, because one of the programmers is now 3 days a week, and is willing to be full-time in the summer. Additionally I hope to finish other external things and also start committing to development tasks. I'd really like that.
We also agreed that every week I will publish project status and prognosis to all the managers engaged in this project. I did that yesterday. I also gave them access to XPlanner to see for themselves (those that are in a distant location) how the project progresses (or not).
I'm curious how they'll react.
Tuesday, June 27, 2006
Day Six: another week, another iteration
This week's Planning Game went really smooth. We picked cards that summed up the previously measured velocity and decomposed them into tasks. We were done in about an hour. That was cool.
One negative thing was that I realized that there were 3 tasks that were not closed in the previous Iteration. They all were accepted by one person, who promised to do it over weekend. So that's a lesson learned not to believe that anymore :).
One very positive and fun thing: the same person brought a toy his wife bought him on her recent visit to Las Vegas. It's a big round button about 15cm in diameter that when pressed says: "that was easy" :D. So now we have a rule in place that after each task, the acceptor has the right to come to this button and press it once, or twice if the task was really hard :).
I also lined up the cards, and giving current velocity I noticed that we will probably be one week short of time. We need 5 iterations to finish and there are 4 weeks left from the original schedule. I'm really surprised though, I thought that it would be much worse. I have to go to my boss and talk to him about that, we'll see what options we have.
Tomorrow I'm of to the other company so you'll hear from me in a few days, or tomorrow if the chat with my boss will be interesting enough.
One negative thing was that I realized that there were 3 tasks that were not closed in the previous Iteration. They all were accepted by one person, who promised to do it over weekend. So that's a lesson learned not to believe that anymore :).
One very positive and fun thing: the same person brought a toy his wife bought him on her recent visit to Las Vegas. It's a big round button about 15cm in diameter that when pressed says: "that was easy" :D. So now we have a rule in place that after each task, the acceptor has the right to come to this button and press it once, or twice if the task was really hard :).
I also lined up the cards, and giving current velocity I noticed that we will probably be one week short of time. We need 5 iterations to finish and there are 4 weeks left from the original schedule. I'm really surprised though, I thought that it would be much worse. I have to go to my boss and talk to him about that, we'll see what options we have.
Tomorrow I'm of to the other company so you'll hear from me in a few days, or tomorrow if the chat with my boss will be interesting enough.
Saturday, June 24, 2006
Day Five: first retrospective
Today we ended our first iteration. We were all surprised to find out that our speed was better than we expected, because we had to pull an additional 3 Gummi Bear User Story to have enough things to do. As we talked during the retrospective the team was very happy with the development process, especially with the User Story cards, decomposition to tasks and developers signing up for them. That really suites them.
What they found difficult was some of the Story dependencies, they asked for a way to mark them. I asked them to track dependencies without special demarcation for now, just as common sense, and when it becomes a problem then we'll address it, but for now I convinced them to try without it. I believe more constraints and attributes will slow things down rather than help us. We'll see.
I didn't close the Iteration formally yet (in XPlanner), as one of the guys said that he will commit an hour or two tomorrow to close one of the almost done Stories. I know I shouldn't let him do that, but he was very eager to do that and I cracked.
Monday we start the second Iteration, but we'll have to have out Planning Game without one of the development leader, as he has been asked somewhere else and he can't be there on Monday. I decided that we can't hold back and will do the Game ourselves choosing Stories that we feel comfortable with. I think that's better that putting the whole team on hold for a day and messing up the whole Iteration because of that.
Tuesday I promised my boos to update him on the project status, I'll analyze the project speed, and summarize the Stories to have a feeling of what's ahead of us. This will be the day of terror I feel. Though I hope not. Please don't shoot the messenger.
Sorry for the poor text today but I had a few beers with my brother-in-law and it's 3AM and tomorrow early morning (9AM) I have to drive something like 250km ... ;)
What they found difficult was some of the Story dependencies, they asked for a way to mark them. I asked them to track dependencies without special demarcation for now, just as common sense, and when it becomes a problem then we'll address it, but for now I convinced them to try without it. I believe more constraints and attributes will slow things down rather than help us. We'll see.
I didn't close the Iteration formally yet (in XPlanner), as one of the guys said that he will commit an hour or two tomorrow to close one of the almost done Stories. I know I shouldn't let him do that, but he was very eager to do that and I cracked.
Monday we start the second Iteration, but we'll have to have out Planning Game without one of the development leader, as he has been asked somewhere else and he can't be there on Monday. I decided that we can't hold back and will do the Game ourselves choosing Stories that we feel comfortable with. I think that's better that putting the whole team on hold for a day and messing up the whole Iteration because of that.
Tuesday I promised my boos to update him on the project status, I'll analyze the project speed, and summarize the Stories to have a feeling of what's ahead of us. This will be the day of terror I feel. Though I hope not. Please don't shoot the messenger.
Sorry for the poor text today but I had a few beers with my brother-in-law and it's 3AM and tomorrow early morning (9AM) I have to drive something like 250km ... ;)
Tuesday, June 20, 2006
Day Four: rollin', rollin', rollin'...
Today I had more luck with the trams and arrived to work around 9 AM, finally. We waited for the whole team to show up and eventually around 10:30 we did the Stand-Up Meeting. To tell you the truth I was afraid people will start laughing when I tell them to stand up and gather in the middle of the room. They surprised me again and did take it quite seriously.
I asked everyone to say in a few words what are his plans for this day, which tasks will he fight with today, and whether or not he the would like someone's help on the way. Everybody contributed, and we were done in 5-7 minutes. Then we started normal work or rather got back to it, as most of the team was there from 9 AM.
It has to be noted that we do not use regular pair programming. I know, I know, bad boys. The team does however talk everything through with each other over the desk, so it isn't that bad. From time to time they do get together to do something really serious, or when someone doesn't know something, but that's quite normal behaviour. Maybe in the future if I gain more courage I will come forward with that, but for now I leave it be. Fist I have to observe and see to it that other fragile project mechanisms work properly.
Yell at me, please. ;) (I'm open for discussion, I have some twisted rationale behind that, some of my own, some overheard from the team)
Anyway, the day was a good one, I jumped from person to person helping out mainly in writing unit tests. The architecture is not as loosely coupled as one might like, so there are some quirks to go with. That said I have to admit that it not bad at all. There is just room for improvement. As always :). We have to cope with that for the time being, when the time comes I hope to refactor it to something more pleasant.
In the meantime of that I got back to organizing the build system, trying to tweak Maven2 to do the things that are needed. Damn, there is a lot of documentation out there, but it barely scratches the surface. Doing some really custom while using as much of Maven's default functionality as possible is not so pleasant as the adds may say. Anyway by the time I had the things figured out and thought through it was 5PM and it was time to go home ;).
Tomorrow and the day after I have to be at another project site, so I assigned my colleague to be the guardian of the morning Stand-Ups, and other behaviour and practices. I hope they'll live, oh I'm sure they'll do just fine.
So until Friday!, maybe I'll think of something earlier and come back here, if not then Friday for sure I'll report the next portion of this rescue attempt.
I asked everyone to say in a few words what are his plans for this day, which tasks will he fight with today, and whether or not he the would like someone's help on the way. Everybody contributed, and we were done in 5-7 minutes. Then we started normal work or rather got back to it, as most of the team was there from 9 AM.
It has to be noted that we do not use regular pair programming. I know, I know, bad boys. The team does however talk everything through with each other over the desk, so it isn't that bad. From time to time they do get together to do something really serious, or when someone doesn't know something, but that's quite normal behaviour. Maybe in the future if I gain more courage I will come forward with that, but for now I leave it be. Fist I have to observe and see to it that other fragile project mechanisms work properly.
Yell at me, please. ;) (I'm open for discussion, I have some twisted rationale behind that, some of my own, some overheard from the team)
Anyway, the day was a good one, I jumped from person to person helping out mainly in writing unit tests. The architecture is not as loosely coupled as one might like, so there are some quirks to go with. That said I have to admit that it not bad at all. There is just room for improvement. As always :). We have to cope with that for the time being, when the time comes I hope to refactor it to something more pleasant.
In the meantime of that I got back to organizing the build system, trying to tweak Maven2 to do the things that are needed. Damn, there is a lot of documentation out there, but it barely scratches the surface. Doing some really custom while using as much of Maven's default functionality as possible is not so pleasant as the adds may say. Anyway by the time I had the things figured out and thought through it was 5PM and it was time to go home ;).
Tomorrow and the day after I have to be at another project site, so I assigned my colleague to be the guardian of the morning Stand-Ups, and other behaviour and practices. I hope they'll live, oh I'm sure they'll do just fine.
So until Friday!, maybe I'll think of something earlier and come back here, if not then Friday for sure I'll report the next portion of this rescue attempt.
Monday, June 19, 2006
Day Three: the first Iteration begins
So I promised every day I spent on site will be documented here, and so it is. Today we have had the project's first Iteration Planning Game, sad that it's almost a year from the project initiation, but better late than never, or so they say...
Anyway I was late because there was a tram traffic jam, chances are it'll happen like 1:100, but of course I hit the 1, too bad I don't play the lottery, so we started around 10:00.
I read out loud all the 50+ cards that we created last time. We decided which group of them is not blocked by any external constraints (like other teams doing something) and chose a few most important based upon business value, as we (as in "the team") said we have a very good understanding of that. Of course the whole course of my actions is to get the machine running and then mount some test environment that the client may see and give feedback. But one thing at a time. This style of adopting XP is somewhere between cannonball and steadily waltzing into the pool, as things happen quite fast (we're almost out of time) but not all at once.
We then begun decomposing those User Stories into technical tasks on a big whiteboard. Every task was then estimated and taken by an individual. I watched carefully that the people who take them feel confident in how to implement them.
Surprisingly in the battle of decomposition we discovered that two of the stories need to have a more general ancestor that will create a foundation for those two to be done. So we created another Story dividing parts of functionality and responsibilities of those former two. We then tried to decompose the new story into tasks, but we found ourselves unable to divide the main task that was 20h long (a lot compared to others), we didn't know how to divide it. It was a clear sign that we really don't know how to do it, so we can't decompose it nor estimate it. We then decided to postpone this Story till the next Planning Game, and instead scheduled a 2 Gummi Bear long spike solution to be done in this field. I think those decisions were the real highlights of this Planning Game's.
I have to admit, that in the midst of the struggle I almost forgot about the basic principles, but thankfully the team members themselves reminded me the things I've told them earlier, and have put me back on track. What a great team! I hope the managers and the blue sky above want fall on them in the coming weeks.
I'm not sure if I did something wrong, or maybe the team is so talkative, or maybe there was just a need for such a discussion, but this Planning Game took the better part of the day, not much time was left to do any real coding, maybe the team just needs to get used to it and speed up in the future...
I also decided to put the Stories and their tasks into XPlanner. To tell you the truth I'd rather not use it, as the whiteboard is just enough, but I want to collect as much data as possible to use it as hard proof in the future, and XPlanner gives a lot of such data for free, you just need to type the Stories, tasks with their estimates, and then tell him how much time each task took to complete. It's a very simple tool, though it's not "the simplest thing that could possibly work" ie. a whiteboard, I take that risk. If it'll get too much into the way I promise I'll shut it down, but for now I'll try to use it for my own benefit, as I can't do everything at once myself.
Tomorrow I'll also be there, so watch out for new posts, tomorrow I hope to have a normal programming day. And I look forward to try a practice a have never tried in practice :), it's motivation I understand but I fear the Stand-Up Meeting might feel weird .. . But this team has put me in a positive attitude so I'm being brave and I'm going straight ahead ... to bed, nighty night ;)
Anyway I was late because there was a tram traffic jam, chances are it'll happen like 1:100, but of course I hit the 1, too bad I don't play the lottery, so we started around 10:00.
I read out loud all the 50+ cards that we created last time. We decided which group of them is not blocked by any external constraints (like other teams doing something) and chose a few most important based upon business value, as we (as in "the team") said we have a very good understanding of that. Of course the whole course of my actions is to get the machine running and then mount some test environment that the client may see and give feedback. But one thing at a time. This style of adopting XP is somewhere between cannonball and steadily waltzing into the pool, as things happen quite fast (we're almost out of time) but not all at once.
We then begun decomposing those User Stories into technical tasks on a big whiteboard. Every task was then estimated and taken by an individual. I watched carefully that the people who take them feel confident in how to implement them.
Surprisingly in the battle of decomposition we discovered that two of the stories need to have a more general ancestor that will create a foundation for those two to be done. So we created another Story dividing parts of functionality and responsibilities of those former two. We then tried to decompose the new story into tasks, but we found ourselves unable to divide the main task that was 20h long (a lot compared to others), we didn't know how to divide it. It was a clear sign that we really don't know how to do it, so we can't decompose it nor estimate it. We then decided to postpone this Story till the next Planning Game, and instead scheduled a 2 Gummi Bear long spike solution to be done in this field. I think those decisions were the real highlights of this Planning Game's.
I have to admit, that in the midst of the struggle I almost forgot about the basic principles, but thankfully the team members themselves reminded me the things I've told them earlier, and have put me back on track. What a great team! I hope the managers and the blue sky above want fall on them in the coming weeks.
I'm not sure if I did something wrong, or maybe the team is so talkative, or maybe there was just a need for such a discussion, but this Planning Game took the better part of the day, not much time was left to do any real coding, maybe the team just needs to get used to it and speed up in the future...
I also decided to put the Stories and their tasks into XPlanner. To tell you the truth I'd rather not use it, as the whiteboard is just enough, but I want to collect as much data as possible to use it as hard proof in the future, and XPlanner gives a lot of such data for free, you just need to type the Stories, tasks with their estimates, and then tell him how much time each task took to complete. It's a very simple tool, though it's not "the simplest thing that could possibly work" ie. a whiteboard, I take that risk. If it'll get too much into the way I promise I'll shut it down, but for now I'll try to use it for my own benefit, as I can't do everything at once myself.
Tomorrow I'll also be there, so watch out for new posts, tomorrow I hope to have a normal programming day. And I look forward to try a practice a have never tried in practice :), it's motivation I understand but I fear the Stand-Up Meeting might feel weird .. . But this team has put me in a positive attitude so I'm being brave and I'm going straight ahead ... to bed, nighty night ;)
Thursday, June 15, 2006
Day Two: and here they go again ...
Today is the subsequent day of yesterday (as it usually happens lately). We started by reading out loud the Stories written down yesterday. Then we bravely dived into the ocean of the project's requirements and begun producing new User Stories. We finally got to tear some cards (wow! you wont know how good that feels until you try that, seriously! :) ) as we found that some previous ones are not correct. In the process we had a few YAGNI discussions, that resulted in not having some new Stories at all. We also had a few tiny design war games, resulting in tearing other cards into tiny pieces.
We finished our work having defined all the work that has to be done for now. We still need to define cards for an external component that is produced elsewhere, but that's not so crucial for me at the moment. We also found a need to write down as Stories all the functions that are already implemented, so we will know what acceptance tests we need. Yeah, I sincerely hope we'll get to the part where we have acceptance tests, for now we're deep in the jungle ... and is that a hungry puma I hear?
Anyway this day was also a success to the point that I didn't have time to put the cards and sum them up to a scary number of Gummi Bears. I have to see the Project Velocity, then I'll be able to talk to the management and tell them where in terms of progress we really are. And I hope they will have a backup plan if things wont show up so shiny as they think they are. Anyway we're-in-trouble information fed sooner is better than later, way better.
Today is Wednesday (night), so we are scheduled for Monday to start our first brand new Iteration. That is because tomorrow (is Thursday, yes, that's a shocker) is a holiday in Poland, and Friday I have to be at that other company, sigh. So .. see ya all on Monday :). High hopes and brave hearts. (And hard butts if all that wont help :).)
We finished our work having defined all the work that has to be done for now. We still need to define cards for an external component that is produced elsewhere, but that's not so crucial for me at the moment. We also found a need to write down as Stories all the functions that are already implemented, so we will know what acceptance tests we need. Yeah, I sincerely hope we'll get to the part where we have acceptance tests, for now we're deep in the jungle ... and is that a hungry puma I hear?
Anyway this day was also a success to the point that I didn't have time to put the cards and sum them up to a scary number of Gummi Bears. I have to see the Project Velocity, then I'll be able to talk to the management and tell them where in terms of progress we really are. And I hope they will have a backup plan if things wont show up so shiny as they think they are. Anyway we're-in-trouble information fed sooner is better than later, way better.
Today is Wednesday (night), so we are scheduled for Monday to start our first brand new Iteration. That is because tomorrow (is Thursday, yes, that's a shocker) is a holiday in Poland, and Friday I have to be at that other company, sigh. So .. see ya all on Monday :). High hopes and brave hearts. (And hard butts if all that wont help :).)
Day One: And here they go ...
I came to work and realized that I forgot to check if they have cards for the Planning Game. Of course they didn't, why should they :). Fortunately a block away, I found a warehouse that agreed to cut me 200 cards for a reasonable amount in 10 minutes time :). We could've used normal paper, but I personally don't like it, cards 10x15cm made from 240gr/m2 paper are way way better than anything else I've used :).
So starting a bit late we begun identifying various User Stories, giving them short descriptions, and estimating in some number of cute Gummi Bears. At first a Gummi Bear was about one ideal work day, but this rapidly blurred away. To find what the value of a Gummi Bear is, we'll have to wait and measure the Project Velocity.
The first thing that annoyed me was the room, we didn't leave it, everybody was sitting at his computer, so after a while half of the team was distracted doing something else. Unfortunately we had no other choice as there was no room to go to, so I had to ask the team to concentrate, and explained again the importance of what's going on here. Surprisingly it worked and soon everybody was committing to the discussion as much as his knowledge of the project would let him. But in the future I think I'll try to find something more suitable for this purpose.
One might notice the absence of a real customer at this Planning Game, while I'm open for discussion on how to organize that, I had to choose between doing it this way, or don't doing it at all. One of the problems is that we have more than one customer, and they don't directly know each other, and have somewhat different requests and priorities. So after reading an article at agilealliance.org on working with multiple customers I decided to have an internal one, at least for this stocktaking Planning Game.
That said I have to admit that the project leader and part of the team are somewhat experts on how this particular business domain looks like. The project runs for almost a year now, so they have a fairly good understanding of what the client needs. One of them has shown us an existing system that we should largely mimic, and the rest is covered in the mentioned analysis document. So although I know and feel the importance of a customer on a Planning Game I'm not so sure that he was crucial at this moment in this particular context.
What I was counting for though was also to recognize which parts of the system we do not understand at all, and which we *almost* understand. Name them and then bring them to the client for an open discussion.
The day ended having 15+ User Stories written down and estimated, as I suspected a few Stories were named but marked for discussion with the client, as we found we don't really know what he needs. Also we found a few stories that we decided to write down just for remembrance, and for now marked in memoriam as we found that those things are not going to be really needed for this release.
The day was a total success.
So starting a bit late we begun identifying various User Stories, giving them short descriptions, and estimating in some number of cute Gummi Bears. At first a Gummi Bear was about one ideal work day, but this rapidly blurred away. To find what the value of a Gummi Bear is, we'll have to wait and measure the Project Velocity.
The first thing that annoyed me was the room, we didn't leave it, everybody was sitting at his computer, so after a while half of the team was distracted doing something else. Unfortunately we had no other choice as there was no room to go to, so I had to ask the team to concentrate, and explained again the importance of what's going on here. Surprisingly it worked and soon everybody was committing to the discussion as much as his knowledge of the project would let him. But in the future I think I'll try to find something more suitable for this purpose.
One might notice the absence of a real customer at this Planning Game, while I'm open for discussion on how to organize that, I had to choose between doing it this way, or don't doing it at all. One of the problems is that we have more than one customer, and they don't directly know each other, and have somewhat different requests and priorities. So after reading an article at agilealliance.org on working with multiple customers I decided to have an internal one, at least for this stocktaking Planning Game.
That said I have to admit that the project leader and part of the team are somewhat experts on how this particular business domain looks like. The project runs for almost a year now, so they have a fairly good understanding of what the client needs. One of them has shown us an existing system that we should largely mimic, and the rest is covered in the mentioned analysis document. So although I know and feel the importance of a customer on a Planning Game I'm not so sure that he was crucial at this moment in this particular context.
What I was counting for though was also to recognize which parts of the system we do not understand at all, and which we *almost* understand. Name them and then bring them to the client for an open discussion.
The day ended having 15+ User Stories written down and estimated, as I suspected a few Stories were named but marked for discussion with the client, as we found we don't really know what he needs. Also we found a few stories that we decided to write down just for remembrance, and for now marked in memoriam as we found that those things are not going to be really needed for this release.
The day was a total success.
Day Zero: In the lockers... preparing for the battle
We sat down and I told the team what hurts me most, and what I think might just help. My main concern was not to overthrow them with my ideas, and tell them what's wrong or wright, but just to show them a way out, so that they will make the decision of changing the current flow of work. It was the only way I had a chance to succeed. So I told them about capturing requirements in simple, manageable User Stories, the whole lifecycle of a Story. I spoke about the art and power of decomposition and how it affects requirements specification, feature size estimation, and the process of software design. How a Story gets further decomposed to technical tasks by the whole team during the Iteration level Planning Game. Then I told them about organizing work in swift and wieldy one-week Iterations, that start with the mentioned Planning Game, and end with a Retrospective. At the end I mentioned other projects where this approach saved the day, from other people's and my personal experience. So after a few hours of talking and question answering the team agreed to give it a try.
The days before Day Zero
About a month ago my boss told me about a nice and shiny project that is quite crucial for his company and that is about to enter it's final stage. Of course I can't mention a thing about the subject of the project, nor the people involved, but that's quite irrelevant to the story I'd like to blog about, I guess.
The next thing I was told, as one might suspect, was that probably this project isn't going as well as it is supposed to, and more importantly we don't know that for sure. One of the first things that went through my mind was: what is the development method they use, do they use any automated test and stuff. Of course the answer was no. "No" as in "no they don't use any method at all", "no they don't have any automated tests of any sort", and more no's followed.
At the moment I was deeply buried consulting another project at another company. This subject deserves it's own blog entry possibly but to cut it short, that project also wasn't going as well as it should, and even could go (though they do have the potential), but after half a year of struggle mainly with the management of that company I had to give up, as I saw no progress in software engineering practices at all. I can tell people things once, twice, three times, but for the love of God not a dozen, and certainly not so basic things that they just happily choose to ignore. They'd certainly would have to pay me more to compensate for the irritation they cause, and they should at least pretend they listen to what I say. They chose otherwise, well good luck then, a typical shiny Death March, with heads high, proud look and striking bravery. I'll send them a post card, or two.
Anyway right now I'm still engaged in that project for half of my time, but my heart and the rest of my time I dedicate to the new one. Those proportions are very likely to change in the near future, as I find the new project much more responsive to treatment than the old one. Id est the people are willing to cooperate, and they are ready to admit the reality surrounding them, weird as it may sound, but not many are ready to do that.
The primary thing that the main stakeholder wished to have are a certain level of unit test coverage, so that was the first thing that I was told that he wishes to be done. Generally I agreed with that, who wouldn't, we love to have unit tests all around. But my main concern was: is the absence of unit tests the only problem of the project. Well as one might expect, when things unfolded, more monsters came out... Anyway my boss sent me there to secure the well being of the project, and that's what I'm going to write here about.
I've spent around 6 days so far with the team over the last month. The first day I had a presentation about Test-Driven Development (or Test-First Development as nowadays is preferred to say), combined that with a little show and tell and a general discussion about ways of software development. The subject was nice and I needed a solid starting point for a discussion to get to know the team, and it's problems. The response was very good, the team liked the approach very much and they were quite enthusiastic about working that way. I ended the session by leaving them to read the TDD by Example by Kent Beck, and a suggestion to try to use this approach themselves.
I came back after a 2 week holiday and collected feedback. Never mind that for now, there were some problems but at least they strive to write new code the new way.
I then begun observing the project structure itself, I noticed over 40 modules in the SVN repository, but there were no automation scripts that would put all of those modules together. Most of the job was done by hand, some through Eclipse's builders. So the first technical thing I decided to do was to install a few collaboration environments. So I installed JSPWiki for sharing knowledge and maintaining useful data, Luntbuild for build automation, and XPlanner anticipating the further need for it for planning and sharing that with remote teams and stakeholders. Then I begun preparing scripts for Luntbuild to be able to build the system, outside of the development environment, on a separate test machine. Having 40 projects, I soon realized that I'm doing too much copy-paste operations on scripts, so I decided to move to Maven2. I never really used it before so it took me some time to figure out how to customize all the various directories and other stuff that defaults to something different from what the project has. I didn't get a chance to finish the task just yet, as in the next days other things caught my attention.
The leading programmer has a habit of drawing the project structure on a whiteboard and assigning percents it's elements meaning how much is done. What struck me was that all of this came from his head. The features to be implemented weren't written down anywhere. The general understanding of what to do of course was signed with the contract, but that was just as general as it sounds. There was some analysis document but it was vague and incomplete. Moreover there is not a single place to hold, what is done, how do we estimate what has to be done, and when approximately will we finish.
We have a date of course, the 28 of July 2006, but no one really knows what will be done by that time. The customer is sure we'll do it all (whatever *it* means). The managers believe that too. The programmers on the contrary are quite sure we wont be able to do it all in time, and we'll have to mask it somehow.
I don't like situations like that, or to be more specific I hate situations like that one. I like facts, there's no shame nor guilt in telling the truth as soon as possible. There is however shame in covering the truth or even just not being straight forward with it, I strive not to do that.
Well given that, the first thing I decided to do was to force an stocktaking of what we have and what we need, a Planning Game to estimate the size of what we need to develop, and a change in the development flow to have nice observable cycles of development, say weekly Iterations. So over the next few days I talked to people. I talked to one of the programmers there who is my colleague from my company, asked him what does he think about it. I talked to my boss. I talked the manager of that project. After I received green lights everywhere in the command chain, we sat down to work.
The next thing I was told, as one might suspect, was that probably this project isn't going as well as it is supposed to, and more importantly we don't know that for sure. One of the first things that went through my mind was: what is the development method they use, do they use any automated test and stuff. Of course the answer was no. "No" as in "no they don't use any method at all", "no they don't have any automated tests of any sort", and more no's followed.
At the moment I was deeply buried consulting another project at another company. This subject deserves it's own blog entry possibly but to cut it short, that project also wasn't going as well as it should, and even could go (though they do have the potential), but after half a year of struggle mainly with the management of that company I had to give up, as I saw no progress in software engineering practices at all. I can tell people things once, twice, three times, but for the love of God not a dozen, and certainly not so basic things that they just happily choose to ignore. They'd certainly would have to pay me more to compensate for the irritation they cause, and they should at least pretend they listen to what I say. They chose otherwise, well good luck then, a typical shiny Death March, with heads high, proud look and striking bravery. I'll send them a post card, or two.
Anyway right now I'm still engaged in that project for half of my time, but my heart and the rest of my time I dedicate to the new one. Those proportions are very likely to change in the near future, as I find the new project much more responsive to treatment than the old one. Id est the people are willing to cooperate, and they are ready to admit the reality surrounding them, weird as it may sound, but not many are ready to do that.
The primary thing that the main stakeholder wished to have are a certain level of unit test coverage, so that was the first thing that I was told that he wishes to be done. Generally I agreed with that, who wouldn't, we love to have unit tests all around. But my main concern was: is the absence of unit tests the only problem of the project. Well as one might expect, when things unfolded, more monsters came out... Anyway my boss sent me there to secure the well being of the project, and that's what I'm going to write here about.
I've spent around 6 days so far with the team over the last month. The first day I had a presentation about Test-Driven Development (or Test-First Development as nowadays is preferred to say), combined that with a little show and tell and a general discussion about ways of software development. The subject was nice and I needed a solid starting point for a discussion to get to know the team, and it's problems. The response was very good, the team liked the approach very much and they were quite enthusiastic about working that way. I ended the session by leaving them to read the TDD by Example by Kent Beck, and a suggestion to try to use this approach themselves.
I came back after a 2 week holiday and collected feedback. Never mind that for now, there were some problems but at least they strive to write new code the new way.
I then begun observing the project structure itself, I noticed over 40 modules in the SVN repository, but there were no automation scripts that would put all of those modules together. Most of the job was done by hand, some through Eclipse's builders. So the first technical thing I decided to do was to install a few collaboration environments. So I installed JSPWiki for sharing knowledge and maintaining useful data, Luntbuild for build automation, and XPlanner anticipating the further need for it for planning and sharing that with remote teams and stakeholders. Then I begun preparing scripts for Luntbuild to be able to build the system, outside of the development environment, on a separate test machine. Having 40 projects, I soon realized that I'm doing too much copy-paste operations on scripts, so I decided to move to Maven2. I never really used it before so it took me some time to figure out how to customize all the various directories and other stuff that defaults to something different from what the project has. I didn't get a chance to finish the task just yet, as in the next days other things caught my attention.
The leading programmer has a habit of drawing the project structure on a whiteboard and assigning percents it's elements meaning how much is done. What struck me was that all of this came from his head. The features to be implemented weren't written down anywhere. The general understanding of what to do of course was signed with the contract, but that was just as general as it sounds. There was some analysis document but it was vague and incomplete. Moreover there is not a single place to hold, what is done, how do we estimate what has to be done, and when approximately will we finish.
We have a date of course, the 28 of July 2006, but no one really knows what will be done by that time. The customer is sure we'll do it all (whatever *it* means). The managers believe that too. The programmers on the contrary are quite sure we wont be able to do it all in time, and we'll have to mask it somehow.
I don't like situations like that, or to be more specific I hate situations like that one. I like facts, there's no shame nor guilt in telling the truth as soon as possible. There is however shame in covering the truth or even just not being straight forward with it, I strive not to do that.
Well given that, the first thing I decided to do was to force an stocktaking of what we have and what we need, a Planning Game to estimate the size of what we need to develop, and a change in the development flow to have nice observable cycles of development, say weekly Iterations. So over the next few days I talked to people. I talked to one of the programmers there who is my colleague from my company, asked him what does he think about it. I talked to my boss. I talked the manager of that project. After I received green lights everywhere in the command chain, we sat down to work.
Initial notes
I am an young and angry consultant (slash programmer), I just llllllove to play agile, currently I'm contracted to a not so young yet still fierce software company and I'm going to tell a story about what my daily work looks like. Generally it has to be noted that I feel and know from personal practice, that working the agile way, e.g. using the practices of eXtreme Programming is the best way to develop good software that I know of.
For the sake of this blog I'll capitalize the first letters of the XP practices that I decided to adopt as for me those names mean more than just the ordinary common sense. I don't want to Make A Big Fuss By Using Capitals, but rather to underline the importance of realizing when which practice to be used.
For the sake of this blog I'll capitalize the first letters of the XP practices that I decided to adopt as for me those names mean more than just the ordinary common sense. I don't want to Make A Big Fuss By Using Capitals, but rather to underline the importance of realizing when which practice to be used.
Subscribe to:
Posts (Atom)