Our Post-Mortem Review

We held our post-mortem review by telephone and discussed these simple questions:

• What went well ”what would you do more of on your next project?

• What went wrong ”what would you do differently on your next project?

• What did you get out of working on the project?

We present the anonymous answers to the first two questions as simple lists. These are the items our group shared and agreed on. For the third question, we let team members write about what they got out of the project. Russell has nothing to say; at this point, the persona has served his purpose and it's time to bid him farewell until the next time we need him.

What Went Well?

We each described the top three things that went well. Some of us mentioned the same items. The following list collates our thoughts.

• Using Groove . Groove made it possible for us to collaborate in a way that would have otherwise been impossible .

• The team made the project fun. We were able to find ways to overcome many types of adversity. We didn't always agree with each other, but we still worked together effectively.

• Focus on the user experience. It was educational to see how focusing on the user experience and the users' problems directed our solution.

• Pair programming . It was effective to experience the benefits and the teamwork that resulted from pairing .

• Using Eclipse and Rational XDE. This IDE was the best one we've encountered in terms of the features it provided and the ease of use. The IDE helped us rather than got in our way.

• Russell . It was great to have "Russell" available to keep us on track and provide user input.

• The project wasn't a "death march ." We had enough time to think about what we needed to do and then do it.

• Just enough process. We didn't let the process get in the way. For some of us it was the first time we had the ability to do "the right thing" when it comes to process.

What Would You Change?

Another way of asking the question is: What didn't go well? Our list follows .

• We should have found a way to get on track earlier. We spent too much time waiting for John to deliver something. We should have found a way to help him succeed on the project or provided him an opportunity to leave the team earlier.

• We should have spent more time at the beginning on team building. We would have easily made up the time during the rest of the project.

• Those of use who were co-located, even if in separate buildings , should have met face-to-face more often.

• We should have spent more time on unit tests and been more serious about using Test-First Programming and JUnit for all of our code.

• We should have all used PSP Tools for our work. The only one who really used it was Gary.

• We should have enlisted a separate, experienced tester much earlier.

• We shouldn't have had the same person fill the project manager and architect role.

• We overused Groove . Groove is great for many things, but, for example, we quickly outgrew the benefits of using Groove for recording our defect tracking. We should have taken the time to install and use a real defect-tracking system.

• We should have tried harder to get more Beta testers.

What Did You Learn?

In this section, we each contribute a personal note about what we learned on the project.

Gary

This project was my ideal type of project. It was fun, small, and successful. The bonus, and the thing that made this project special, was the team. I'm sorry that we've completed this. Maybe we'll work together on something else ”I hope so.

I've been fortunate to have spent several years of my career working and studying with exceptional people. This team is a group of such people and I'm honored to be able to call them my teammates. I've always been saddened when the group breaks up ”which is inevitable. I am saddened now, but value the time when we walked the same path together.

In the last few years I have gotten away from software development. I learned how many new things there were to learn and re-learn. I remembered how much I like building software. There is always something new to learn. When I stop learning, then I'll know that it's time to stop working. I can't imagine that happening.

If I had to choose one thing that I remember most about the project it's this: the PSP Tools project fits my definition of what meaningful work should be ”useful to someone else, useful to me, something I want to do, and fun. It was all that and more.

Another thing that I treasure about this project is the fact that we were able to take it from start to finish. We didn't quite keep a complete record of the things we wanted to capture. We did deliver a product. As with most real projects, we didn't implement all the features we wanted to, and we did introduce a few minor defects that we didn't fix. That is always a humbling experience, but it shows how much opportunity for improvement we have.

When I looked back at some of the code I wrote, I realized how I could make it better. I think that is a good thing. It means that I'm learning still (or it means I have really gotten out of practice). Some of my code truly "smells," as the XP community might say. But, I can make it better, and I will. If you download the code from the book's Web pages, you may notice areas that we've improved since we wrote this book. The code is still not perfect, but we're improving it incrementally. I look forward to the challenges that await me on the next project. I hope I've learned something about people, process, and tools on this one that will serve me well. I think I did.

