||Dave Hoover : Home|
Two years ago, I started learning my first programming language. Seven months ago, I read Kent Beck's Extreme Programming Explained. I quickly discovered that the underlying philosophies of Agile Software Development were a natural fit with the approach I took in my previous career as a child and family therapist. This excited me. Since that time, I have read numerous agile books, attended user group meetings, regularly lunched with a fellow agilist, and attended XP Agile Universe.
In the last few months, I have been blessed to develop a friendship with a champion of Agile Software Development, Wyatt Sutherland. Wyatt wrote An XP Diary, the inspiring account of an XP project in mid-2002. I have had the privilege of meeting with Wyatt on several occasions to discuss agile philosophies and his ideas on the topic. From these meetings, I gleaned enough ideas to put together a presentation on Agile Software Development.
Last month, I presented these ideas to our IT directors at work. In spite of my weak presentation skills, the directors showed interest in several of the ideas and decided to implement them in our upcoming e-commerce project. The practices they chose were: Test-Driven Development, Pair Programming, Continuous Integration, Refactoring, Coding Standards, and Open Workspace.
Because I appreciated Wyatt's diary and enjoy writing, I decided to maintain a journal of this project.
The preliminary goal of the project is to rewrite an existing e-commerce application in ATG Dynamo. Although I have little experience with ATG Dynamo, most of the other developers on the team have worked together on a previous Dynamo project. I have experienced Test-Driven Development, Pair Programming and Refactoring, but still have much to learn. I have exposed our project manager to agile ideas and he believes they have potential, but he is wary of how the team will react to the new practices.
Our department has a less than stellar reputation in the organization. While there have been recent improvements, missed deadlines and budget overruns have lowered expectations among developers, managers, and business sponsers. Morale is generally low.
The development team will consist of 7 developers. The experience of the team ranges from 2 years (me) to over 20 years, with most around 10. None of us have been developing in Java for more than 2 years. The team is comprised of 3 women and 4 men. One developer is from Bulgaria, one from Ukraine, one from Russia, one from Korea, and one from India. There are two US natives, an African-American and me, your standard issue WASP.
To keep things confidential, I will refer to all of the developers as men. Their aliases are Matt, Nate, Paul, Ralph, Steve, and Trevor. I'll refer to everyone else by their role: PM (project manager), Director (PM's boss), Customer, etc.
I attended a meeting to go over the proposed file system architecture for the project. After all the reading I have been doing lately about team dynamics (Peopleware), it was exciting to rub elbows with some teammates. Nate and Ralph were there. They have spent the last few days building the prototype. The PM announced that I would help with the prototype next week.
The PM did most of the talking, supported by his PM-in-training. The PMIT proudly held a thick document that contained the use cases. There was also a guy there from the QA department. There is some tension between the QA guy and the PMIT about a tool called Requisite Pro.
Most of the other developers are just coming off of another Dynamo project. I need to get up to speed quickly.
The PM briefly discussed the project goals. Our goal for the project is to get the current application off of its current unsupported platform. The Customer's goal for the project is to increase revenue. There is some tension between the Customer's desire for personalization and the amount of time we can spend on the project.
When I heard about this tension my excitement immediately died. Fear crept in. If the prototype isn't being developed in pairs, will the project start without pairing? If we're not pairing, will any of the other practices be introduced? This led me down a rabbit hole of worries.
I spoke briefly with the PM today. He is under pressure to complete the project by the end of April. We discussed that the addition of the new practices will slow things down at first. He isn't wavering in his commitment to try the practices, but will likely use them as leverage for a more flexible deadline.
I am going to focus on setting up our development environment until the project officially starts. We need three development boxes and one integration box. We need to decide on an IDE. I need to start practicing TDD with Dynamo as soon as possible.
I sat down with Nate today. We talked a bit about the project. He expressed his concern over its disorganization. I asked him what a better organized project would look like. He told me he enjoys projects in which use cases are handed down and he translates them to code. Apparently the use cases on this project have been changing frequently. I asked him if he did much reading, hoping to suggest a few nuggets of agile literature. He chuckled at me, explaining that at the point he is at in his career, he doesn't read much anymore.
Tomorrow, I will start helping out with the prototype. I'm sure I'll have many stupid and annoying questions for the PM. More than anything, I don't want to waste time on busywork. I want to set us up for success.
Steve and I will be attending a local 5-day ATG training next month. The week after the training will be spent at the ATG conference in Miami. Development will start in the first week of February.
I installed the ATG Dynamo 5.6.1 development environment. I have a large stack of training materials from some ATG trainings that Ralph attended. The task ahead feels insurmountable, but regardless of the outcome I know I will learn a ton.
Had an excellent lunch with the PM, the Director, and Wyatt today. Lots of questions answered. I could see the PM's Confidence rising and the Fear falling away.
If you had told me three months ago that we would be talking about the Planning Game, Iterative Development and Pair Programming in an Open Workspace, I wouldn't have believed you. It was a strange experience watching the PM and the Director as they began to embrace some of these ideas. I realize that I am just a catalyst, the changes ahead will be increasingly less under my control. It's going to be quite a ride...I can't wait!
The PM called me over to his cube today for an impromptu meeting with Matt. The PM asked Matt what he thought about the introduction of pair programming on the upcoming project. Matt didn't object, but told us that there would be others who would.
He did question whether the project was large enough to keep 6 developers busy. I pointed out that since we will be pairing, we won't need to keep 6 developers busy, just 3 pairs. I'm not sure if he was convinced.
The PM went on to describe breaking our current use cases out into Stories and Tasks. The meeting with Wyatt certainly had an impact! I will push to have the Customer present when the Stories are written.
I stopped by Matt's cube a bit later and dropped off a copy of Cockburn and Williams' The Costs and Benefits of Pair Programming. He seemed genuinely interested in reading it.
The PM, the Director, the Junior Architect, and the development team (excluding Paul, who was out today) met to discuss "Agile Software Development." The PM started off with a somewhat wishy-washy, but relatively accurate, overview of Extreme Programming. He described Pair Programming, Short Releases and the Planning Game. There were no immediate objections.
He asked me to fill in any details that were missed. I spoke briefly about my experience with TDD and the advantages it provides. The Junior Architect for this project asked a few questions about JUnit.
Nate questioned the overall benefits of the approach. Since the PM had already stated that this approach would reduce development time and improve quality, I responded by saying that most developers find the practices very enjoyable, although somewhat awkward at first. I added that the approach took a different perspective to requirement changes during development. We embrace change, but stand firm on Sustainable Pace and timeboxed Iterations by having the Customer prioritize how to adjust the scope.
Nate went on to warn the team that most Customers in our organization will not take kindly to this view of prioritizing Stories. The Director assured us that this project's Customer will be open to the approach for two reasons:
Ralph questioned how our development time could be reduced if only half of the developers are coding at any one time. The PM gave an excellent response, describing the low-level (syntax checking) and high-level (design considerations) benefits that pair programming provides.
Steve and the Junior Architect seemed the most interested. The meeting concluded with the PM mentioning a few issues to consider for our next meeting:
Sat down with the PM and Paul today to go over the meeting that Paul missed yesterday. Paul was extremely open to the ideas we discussed. He asked for some agile resources afterward so I lent him Extreme Programming Explained and referred him to c2.com and extremeprogramming.com.
I think the PM is shocked at the lack of resistence to these new ideas. I'm noticing that the more he explains this stuff, the more he reiterates that we won't be adopting the full set of practices. With upper management pushing it and the developers embracing it, I don't think he'll have much of a choice. I've got to make sure everyone gets a good taste of each of the practices.
Just after we met, the Junior Architect emailed today's Dilbert comic to the team. It was based on XP and had the PHB introducing pair programming. Nice timing. :-)
The team met today to decide on our official hours and IDE. We very quickly agreed that we will use SunOne. Soon after, we came to a consensus on a 9:30 start time for our stand-up meeting. Afternoon hours will begin at 1:30.
Later on, the Junior Architect, Paul and I sat down together to talk about what's been said thus far. Paul read up to chapter 4 in the white book last night. It was an excellent dialogue. Paul voiced his concern about the lack of experienced XP leadership. This encouraged me to start explicitly taking on the role of our Coach.
We talked about some other decisions that the team would be facing, like coding standards. Apparently, the standards discussion has happened before and was mostly unproductive.
We talked about team dynamics and the challenges and benefits that this more intimate setting will provide. All of us could see that the process had already benefitted our team because we wouldn't even be having conversations about the team if it weren't for this.
Our first Planning Game. The PM was out sick so I facilitated the meeting. The Customer, the Director, the Architect, the Junior Architect, the QA guy and the development team were present. I gave a brief explanation of what Stories usually look like. I emphasized that the Customer defines and prioritizes them and the Developers estimate their length.
Things progressed rather nicely at the beginning. The Director acted as the scribe for the Customer. The Customer chose to start with the registration process. We developed a dozen or so Stories and the Customer had to leave.
With the small stack before us, the Architect asked how these Stories would be translated into use cases. He explained that without use cases in Requisite Pro, the acceptance tests could not be properly generated. The Architect decided that the QA guy would translate the Stories into Requisite Pro.
With that out of the way, we began estimating the Stories. Several times, the Architect tried to provide an estimate. After a few unsuccessful attempts at re-explaining the rules to him, I told my teammates that they did not need to use the Architect's estimates since he would not be implementing the Story. He finally caught on, and we all got a good laugh when he told us the current Story estimated at 2 days would take him 3 weeks.
We deferred a few estimates until tomorrow so that we could get some clarifications from the Customer.
As we were wrapping up, Nate held up a card and told us that he could not write code based on that Story. I tried to explain the process of breaking the Stories into Tasks in our Iteration Planning. Nate explained his need for the Junior Architect to provide class and system hierarchies, along with sequence diagrams in order to begin coding. The Junior Architect did a great job of listening to Nate, asking him questions to tease out his needs, and stating his desire to keep the project well organized.
I tried to explain that this approach was not against sequence diagrams when they were needed. I don't think I communicated effectively because Nate turned to Matt, held up an index card, and asked him, "Can you code from this?" I began to lose my patience and rather abruptly agreed that no one could code from the Stories we had written. If we needed to have sequence diagrams to communicate the system to each other, we would use them.
The meeting adjourned on a somewhat uneasy and fatigued note.
Nate, Steve, and I spoke on the way back to our cubes. I restated that this approach was open to any medium that helped increase communication, including sequence diagrams. Steve helped reframe the conversation to Nate and he seemed satisfied.
Nate told me he hoped I wasn't taking his concerns personally. I reassured Nate that I wasn't and we parted with a nod and a smile.
The Customer couldn't make it to the Planning Game today so I cancelled the meeting. On the way back to our cubes, the PM told me that he was going to give me "a lot of latitude" on this project. With his support I feel like I can officially step into the role of Coach. This excites me.
Second Planning Game session today. It feels like a rhythm is developing. Discuss a feature, develop one or more Stories from the conversation. Estimate. Repeat.
Having the PM there was helpful. When developers were reluctant to estimate, the PM was able to prompt those who had relevant experience from the last project to make an estimate.
The process is not going as quickly as anticipated and it looks like the Game will need to continue into next week. I will be in ATG training next week with Steve, so hopefully things will stay on course.
Toward the end of today's meeting the Customer made a statement that, according to the PM, justified this whole exercise. After we had estimated a few of the Stories, the Customer told us he had an uneasy feeling that we already had 3 months worth of Stories. Few Customers in our organization have had the opportunity to observe the effort it takes to develop a web application. In just a few meetings, our Customer has already acclimated himself to a more realistic expectation for this release.
I sent the team some Test-Driven Development resources today. I included a link to "JUnitTest Infected" and let people know they could borrow my copy of Beck's Test-Driven Development: By Example. I also found a JUnit plugin for SunOne and encouraged people to install it.
The Planning Game continues to improve. I think we're all feeling the benefits of the rich communication these meetings provide. The QA guy is using the Game to keep the use cases in sync. The Architect and Junior Architect are using the Game to nail down the details of the database schema. The rest of us are getting a solid perspective on the Customer's needs.
A team is beginning to form. A self-organizing team consisting of developers, managers, and the Customer. A team with a flat hierarchy, formed on collaborative relationships. I am amazed at how easily things have gelled.
Developers are starting to risk being wrong and spirits are high. The Game will continue into next week, though I will be gone. I am confident that the Game will continue to provide the team with a collaborative environment. In my absence, my teammates will have the opportunity to take more ownership of the process. I see this as a Good Thing.
I'm in Miami for the ATG Open conference with the PM and the Architect. The guys from Classroom Connect provided an excellent introduction to TDD on the ATG platform. It was exactly what we needed to hear. They rely heavily on mock objects. By mocking out pieces of the ATG API, it is possible to cut out the Dynamo restart lag time.
My favorite nugget of insight was the ability to defer database design until the end of the project. This directly contradicted the Architect's ongoing assertion that to commence development in ATG, the database needed to be in place.
The PM seemed reassured by the session, while the Architect seemed unsettled. I was excited. I need to come up with an ATG/TDD/Mock Object demonstration before we start development to give the team some confidence in this practice and to reaffirm that we don't need a database right away.
Back from Miami. The Junior Architect asked me out to lunch. The team finished writing the Stories and the Customer had prioritized them into high and low priorities. I told him about the Test-First session and how Classroom Connect was using mock objects. He had borrowed Test-Driven Development: By Example, but hadn't started it. He still hasn't grasped how JUnit works, so the concept of mock objects was lost on him. We agreed to sit down tomorrow morning and work up a demo of TDD in ATG to share with the team.
He shared his thoughts on the ATG project that was completed in December. During the 10 month ordeal, programming tasks were assigned to individual developers. These developers were given the deadline for each task. This environment produced very little communication between developers. They focused solely on completing their task without any thought of reuse or design. The result was a team with low morale and bloated, disorganized software.
His goal for this project is to make things easier on the team by coming up with a subset of the Dynamo API for us to use. His hope is that this will make it easier to reuse the ATG libraries and encourage a simpler design. He also wants to put together an object model before we start coding.
I warned him about the danger of trying to implement code directly from an object model, that there needs to be a give and take as the pairs learn new things and requirements change. I told him my goal for the project was to improve communication within the team and to stay disciplined throughout the project.
Later, the developers, the Junior Architect, the Director, and the Customer met in our Workspace. Our three workstations had just been setup. I was disappointed to see four other guys in there having a meeting. It looks like we'll have to share the Workspace with another team at the beginning. I need to push hard to have that space as our own. Unrelated conversations will distract us from our work.
The Director had to leave in a few minutes but announced that we were ready to start developing on Monday. The Customer was excited to hear it. I held my tongue. The Director left.
A few Story clarifications for the Customer from the Junior Architect. I noticed the Customer was talking a lot about priority and the scope of this release. Excellent.
I asked about the prioritization and how we were going to decide which Stories to implement in the first iteration. The Customer told us that she didn't care which of the high priority Stories were implemented first. Interesting.
I taped a big piece of paper on the wall and tried to explain how we might decide how many days we can fit in each iteration. I stumbled a bunch of times, but fortunately my teammates provided some good input and picked up the slack. We decided that a three week iteration would have 15 "days".
Everyone seemed to understand that after the first iteration, "day", our unit of estimation, would probably not represent an actual day since our estimates are almost certainly not accurate. We discussed how our Iteration Planning Meeting would go: deciding on the Stories, breaking Stories down into Tasks, and then signing up for the Tasks. There seemed to be some discomfort over the idea that we would choose our own Tasks, rather than having them assigned to us.
We all agreed that contrary to the Director's statement, we were not ready to start development on Monday. The team needs to go through an Iteration Plan and get a better grasp of TDD on ATG. That's my goal for the next two days.
The QA guy, the Junior Architect and the developers met to walk through the current prototype. The Customer was out today so we compiled a list of questions for him. The Junior Architect was driving the meeting. He is trying to nail down the database schema along with the look-and-feel of the site. It feels to me like we're thrashing.
Matt, Nate, and Ralph mentioned that they didn't feel comfortable meeting without the Customer. We have already become dependent on his direction. I believe we are recognizing that non-business people shouldn't be making business decisions.
We're going to walk through the prototype on Monday with the Customer and clear up some of our questions. I'm going to try to keep things moving quickly, we could easily get bogged down rehashing all the Stories.
I'd like to get the Iteration Plan started as soon as possible. I still need to setup a TDD/ATG demo.
The developers, the QA guy, and the Junior Architect met to walk through the prototype with the Customer. Several new Stories emerged. We're meeting again tomorrow to (hopefully) finish the walkthrough. As I told the Director, Steve, and Paul after the meeting, we could probably continue rehashing the Stories indefinitely. Stories, by nature, are fluid. I'm looking forward starting the first iteration, I'm tired of all the speculation.
The team seems to be feeling more comfortable together. Everyone was involved in the discussion at some point today. Steve and Paul discussed pair programming after the meeting as I put away the projector. That was great to see. I want them to see this process as their own.
We are set to begin development next Wednesday, 2/12. That takes a load off my shoulders. Now we have some time to go through the Iteration Planning. Paul and I are going to start on the TDD/ATG demo tomorrow. Hopefully we'll have it ready for the team by the end of the week.
The Junior Architect stopped by this morning. He reported that he thought the team "had a good thing going" and hoped that we could keep it on track. He feels that we will be able to go to two week iterations fairly early.
The PM returned from vacation and reported that we might need to push the project start date back to 2/17. This doesn't make me happy. We need to get started.
And then something happened. Nate stopped by and asked for reading materials on Agile Software Development. Astonished, I quickly grabbed Extreme Programming Explained and handed it over. He breezed out of my cube, leaving me with a large smile planted on my face.
The QA guy, the Junior Architect, the developers, and the Customer met to finish the prototype walkthrough. The PM came in toward the end and announced that if people have other responsibilities during the project, Wednesdays are the day to take care of them. So Wednesdays will be optional. Not sure how this will effect our planning and estimates.
Once again, Paul and I did not have time to get started on the TDD demo. We setup an official meeting for tomorrow morning, hopefully that will get us started. We invited the Junior Architect as well.
Started the TDD demo today with Paul. The Junior Architect looked over our shoulders for a while. We hit a snag with some missing properties files and quit until I could figure out why. We went over what we had done thus far. Paul reported that he wasn't feeling quite as worried as he had been initially. I think he's starting to see the light.
I queried the Classroom Connect guys and received an answer about 30 minutes later. Just needed to add some Jars to the classpath. Paul and I will pick it up again tomorrow.
Continued the TDD demo with Paul. I'm getting a feel for how this will work. More questions for the Classroom Connect guys. And more answers. Those guys are lifesavers.
Paul is still a bit uncertain about TDD, but seems to understand the premise. I think he doesn't quite see the value of it yet, though. From the demo exercise and reading Test-Driven Development: By Example, I am compiling a TDD cheat sheet for the team. Hopefully this will help us stay disciplined.
The Junior Architect ran a few meetings with the developers to walk through the prototype and map out the JSP fragments. We spoke in his cube between meetings about the object model for this project. This led us into talking about OOD in general. He showed me Booch's OO book. It looks interesting, I'll need to take a look a it. I suggested three OO books that I've enjoyed: Object-Oriented Software Construction by Bertrand Meyer, Design Patterns by the Gang of Four, and Agile Software Development: Principles, Patterns, and Practices by Robert Martin. Once again, I encouraged us to see potential object models as speculative maps rather than blueprints. He seemed to agree, though it sounds like there is a lack of confidence in the team's ability to evolve a sufficient design on our own.
Worked a bit more on the TDD demo with Paul. We hit some significant challenges. We are trying to use mock objects to simulate Repository interactions. From my brief exposure, the current JSP-FormHandler-Repository architecture doesn't feel right. It's missing a Model layer. The Classroom Connect guys use what they called Services to implement their Model.
When the Junior Architect and I spoke later in the afternoon, he brought up the need for classes that sit between the FormHandlers and the Repository. I agreed and tried to describe MVC. I'm feeling apprehensive about introducing yet another new paradigm into this project. Yet, I'm even more afraid of all those potential FormHandlers trying to fill the shoes of Model and Controller.
With the help of Ron Jeffries and the XP mailing list this weekend, I came up with an idea that I'm going to suggest to the PM tomorrow. I think we should start the project on Wednesday (rather than the following Monday), with just me and Matt. To help the team stay disciplined with the practices, we'll build it up gradually. Once Matt feels confident enough, we'll bring in two more teammates, probably Nate and Steve. When either Nate and Steve are ready, we'll bring in Paul and Ralph.
My concern is the level of chaos produced by six people working in an entirely new way led by a Coach as inexperienced as myself. Chaos is not necessarily a bad thing. Perhaps if I were more experienced, I would attempt it.
The PM immediately embraced the gradual team buildup idea. He agreed that Matt would be the best person to start with. We called Matt over and he seemed excited by the idea. It looks like we'll be starting on Wednesday or Thursday.
This will allow me to focus on working out the rest of the details and skip the TDD demo. One of the details that needed to be addressed was Continuous Integration. On the last project, there was a weekly build with a lot of ceremony and hierarchy surrounding it. Thirty minutes was considered to be a fast build.
I brought up this issue with our Architect since the person responsible for the builds reported to him. He thought anything more than a weekly build was overkill and didn't want to waste his people's time. Then it occured to me that we could do our own builds, since all it took was a fresh checkout, Ant, and JUnit. With the team doing our own builds, the weekly build will essentially be rendered a non-event. Builds don't have to be official, just fast and frequent.
We're all set to start tomorrow. Stand Up Meeting will kick off at 9:30 AM with the PM, the QA guy, the Customer, the Junior Architect, Matt, and I.
Contacted the Classroom Connect guys again to pin down the details of their Model layer. As always, a quick response cleared things up. Did a quick walkthrough of the DynamoMocks sample code with the Junior Architect. Looks like we're on the same page for the time being.
Spoke with the QA guy for a while about his expectations. He's looking for our "first official build" to be able to do his full "system" test. I asked him about the possibility of testing the Stories as we implement them. He liked the idea, and mentioned that he has been pleased with the process thus far. He thinks that his involvement in the Planning Game will be a key advantage.
The Stand Up Meeting was delayed until after lunch because Matt had a few other responsibilities to wrap up. The PM and the QA guy were out so the meeting consisted of the Customer, the Junior Architect, Matt and I. We chose a User Story to implement first. It seemed straightforward so we didn't break it down into Tasks.
The first page we worked on was read-only and we used ATG's out-of-the-box components to implement it. We only had to write JSP and XML. Hopefully tomorrow we'll have an opportunity to write some Java. I am excited to start practicing TDD with Matt.
Pairing with Matt was easy. We had a few disagreements, but were able to work through them quickly. I did most of the driving. Along the way he filled in the holes in my knowledge of the Dynamo API. It was an anticlimactic start, but we're both learning.
I am glad that we didn't start with the full team. There would have been a lot of wheel spinning over the next few days.
The Stand Up Meeting began with Matt and I, so we sat down and got to work. The QA guy showed up and we informed him of our progress thus far. Ten minutes later the Junior Architect arrived. We had some schema questions for him. The conversation eventually led him to express his opinion that we might have started too early. Matt wondered aloud about how he was going to learn TDD if we continued to work solely on JSP's.
My inexperience allowed Fear to creep in. Perhaps we did start too early. How will Matt ever learn TDD? Can we really do this without a finished database schema? As I wavered internally, I stood my ground outwardly. Almost an hour later, the conversation ended on a good note and I stated my desire to continue communicating openly.
By the end of the day, I was confident that we had not started too soon. We tackled some issues that would have been incredibly frustrating with a full team. We still didn't get around to coding any Java. Our work tomorrow may continue to consist exclusively of JSP and XML. Hopefully by the afternoon we'll have time to code.
We stood at the Stand Up Meeting today. More importantly, Matt, the Junior Architect, the PM, the QA guy, and I arrived on time! It lasted 15 minutes. The Customer apologized for missing yesterday, it had slipped her mind.
Matt and I continued to work on the JSP. I picked up some more ATG lingo.
We started coding after lunch! We began with a TestCase and stumbled through a few quick TDD cycles. We slowed down as my expertise in both ATG and TDD began to reach its limits. Matt was patient and guided me where he could. Our Red-Green-Refactor cycles started getting quite long and we ran out of time before we could finish our task. But Matt picked up the rhythm quickly and seemed to appreciate the perspective TDD provides. We left with a failing test so we can pick it up quickly on Monday.
Talked to the PM about who to bring in next and when. Ralph and Steve are set to come on board next Wednesday. That should give Matt two more full days of TDD.
We need to start practicing Continuous Integration. I hacked together an Ant script that grabs the source from PVCS, leaving the locally modified files alone, compiles everything, runs the TestSuite, and Jars it up. Ant rocks.
I was late for the Stand Up Meeting today. I was happy to see that they started without me. Not much to report. Matt and I picked up where we left off on Friday and completed our Task quickly. Our next Task was to implement the Model layer that we had mocked out previously.
Again, we started with a TestCase. Matt wanted to drive this time. He stumbled as he tried to write the test. We agreed that for this task I would write the tests and he would get them to pass. This is a testing pattern that my friend Roman Zabicki and I had used previously. It is a coding competition with cooperative overtones. The coder's goal is to get to green as quickly as possible, laziness is a virtue. The tester's goal is to write tests that will break the coder's code and force the coder to complete the Task. It should feel a bit like hot potato.
We had to grab a bunch of mocks from the Classroom Connect dynamomocks SourceForge project in order to mock out the Repository. Matt got the first test case to pass. I tweaked it: red bar. We went back and forth. An enjoyable rhythm developed. Time passed quickly and we completed our Task.
The Junior Architect came by to discuss the package structure and some classes he had developed. He admitted the classes were developed without tests. I may be wrong, but it seems like he's wanting to build in a lot of needless complexity up front. By the time he got out of there, they day was over.
We still haven't run the build script or checked our code into PVCS, so we'll start with that tomorrow. Looks like we'll be ready for Ralph and Steve on Wednesday. On the way out, Matt told me he is liking TDD.
Matt and I added another method to the TestCase we were working on. Matt drove. We needed to handle a circumstance we hadn't considered yesterday. About a half hour later, the tests told us we were finished.
Time to put our work into PVCS and get the Ant script running. We struggled with the Ant script until lunch, having issues with the PVCS task, then our classpath, then running it in SunOne, and finally with JUnit. Five minutes after returning from lunch we had it working. Not surprisingly, our first build was a success.
We worked closely with the Junior Architect for the rest of the afternoon as we began implementing a highly visible class. As the Junior Architect pushed some ideas about using Introspection, I struggled to see how the added complexity would help us. We went back and forth, but we all kept an open mind.
Matt pushed us to start simple. We wrote a test. We got it to pass with an obvious implementation. Then we started reading about Introspection. A few minutes later, we saw the light. The test passed...high fives and big smiles. Added the new files to PVCS, double-clicked the Ant script...success.
The Junior Architect's idea was a good one. He is nervous about tomorrow, though. Ralph and Steve will join the team. I don't think the benefits of TDD and Pair Programming have sunk into the Junior Architect's head yet.
Matt and I talked about who will pair with who and what we'll be working on. I'll be pairing with Ralph and taking on a new Story. Matt will be with Steve and continue with the same Story.
I was walking on air on my way home. TDD, Pair Programming, and Continuous Integration have been successfully introduced. It was amazing how quickly the day flew by. My attention as our Coach will now need to turn to velocity and estimation.
I got to the Workspace early this morning. I taped the Stories that were relevant to our current iteration to the wall.
In order for Ralph and I to start off on the right foot, I needed to get the second workstation working. Interestingly, when I finally ran the build, it failed. The Junior Architect had checked in some classes last night that wouldn't compile.
Matt, Ralph, and Steve showed up. We sat down to give an overview of what had been worked on thus far.
The Customer showed up later. Not much to report, other than the progress on the Stories. I encouraged him to stop by the Workspace anytime during the day since we usually had some outstanding questions.
Matt and Steve paired up and continued with our task from yesterday. Ralph and I sat down with the Junior Architect to discuss the design for our Story. The Junior Architect had sketched an object model and written some classes for us to use. We made a copy of the model and kept it close by.
We began with a TestCase. We went through a few TDD cycles with some obvious implementations. And then we needed to start using some classes that had been written by the Junior Architect. These classes were not written with testing in mind and were hard to work with.
By the end of the day we had painted ourselves into a corner. I finally realized that we should have mocked out the Junior Architect's classes. As Ralph and I began looking at the most signifcant class, it became apparent that it would be difficult to mock out.
Tomorrow should be interesting. I believe we should chuck what we did today and start over. Furthermore, I think we should rewrite the Junior Architect's classes test-first. Both of these ideas will probably raise some eyebrows.
Neither of the pairs checked anything into PVCS or ran any builds today. Both Matt and I did all the driving.
Before leaving, I sat down with the PM and the Director to reassert my frustration with sharing our Workspace with another project. Several times in the last week, our roommates had convened meetings in the room, distracting us from our work. The Director assured us that he will be working to resolve the problem.
I spoke briefly with the Junior Architect. I tried to sound appreciative as I asked him not to write any more code for us. He got the point. I really wish he could have just been a developer with us on this project. It's such a waste to put such a knowledgable Java developer in a non-coding role.
Ralph and I scrapped our work from yesterday. Rather than mocking out the classes that the Junior Architect wrote, we focused on developing tests for them. By the end of the day, we had mocked out a couple more ATG classes and added to some of the existing mocks.
Our TDD cycles were long. I was still doing most of the driving. Fortunately, we were able to check some of our work into PVCS and did a successful build.
We continued to work on the tests for the Junior Architect's' classes. I began to feel uneasy about how much logic we were building into one of the mocks. Ralph and I quit for the day and I shot an email to the Classroom Connect guys for advice.
Nate and Paul will join the team on Monday. It's fortunate that Paul has already been exposed to TDD. Ralph and Steve haven't had much time to build their TDD skills.
The Classroom Connect guys got back to me, encouraging me to not attempt to rewrite ATG functionality in our mocks. They also referred me to the ObjectMother testing pattern for the setUp methods that can get quite long and annoying. ObjectMother looks perfect for what we're doing, it should make testing a lot easier.
Ralph and I got our tests passing and began refactoring one of the Junior Architect's classes. In it's original state, it tried to do too much, violating the Single Responsibility Principle. We started with a TestCase and did an extraction. By lunchtime we had two simpler, more focused classes, but we were still at a loss about how to test the full functionality.
I met my friend and agile collegue Roman Zabicki for lunch and explained our current dilemma. After we had sketched some pictures and typed some pseudocode, Roman offered a solution. He emphasized that we shouldn't be testing ATG's software, and therefore, we could just focus on the sequence of calls to ATG objects and have our mocks track this. Ralph and I tried it out and it worked. Because it hasn't run against non-mocks, we can't be certain that the code is correct, but our tests are in place. If we do find a problem during our acceptence testing, we'll update the tests and make them pass.
Nate and Paul start Monday. The team decided that Ralph and I will stay together for the time being. Matt will work with Nate on a new Story that Nate chose during our Stand Up Meeting this morning. Paul and Steve will pair up on the Story that Steve and Matt have been working on.
We're halfway through the first iteration. I think the best aspect of the project thus far has been the pair programming and the Workspace. With less interruptions and continuous access to each other, the project's communication is excellent.
We need to improve on running the builds frequently. When Ralph and I finished up on Friday we did a build and it failed. Matt and Steve had checked in code that failed the TestSuite and had a bunch of residual debugging code in place. I spoke briefly with Matt about it. Might be time for a rolled up newspaper...
Paul was out sick so the PM brought in Trevor to work with Steve.
Matt and Nate worked well together all day on the new Story. It was good to see Nate integrating so easily into the team.
Steve and Trevor are both inexperienced Java developers. Becuase of this, I found myself switching places with Trevor when Steve would hit a snag. This slowed down Ralph quite a bit, since he relies heavily on me for the TDD stuff. Although I felt stretched thin, the Open Workspace made switching pairs and improptu team meetings incredibly easy.
We are spending a ton of time on our TestCases, it feels like it's about 2:1 test code to production code. I need to get the ObjectMother class in place to keep us writing tests. Matt will be out on Wednesday. Maybe Nate and Ralph can work together while I develop the ObjectMother.
The build is still broken. Tomorrow will not begin until we have a successful build.
No Customer at the Stand Up Meeting, but the PM was there. The PM asked about our progress. No one spoke up, so I told him that things were going slow, just as we had predicted. Paul was in the office, but has bronchitis so the PM quarantined him from the Workspace. Trevor will continue with Steve.
I encouraged people to check things back into PVCS quickly, to run the tests frequently, and run the build at least once a day. Mostly blank stares. I think there may be some cultural issues at play here, and it feels like it's closing down our communication. I ran the build a few times today and things are looking good. But the two other pairs hadn't checked in their work.
Throughout the day, the team struggled to write tests. The Junior Architect tried to help, but his TDD ignorance had him sending people in directions that made things hard to test. Steve and Trevor spun their wheels most of the day, their Java inexperience was showing. Matt and Nate continued on their Story, but struggled with testing. Ralph and I completed a thin version of our Story. We're set to do a manual acceptance test.
Tomorrow is the official off day for the project. I think a few people will still be able to work on it but it's a bit up in the air. I am going to sit with Steve and help him through his current Story. I am also going to implement the ObjectMother.
Today was our first official off-day. I was pleasantly surprised to see that the PM, the Customer, the Junior Architect, and the developers still attended the Stand Up Meeting. Hopefully peoples' attendence was due to the value they receive rather than mere obedience.
It was a very interesting meeting. Last night, the Junior Architect discovered that Ralph and I had worked on a class at the same time as Steve and Trevor. I had spoken with Steve about it yesterday to make sure we got together to merge the two versions today. The Junior Architect assumed that Steve and I hadn't communicated and merged them for us. He told us in the meeting that we should not work on files simultaneously because it goes against source control. I disagreed, saying that as long as we're communicating, it shouldn't be a problem. We went back and forth. Eventually I lost my patience and raised my voice. The PM stepped in and stated that we should try to do it my way until it doesn't work.
After the meeting I apologized to the Junior Architect for losing my cool. We spoke for over an hour about the project and the costs of testing. He told me that it upset him that Ralph and I had spent so much time on our Story just to get the code tested. He felt that we should be more carefully weighing when the costs of testing outweighs the benefits. I reluctantly agreed, and told him that I had high hopes for the ObjectMother class Steve and I would be implementing today.
I asked the Junior Architect why he was concerned with our speed. It didn't make sense to me. He confessed to me that his concern stems from his past experiences when schedules got tight: he was always the hero. Now his concern makes a lot more sense to me. I feel like I should talk with the PM about this issue. It would be great if we could reassure the Junior Architect that he would not be put in that position in this project.
Steve and I got into the code and ran the build script. Failure. The Junior Architect hadn't updated the tests or the mocks when he had made his changes last night. We started trying to get the build to work, but gave up so that we could get Steve's current task completed first. We cycled through Fail-Pass-Refactor for a while and our work was done.
We then began our work on ObjectMother. We started with the most recent TestCase we had worked on. It had a huge setUp method. Taking small steps, we extracted chunks of the setUp out to the ObjectMother. We ran the TestCase constantly to see if we were breaking anything. It caught us a few times. When we finished, our setUp method had gone from about 50 lines to less than 10. It was beautiful.
We checked in our changes. Tomorrow we need to get the build running.
Just two pairs working today, Matt and Nate were out. Ralph and I got the build working, refactoring the Junior Architect's changes. Along the way we found several bloated setUp methods and refactored them to use the ObjectMother. I was a happy camper when we finally saw the build succeed.
Ralph seems to be more test infected lately. At one point today, we had some broken tests and I wanted to do something else before we fixed them. Ralph insisted we get the tests running. It was the right move.
This afternoon we manully tested our Story via a web browser. We hit some bumps and updated our mocks to behave themselves more realisitically. Once the unit tests were passing again, we tried again with the browser. Another bump, another test update, another few minutes, and the tests passed.
And then it worked. Big smiles. We checked in, ran the build, success. Ralph shyly raised his hand, offering a semi-high-five. I slapped him some skin and we called it a day.
Mostly JSP progress today, implementing the View for the Java we have done these past few days. It was a different sort of beast, with long Dynamo restart cycles and Repository and Nucleus tweaks. By the end of the day, the Stories were feeling manageable and the end was in sight.
With Nate still out, Matt alternated between working alone and with the Junior Architect on his Story. It feels like he's spiking right now, exploring some unknown territory. Not sure how much he'll have for this iteration.
Our first iteration concludes on Tuesday. We have two days to get to a clean stopping point.
Regarding our process, I feel like Tasks are the missing link. We never broke down our User Stories into Tasks. We signed up for our Stories as pairs, not individually, so there is no measure of individual velocity. We need to have that metric.
I'm going try to set an Iteration Planning Meeting for Wednesday in place of the Stand Up Meeting. We can reflect on how things went, work with the Customer to choose the next User Stories, break them down into Tasks, sign up, and estimate.
Wrapping up Stories and polishing the JSP's for tomorrow's release. I set up an Iteration Planning Meeting for Wednesday. I am excited that we will have some real functionality to give to the Customer.
Last day of the first iteration. The Director showed up to the Stand Up Meeting with Krispy Kremes. Afterward we sat down with the Customer to show him our progress. I may just be insecure, but he seemed to be a bit surprised that there wasn't more to show.
After being told that the test server was ready last week, it turns out that it wasn't. Our first release to the test server will have to wait until tomorrow.
By the afternoon, the Stories were as far as we could take them. A couple small Tasks remain undone for each Story, so we will have to cover them in our Iteration Planning Meeting tomorrow afternoon.
The Junior Architect and I spoke at the end of the day. He is happy with how the project is going. He views TDD as something we must continue! He feels that most of the team needs more direction in their testing, though. He wanted he and I to map out ahead of time which tests to write. As usual, I disagreed with this approach, stating my desire to keep people learning and thinking rather than being told what to do. But I agreed that the team did need more direction. Pairing with more people than just Ralph would certainly help spread some TDD knowledge.
With Tasks and individual developer sign-up, the results of our meeting tomorrow should facilitate more frequent pair changes.
The developers, the Junior Architect, the Customer, the QA guy, and the PM attended the Iteration Planning Meeting. I took the lead and facilitated an iteration Retrospective. Because of some of the team's reluctance to speak, the PM asked everyone to say at least a few words. The feedback was largely positive, focusing on improved communication, design, and knowledge distribution. People found the Planning Game to be extremely beneficial, along with having early and continuous access to the Customer. Negative feedback was directed at the need for more design documentation and a smarter perspective on where testing is appropriate. I encouraged people to interrupt the entire team if they were stuck on something. Frustration had built up about testing partly because pairs weren't asking for help.
We broke down the Stories from the first iteration and signed up for the remaining Tasks. It was a pleasant surprise to actually have several Story Cards in the "finished" pile. We hit a few bumps when I tried to introduce the idea of individual sign-up, but ten minutes later things were working perfectly.
We spent a long time discussing the "Shopping Cart Checkout" Task. Eventually I had to interrupt to keep things moving. Matt had signed up for it and was forced to give his best guess for an estimate. We all know we need to talk more about this Task.
Once we had signed up for the remaining Tasks from the first iteration, we added more Stories, breaking them down into Tasks as we went, until we felt we were full. Then we recommenced the sign-up process. It went very quickly. It felt empowering to be able to choose my own Tasks.
To determine individual velocity, we took the number of days in an iteration (12 = 3 weeks x 4 days per week) and divided by 2 (since one would only be working half of the time on one's own task). This gave each developer a bag of 6 days. Paul took one less because of some outside responsiblities. This gave us 41 days worth of work in the iteration.
Amazingly enough, as the time for our meeting drew to a close, we had just finished signing up for the last Task, and our total days was at 41. I transposed the Tasks from the whiteboard to index cards. We left on a high note. I'm looking forward to tomorrow.
I got to the Workspace early and posted the Stories and Tasks for this iteration on the wall. Above the stories, I wrote the date of the last day of the iteration: March 25th. It felt great to have things broken down into more manageable chunks.
The team worked on wrapping up the remaining Tasks from the first iteration, so the pairs remained the same. As Ralph and I completed two of his Tasks that we had estimated at one day a piece, I immediately saw the advantage of having Tasks. We received positive reinforcement much sooner because our Tasks are small. More importantly, we received immediate feedback about the accuracy of our estimates.
It was great to see Steve interrupting the entire team when he and Trevor got stuck. Each time someone helped them it took only a couple minutes and they were back on track.
I am going to try to switch pairs tomorrow. I would like to have Ralph pair with Steve and Trevor pair with me. It will be interesting to see how the team reacts to this idea.
The pair switch was a non-event. Trevor and I made a ton of progress on my first Task. Looks like it will be finished early Monday.
Matt and Nate are struggling with their Task. They are definitely not writing tests. I am going to see if I can lend a hand on Monday.
Paul, who has yet to join the team because of other responsibilities, is reported to be starting on Monday. I am looking forward to his participation because he asks a lot of questions. His arrival will present an interesting challenge for the team. With Trevor on board full time, we will have 7 developers and 3 workstations. We'll see how that goes.
Matt and Nate are still chugging away at their Story. One Task is completed. Their estimate was a day off. I'm concerned about their isolation as a pair and the lack of knowledge sharing.
I paired for a while this morning with Steve, and then Trevor. We finished my Task soon after lunch.
Trevor was pulled off to work on another project for a day or two. Paul was in the Workspace for about an hour, talking with the Architect about Ralph's remaining Task. Ralph was there for only a short while, spending most of the rest of the day working on a different project.
The PM and I sat down to discuss the issue of people getting pulled off and onto the project so frequently. I stated that it didn't matter to me how many people were on the project. My desire is to have a dedicated team.
We still haven't released our first iteration's work to the test server, which was finally ready today. That will be my first priority tomorrow morning.
We released to the test server and now the admins are fooling around with the configuration. This is driving me a little nuts, it's been a week since the Customer and QA guy were supposed to have it.
The Junior Architect is getting nervous about Matt and Nate's apparent lack of progress. I shared my concern about their isolation and lack of testing. I had offered my help at the Stand Up Meeting to no avail.
I suggested we use their estimates as an indicator and a tool to help them out. If they are getting behind, our offers to help bear a bit more weight. I do not want to get the PM involved. I want the team to resolve this issue. The Junior Architect suggested we revisit the issue this Friday. I agreed.
Steve and I made a ton of progress on my Task today. It looks like we may have overestimated, which is nice.
Matt was out today and Nate worked on their Task alone. By the end of the day he had it mostly finished, which means they will almost certainly hit their estimate for tomorrow.
These small Tasks give us an excellent grasp on our Velocity. It's all about feedback.
Steve and I were finished with my Task after lunch. I had overestimated by over 5 days. This works well, since it's looking increasingly doubtful if Paul (who had 5 days worth of Tasks for this iteration) will ever join the team.
Once we finished, this freed us up to pair with different people. Steve joined Matt on his new Task. I sat down with my old pal Ralph to help him wrap up his Task. Trevor got started on his Task with Nate.
Sitting down with Ralph revealed a complete lack of testing. This is still our biggest challenge. I need to to continue to switch pairs frequently. Steve became test infected as we developed our Task. At first he was wary of spending a bunch of time setting up mocks in our ObjectMother. By the end he experienced how much faster we could develop without having to worry about the slow ATG restart.
A bunch of bad news in the Stand Up Meeting. The Customer announced that he would be out of the office for 11 business days, starting this Friday. I asked if there was anyone who could stand in for him while he was out. He told us that he was the only one who knew about the project.
Then Matt and Nate both reminded the PM that they would be out next week. It was news to the rest of the team.
On top of it all, the test server, which had been up for a day, was down again. The PM is looking into it.
Paul is doing his best to join the team, though our setup doesn't make it easy to incorporate a seventh devleoper. He will definitely be able to fill in next week.
Because of the absences next week, I am going to try to hold the Iteration Planning Meeting early so that everyone can be involved. I'm shooting for Thursday morning.
The morning was spent planning for the next iteration. We started by re-estimating the outstanding Tasks for the current iteration. It was clear that three Tasks needed to be deferred. Our velocity ended up being almost 25% less than we had estimated.
We used Yesterday's Weather to determine our capacity for the next iteration. I was sure to ask very clearly about any time off. Four of us will be out at some point over the next three weeks. Paul won't sign up for any Tasks and will assume the role of the floating pair when people are out.
We chose the Stories for the next iteration and broke them down into Tasks. Again, this felt very natural and provided opportunities for some brainstorming and design. But when it came time to sign up, most of the team was silent. A few people signed up, including myself, until we met our capacities. I eventually prompted our silent teammates about whether they were interested in the remaining stories. Eventually everyone was at their capacity. At the end, the team looked downright downtrodden, though I'm not sure why.
It feels as though we are ahead of the game. When this iteration is over, our "Finished Stories" pile should be much larger than the pile of remaining Stories.
I had lunch with the Junior Architect today. Our relationship has become a pleasant surprise and a good support for me. I think we both see that there is a lot we can learn from each other.
We discussed how we felt things were going with the project. I brought up my frustration and impatience at the team's lack of motivation. As the Coach I feel increasing pressure to become a dictator. While I know that is not what the team needs, it is clear that it is often what the team wants. The Junior Architect and I agreed that there are a lot of cultural issues involved that we don't fully understand.
I brought up my desire to switch pairs more often. We haven't switched in a week and it's getting exhausting.
After this next iteration, we will have six weeks left. The Junior Architect and I both agreed that we should try to do three two week iterations rather than sticking with three week iterations. Looking forward to that.
I told him that I am very interested in seeing what happens after the project. Will management look at it as a nice experiment but not generalizable? Or will they take pieces out of it to incorporate into other projects? This is what excites me right now, organizational change.
It came up at the Stand Up meeting that Matt's current Task may not be what he thought it was. He looked to me to define the Task, as if I were the holder of the requirements. This expectation seems to be appearing more frequently, and it's a phenomenon that frustrates me. I want the team to be individually proactive, to ask questions and check assumptions.
Perhaps I am making some assumptions about people that don't translate across cultures. I assumed that my teammates would choose to be self-directed rather than dictated to. But there seems to be an organizational tendency to defer responsibility up the chain of command. I suppose we fear that by taking responsibility we will become the unwilling hero when things go awry. I've got a lot to learn.
Tomorrow is the last day of the iteration. It feels like we'll have our current Tasks completed. Wednesday we go to lunch as a team. It will be wonderful to have a chance to interact in a less professional setting.
Last day of the iteration. Matt and Nate are on vacation. It came out in the Stand Up meeting that Paul and Trevor spent most of the day yesterday trying to untangle some changes that Nate had made late Friday after everyone had left. Paul was out unexpectedly today and Trevor was concerned about being able to finish alone. The Junior Architect worked with Trevor all day, with Steve looking on. At the end of the day, bugs remained.
Ralph and I finished our Task, though we had to defer a small piece of it.
Things are feeling a bit messy and definitely undisciplined. I'm unsure of how to proceed without exercising too much authority. I feel like testing has been mostly abandoned outside of anything I'm working on.
The shopping cart/checkout process seems to be our biggest challenge. I wonder if learning from our mistakes and starting over would be the wisest decision.
I'm looking forward to going out to pizza tomorrow. This team needs to let off some steam. I think I need to go invest in some Nerf guns for the Workspace.
Our work from the second iteration has been deployed to the test server. The QA guy and his accompanying use cases seem disconnected from the team. It doesn't feel like we're getting the feedback from him that I had hoped for. This is another situation where being a player/coach proves difficult. My attention is focused mainly on implementing my current Task, rather than on the practices.
The Director took the team out for pizza. Good times mostly, though we talked too much about work.
The Stand Up meeting was interesting today. We decided on which Stories to start with and discussed how to get started on them. With two people out and Ralph and I leaving in two days, we were limited in the Stories we could work on. But as always, it worked out.
Unfortunately Paul and Trevor spent the day wrapping up a Task that was supposedly finished last iteration. I'm feeling the discipline slip and I need to bring it up in a constructive way.
I finally had the chance to pair with Nate today. We wrapped up a Task he had worked on yesterday by himself. The Task was finished a day early so we grabbed Nate's other Task, estimated at 2 days. Two hours later the Task was complete.
It felt great to zip through two Tasks so quickly. The other two pairs are struggling through more difficult territory. Hopefully Nate and I will be able to help out tomorrow. I'm going to do my best to shuffle the pairs.
The project progresses, we're hitting our estimates, the Customer has returned. But setbacks keep popping up. Yesterday the Junior Architect informed me he would be out for the rest of the iteration. He had told the PM. Today Trevor informs me he will be out tomorrow. He had told the PM. I need to talk to the PM.
TDD has been all but abandoned. The order process was started without tests, and my lack of involvement in its early development didn't help matters. I'm getting my hands into it now and it's a bit messy. The Tasks are completed, but our definition of "completed" lacks rigor. I haven't made time to incorporate our QA guy, who is hesitant to test anything until we have a fully funcitonal site. Acceptance Testing has been non-existant.
I see now that an XP Coach needs to be only an XP Coach, and not a full-time developer. More than 95% of my time is spent coding. That is where I am most urgently needed, and that's where I want to be. But our lack of discipline is a result of our lack of Coaching.
Fortunately, several other practices are keeping the team in good spirits: Pair Programming, (a less than perfect flavor of) Continuous Integration, Open Workspace, Small Releases, and the Planning Game.
With several Tasks completed ahead of schedule, I took on the unofficial task of ironing out the order process. Trevor was out so Paul and I worked together when he was available. It was encouraging. We made a ton of progress.
Still no tests, but a much better conceptual understanding. Tomorrow should hopefully take us through to the end of the order process.
Our third iteration is complete and spirits are high. We completed our Tasks and then some. Most of today was spent testing the application, wrapping up loose ends, and finally giving the thumbs up to the Configuration guy to deploy to the Test Server. Lots of smiles, lots of collaboration in the Workroom.
I think the team is just now beginning to believe in itself. We were able to finish the iteration with some breathing room without the Junior Architect. Unit Testing has not been picked back up yet but we're working to get the QA guy involved.
Tomorrow is our Iteration Planning Meeting. We have a small pile of Story Cards left to implement. We are going to work with the Customer tomorrow to determine a "barely sufficient" release.
The Iteration Planning Meeting this morning went smoothly. We decided to try two week iterations so we could get quicker feedback from the Customer. As we wrote out the rest of the Stories on the whiteboard, breaking them into Tasks, we realized we had more capacity than we needed. Matt ended up without any Tasks so we decided that he would be a floating pair while the PM works to transition him into another project.
It's hard to believe we could be wrapping up development before May! I wouldn't attribute this earlier completion to exceptional development speed as much as working closely with the Customer to create a barely sufficient release. I told the team that I was impressed with our work.
The PM and QA guy are going to be testing the application much more rigorously in the weeks ahead. They will meet with the team every afternoon (essentially another Stand Up Meeting) to go over the current issues. The QA guy came up this afternoon with a few issues. None of them turned out to be bugs, just misunderstood requirements.
Halfway through the iteration. We've knocked out a bunch of Tasks already and the team has great momentum. I like two week iterations, it requires more focus.
The QA guy is resisting testing until we have a "full build". What this means is that he won't test until we say we're done. This frustrates me, but I have chosen to not make a stink about it. It will be interesting to see how this affects our timeline later.
As we complete Tasks, the remaining Tasks are increasingly dependent on outside parties. I spent the day yesterday pestering as many people up and down the chain of command from several companies in order to make progress on the credit card validation Task. I took it as far as I could and then deferred it to the PM, who is now keeping me informed. I paired with Nate today since I couldn't go any further with my Task.
As we near our first release, I want to focus on how to take the lessons we have learned from this project and apply them to future projects. I don't want to let our team fade back into the woodwork, we need to keep our momentum going.
The last two days have been spent struggling against our architecture. It came to a head today when my pair (Steve) and I sat down with the Junior Architect and an ATG consultant to find a solution. After we outlined several approaches, I advocated that we do a major refactoring in order to simplify the design and prevent any hackish workarounds. The Junior Architect then came up with a way to use the java.beans.PropertyChangeListener interface to solve the immediate problem. I am discouraged. It frusrates me that someone can make design decisions without having to deal with the consequences. The immediate issue has been resolved but I feel like we're writing legacy code.
Wrapping up Tasks in preparation for the last day of the iteration. The Customer hasn't attended the Stand Up Meeting in a week. The PM tells us he's working on getting the Customer there.
We finally made solid progress on the credit card validation Task. The Director and I spoke with some guys from the financial institution. I'm confident we'll be able to complete the Task during the next iteration.
I read something in Jim Highsmith's Agile Software Development Ecosystems today that made a lot of sense to me. He was speaking to a Kiwi project manager who told him:
We don't organize a team around a project, we build up teams and then throw work at them.This makes sense to me. I'll have to bring it up during our Project Retrospective on Wednesday.
Our first two week iteration is complete. Looking back, two weeks vs. three weeks caused no additional strain on the team. It simply allowed us to get feedback more quickly.
We completed our Tasks to the best of our abilities and adapted when necessary. Tomorrow is our Iteration Planning and I will be facilitating a Project Retrospective.
The Director and I spoke for a few minutes today about the Retrospective and what I have learned during the project. I expressed my hope for the Retrospective: that the team will feel comfortable communicating how they felt about the practices we tried and their wishes for future projects. I didn't push the Director in any direction other than to listen to the feedback of the team.
He asked me what I had learned. Wow, so many things. I learned...
We had a number of people absent for today's Retrospective: the PM, Paul, Trevor, the QA guy and the Junior Architect. Despite their absence, I couldn't be happier with the way things went. The team felt comfortable expressing themselves, freely disagreeing about what worked and what didn't.
One of the consensus agreements was that we needed better communication about the architecture at the beginning of the project. I don't have an obvious solution to this, particularly using an Agile approach which puts less emphasis on up front design. Having the Architect in the trenches would have facilitated better communication about the architecture.
There were mixed reviews of pair programming. Everyone agreed that it helped immensely with knowledge sharing and bringing less experienced people up to speed quickly. But a couple of our most experienced teammates felt they could have worked faster and better on their own. One develper felt that pair programming reduced personal responsibility compared to assigning a single feature to a single developer.
I brought up the advantage of having the Customer involved throughout the process. I emphasized how much time we saved by focusing on a barely sufficient release rather than what the requirements specified at the onset of the project. I also brought up the need for our organization to work to improve our web application testing practices.
Afterward, we broke down the remaining Stories, signed up for Tasks, and estimated. In two weeks we will have very little left to do.
Steve and I finished my credit card validation Task today. Right in line with our estimate. We're now getting started on his calculate sales tax Task. After grabbing some code from the last ATG project, we spent some time refactoring it to interact with our components. Good fun.
The team is increasingly pulled away from the project despite the PM's knowledge of our Task commitments. I'm fighting to keep us focused and we seem to be staying on track.
The team continues to struggle to stay focused as the PM is under pressure to pull people in different directions. I feel I need to suggest an alternative: pick a couple people and dedicate them to dealing with these other issues, leaving the rest of the team to focus on their Tasks.
We're whittling the remaining Tasks down. What is left is the messy and deferred. We are increasingly reliant on people outside the team to complete Tasks. Fortunately, these dependecies are tracked closely in our Stand Up Meetings.
As the iteration draws to a close, the intensity is picking up. Getting our Tasks completed will be a tight sqeeze because Nate's LDAP integration Task has been a bear. Fortunately, my sales tax Task should be finished early.
Steve and I stayed a little late and wrapped up his sales tax Task. It was a particularly good feeling because of the limitations we had with interfacing to the third party software. We were forced to develop on our test server and not in our development environment, slowing us down considerably.
Tomorrow is the final day of the iteration. Looks like we'll need to defer a Task because Nate's one day LDAP integration Task turned into a week. Even with the deferred Task -- originally estimated at a day and a half -- there is very little left to develop. What lies ahead is testing, followed closely by fixes and refactoring, implementing a GUI redesign, and releasing to production.
I'm working with the Director to find a way to celebrate the completion of development as a team. I'm working with the PM to have our next project involve pair programming in an open workspace.
We had our final Iteration Planning meeting today. It was quick and upbeat. We ended up meeting our estimated velocity for the iteration, leaving us with only a day or two of Tasks left to do. The Director offered Friday afternoon as our "project celebration meeting", meaning we'll leave work early and have some drinks together.
By the end of the week, only Nate and I will remain on the project. Ralph will be adding features to an existing Dynamo application. Trevor will be working on adding features to an existing J2EE application. Matt and Steve will be pairing together on a new project, converting a small Perl web application to ATG Dynamo.
Matt and Steve will share the workspace with Nate and I. I see this as a very good thing, since it will keep our team intact.
We had an excellent post-development "meeting" at a local pub. A caricature artist happened to be standing outside the window we sat next to. After about 20 minutes he motioned to us. The Director spoke with him and returned with 2 drawings of the team. We decided they would be posted in our Workspace.
This project was a catalyst, gelling this group into a team of colleagues.
The formal QA process has thus far produced very little addtional work for us. The defects are entered into Rational's ClearQuest and I am supposed to resolve them there. I have successfully resisted this this artificial process (so far) by simply visiting the QA guy's cubical on a regular basis and discussing any problems he has come across.
I am the sole developer remaining on the project and taking the opportunity to reintroduce TDD to help nail down the defects. I'm occassionaly pairing with Ralph or Nate as their schedules allow. Trevor is pairing with a new hire to enhance an existing J2EE web application. Steve and Matt are pairing together on a small project. We're sharing the Workspace, which allows us to help each other very easily and keeps the team intact.
Speaking of sharing the Workspace, yesterday marked the departure of our roommates. We now have the room all to ourselves, including the whiteboard I have coveted for so many months.
The PM has told me that he would like me to present some of the agile practices we used on the project to our development department as a whole. This excites me.
The PM pushed the issue and I'm now using ClearQuest to "resolve" defects. Not a lot going on, most of the defects are related to perfecting the test environment's configuration. The rest are small, but I'm using the opportunity to build tests and refactor.
We should be getting the redesigned HTML in the next few days so that will be a bit of JSP work.
I just returned from vacation. The site went live while I was gone.
The two months after development concluded were mostly uneventful. There was a redesign and a QA phase. The redesign was much needed and has been warmly accepted. The QA phase revealed very few defects, but many outdated use cases.
I'm pushing hard to begin introducing automated acceptance tests as part of development. I have played around with jWebUnit and envision a QA guy and a developer pairing to write the tests. People like the idea, but I'm not holding my breath yet.
Our most troublesome hurdle in our move to production was ingtegrating with the production environment. We have much to learn in this regard. I met with the PM, the Director, and the Architect today to do a post-mortem of the intgration issues. It was a potential finger-pointing-fest, but it remained mostly cordial and a number of ideas were generated.
I am highly encouraged by our first attempt at agile software development. Two principles have been firmly adopted by the applicaiton development department for new projects: Pair Programming and Open Workspace. My current focus is on successfully introducing TDD for programmer tests and acceptance test. I hope to have another journal to share about this endeavor in the future.
|Home : Dave Hoover||Copyright © 2001-2004 Red Squirrel Design, Inc. All Rights Reserved.|