My First Agile Project

My first agile project was a re-write of an existing system.  The existing system was written in an early version of Java 1 and morphed as time passed.  It was a desktop-based application.  This re-write project was going to go through a full requirements gathering phase, design the application for scale, integrate it into the existing ERP system, and put it on a newer Java 1.2 system.

I joined the project part-way through the requirements gathering, and participated in many of those meetings.  These meetings were quite often contentious.  Many people had many opinions about what the new system should do and how it should do it.  Most of the people from the IT team were worried about the project.  The senior architect suggested that we use a new approach called Extreme Programming to deliver the system, hoping that the new approach would address many of the concerns.  I eagerly read the first Extreme Programming book, and got very excited.  The author spoke directly to all of the problems I encountered during my first internally-focused project, and his suggested approach made a lot of sense.  We were able to convince our management to let us try it.

We set up an area for the project team to work.  It contained open tables with shared computers.  Everything was arranged to make it easier to do paired programming.  The machines were configured identically so that it was easy to move around.  There were about six developers assigned to the project, along with a DBA, project manager, and architect.  We also identified a business user that would be available to test the system and answer questions.  With everything in place, we jumped into the Extreme Programming approach.

I don't remember how we prioritized the requirements, but we had a list of stuff to attack in order.  At every iteration boundary, the group would gather together with flip charts for planning.  We would write a feature/requirement at the top of the flip chart, talk through the tasks needed to accomplish it, and put estimates to the tasks.  We hung the completed sheets on the walls around our meeting area.  After several requirements had been planned, we picked what we thought we could get done in an iteration.  Those charts were moved to the walls around the programming area for the team to see.

Every morning the team met for stand-up, and talked through who would work on what task.  If there were any major roadblocks we talked about them, and tried to align the pairs to knock out the road blocks.  If there wasn't a particular pairing necessary for the tasks at hand, we picked pairs based on who was available and who had a task, and started our day.

The pairs worked side-by-side in the pairing area.  The keyboards and mice would move back and forth as pairs alternated coding, and if a pair got stuck, they would ask another pair for help.  Coding went fairly smoothly and efficiently.  Occasionally some personalities would clash, but either the project manager or architect would help defuse the conflict.  This was one of my favorite times writing code because it was productive, efficient, and the camaraderie was great!  Our progress through an iteration was tracked with burndown charts plotted on a big flip chart on the wall.

As features/requirements were completed, we brought the business user over to test the features.  Any identified bugs were addressed right away, and the user would test again.  We typically brought the business user over as features were completed; we didn't wait until the end of the iteration.

This project progressed well until we came close to a busy season in the company where the original tool was used heavily.  The company wanted to use the new tool for the upcoming busy season, which pushed us to work longer hours and aggressively trim scope.  Ultimately, we delivered the first version of the new system to the team that needed it most for the busy season, and brought other teams on board over the coming months.

Being a first agile project was difficult for a few reasons.  First, the rest of the company didn't understand the agile approach, and put a lot of pressure on the team to do things differently.  Second, the team was learning a new approach, which made it difficult to communicate with the rest of the company and each other.  Lastly, some of the team members hadn't bought into all of the Extreme Programming practices (most notably unit testing), and that difference sometimes caused more friction on the team than was necessary.

I view this project as a success!  The company got a system delivered when they needed it.  The applicaiton was very well designed and well written.  The team of developers gelled pretty well, and continue to stay in touch with each other even though everyone moved on from that company.  It also solidified for me the importance of culture within a development team, as well as how many of the agile practices influence the quality of software.

Now it was time to mature our practices and move them forward.