Jas

Looking back, a lot of life got in the way of our schedules; however, we did meet our overall plan to get to the end with a working product and, hopefully, a useful description of how we got there.

What worked well was having a shared workspace (Groove) to post our ideas, and our regular meetings to maintain the project momentum. Once we established the rhythm of meetings, our activities ”the process of posting and testing builds, and creating issues for further work ”fell into place. I was glad that Gary and Chris created the easy installs to facilitate the user experience with the product. On the negative side, I lost some would-be testers who got too frustrated with the product to give it another shot! As a tester, I must confess I was appalling ”"forget the test cases let me just have a go at the product." Exploratory testing is a lot of fun! However, when I did uncover bugs that way, it was often hard for me to retrace the steps that got me there, providing little value to Gary or Chris. Sorry, guys, I did say we needed a "video test lab"; then you could have seen what I did.

All in all it was a great experience. To paraphrase Christopher Alexander of "Pattern Language" fame, "It's not just the alphabetics of putting together the various bits and pieces to make the final product, but how much satisfaction people actually get from interacting with the result." From the outset I saw the book project as a journey and a team experience. We in the software business have our own "alphabetics." We created the various artifacts required to build the product. But much more than that, we kept together as a team across the continent and in different countries , through the dot.com and then the dot.bomb era.

Now that we're done I will miss the team, Gary's biannual visits , and our treks to various restaurants . It will be interesting some day to actually meet up with Chris. 'Til the next time.

Liz

For years, I'd read about, discussed, and even written about ideas and trends in the software development world. Now that I've worked on this project, I have actual experience with these ideas, and I can speak more knowledgeably about them. For example:

• RUP is a large knowledge base providing guidance to team members engaged in software development. However, it is just as reasonable to use RUP on a small project as it is to use it on a large project. The key is that for every project, you need to customize RUP to your own needs.

• Agile processes offer much of value, but again, you need to customize these processes to your project's needs.

• The real value for us was to customize a process that combined the best of RUP and agile processes.

In the tools arena, I of course felt comfortable using Rational tools. However, I was delighted to learn about other tools of use to members of small teams. Groove, of course, stands out as the tools workhorse. On future projects, I'd like to branch out and learn about other widely available tools that are useful to small teams .

And finally, a few observations about the people aspects (the "soft side") of the project:

• Life is about change, and we certainly experienced a lot of it during the project ”deaths of several parents, layoffs, job changes, vacations , company buy-outs, completing our "real-work" projects. Some of these changes slowed us down, but they didn't derail us. I'm especially proud that in spite of real life's intrusions, and perhaps because of it, we maintained our focus and finished the project.

• The incident with our fifth member, "John," reminded me of a lesson I learned long ago ”that sometimes you need to cut your losses and move on. I think that John and the rest of the team got stuck in the thought that we needed each other. Yet, when the time you're taking to manage a situation outweighs the benefit you're getting back, you need to recognize that you're not making progress and fix the problem. I was proud, though, that when we parted ways with John, we left things on friendly terms; his departure from the team didn't seem to affect our personal relationships with him.

Bottom line: ould I sign up again for a similar project? You bet. I had a lot of fun, learned a lot, and believe that I contributed substantially to the project.

Chris

I've created a simple list of the three main things that I took away from this project:

• Write unit tests as you code. Use Test-First Programming. Telling yourself that you'll write unit tests later rarely works. Write the tests and then write the code to make the tests pass. It's much easier to modify the classes later and know that they still work, because the tests still pass after you change the code.

• Plan a directory structure, and keep asking if this file belongs somewhere else. Be really tough on yourself about this. A well-organized file structure with good file names makes it easier to maintain the code.

• I am much more comfortable with Java. This was one of my stated goals. I took this skill back to my workplace and spearheaded Java efforts in my real job.

Conclusions

The post-mortem review is a time for closure. It helps the team tie up loose ends and get ready for the next set of challenges. It also gives the team time to say good-bye to those who will be moving on. Our review and the opportunity to share our comments with you have been important and cathartic for us; we hope our observations are helpful to you.