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.
Friday, June 30, 2006
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)