Xp Kraft Maid
Xp Kraft MaidThis is intended to be a living diary, describing the adoption of ExtremeProgramming at KraftMaidCabinetry. I have been a visitor of these pages for about 6 months, but have not yet applied XP to a project. I must say that there is quite a bit of material to digest here. Hopefully, I'll be able to attend the upcoming seminar in September to gain a better understanding. Please bear with me on this effort, my team makes the transition. Your comments and insights along this journey will be greatly appreciated.
-- KenReigle
I had the privilege of attending XpImmersionFour and have to say that ObjectMentor did a great job of hosting it. I gained a better understanding of XP, especially in the areas of the PlanningGame and the IterationPlan. The talk given by MikeTwo of ThoughtWorks was especially interesting, as he revealed much of how XP has been working in the trenches for 9 months. -- kr
09/18/00 - Let the games begin! I can hear the Olympic theme music playing softly in the background. Well, not quite....
I suppose a good place to start is stating why I am looking to do XP on our next project, which is a rewrite of a fairly large system. The strongest reason has to be to deal with the change we experience over the life of a project. It often seems that some requirements do not surface until well into development. We can't honestly expect our customers to think of everything up front, and we can't be expected to guess at what those requirements might be.
From a development standpoint, the principles of PairProgramming, UnitTest, RefactorMercilessly, DTSTTCPW, and ContinuousIntegration appeal to me as ways to increase the quality of our code.
On the customer side, I expect that having a plan which promises additional functionality at set intervals would be welcomed. As the person who often takes on the responsibilities of ProjectLeader?, the plan will give me additional tools for gauging the completeness of a project.
Here are some of the areas in which I suspect we may encounter difficulties.
10/31/00 - My team has applied XP to the last part of a project started before we decided to give XP a try. We wrote a small entry application using VB and rolled it out to 10 users as a Beta. We then took user feedback and turned them into 10 stories. Because the work to be done was minimal, we decided to use 1 week as our iteration length. At first we expected that 2 iterations would suffice; although at during the second iteration, it was apparent that an extra 1/2 iteration would be required. The users did come up with additional requirements, which was part of the reason for the increase.
During the PlanningGame, the team was reluctant to give estimates on both stories and tasks. I believe the underlying reason for this was a fear of being wrong, even though I explained that the first few rounds of estimating were bound to be inaccurate and that they were not being measured on their ability to estimate. We completed iteration 2 last Friday, and overall came in under our time estimates. Some programmer estimates were very low, and others were pretty high, but the net result ended up to be almost a wash.
A number of suggestions were offered for changing the XP process before we started, yet I resisted the urge to do so. One suggestion was that each programmer take a story, estimate task #1, complete the task, estimate task #2, etc. until that story was completed. My reason for not doing this was that we would lose visibility of an overall estimate, and it would be difficult to assign stories to iterations. Another suggestion was that we take time to research the system to figure out how long we though each task would take. While I'm not opposed to this on a small scale, I think it can get out of hand and become a TimeSink. I eventually asked the team to give this process a fair chance before wanting to change it. Changing a process before you try it just doesn't seem to make sense.
Towards the beginning of the second iteration, a discussion was started during our daily stand up meeting (although we rarely stood) regarding what things should be worked on a pair. My question to the team was "Do you feel that PairProgramming increases the quality of our work?" Since the answer was yes, I then asked what the advantage would be for not doing it all the time. I was met with an interesting response, which I've called ItsJustaSimpleChange. The feeling was that for small modifications or tasks which appeared to be simple, that PairProgramming would be counter productive. Simplicity is relative, as is our perceptions of small. We finally settled on doing everything as a pair, but taking notice of the tasks we think could be done solo, and then discussing the issue later.
Near the end of the second iteration, I had a pleasant surprise from one of my team members. It was the time at which we realized we weren't going to get all of the stories done. Offhand, I made the comment in our morning meeting that it looked like we were in trouble. The paraphrased reply was that we weren't in trouble. We would figure out how much work we could get done, then ask the users what they would like to defer to a future iteration. That made my day.
On a separate note, I've had a number of conversations with my primary user group about having a customer on site. At first, this was met with resistance, but it looks like we'll be able to have a customer in our development area part of each day. Yeah! -- KenReigle
This was last touched way back in 2001. How did things turn out?
EditText of this page
(last edited January 18, 2006)
or FindPage with title or text search