The Agile E-Mail

I recently stumbled across the following e-mail. It was sent on Friday, March 01, 2002 at 2:12 pm to the project manager of a team I’d just joined. It has not been modified, aside from stripping out e-mail addresses and a few names in order to protect the innocent (and guilty) :-).

It was sent after I was brought onto a development team as a software developer at the beginning of February, 2002. I quickly realized the path the team was taking, and it was not good. When I arrived, the team was meeting with clients, developing design models, and spending a lot of time trying to figure out what to do and how to do it. But they weren’t actually doing anything.

The response was astounding. We began to change what we were doing. We started writing code, sharing the system with our customers, taking their feedback, and making improvements. It worked well, and several months later, we delivered a great system – on time. It was not easy. Some of the changes took months to implement, not because they were technically difficult, but because there were significant cultural and legacy process issues to overcome.

I still believe in the ideas expressed in this e-mail. I would send it again today, almost verbatim, if I were in a similar position.

Here are some of my initial thoughts. Some are a bit random, and if you’d like to discuss any of them, feel free to holler. I’m really dumping a lot of thoughts here, and I apologize for that. In addition, some represent personal recommendations based on what I’ve found useful on past projects. It’s quite possible that a lot of this stuff has been considered, but I just haven’t crossed paths with it yet. If you’d like to talk about this, either one-on-one, or in a group setting with Mike, Jim, Bill, Susan, etc., we might find it to be a valuable discussion.


  • Architecture proof – A proof has many different levels of detail. I don’t feel that a proof needs to prove the feasibility of the entire application architecture. Instead, we might consider emphasizing the critical aspects only. For instance, CMS connectivity is a big issue. While we may want to prove that we can effectively pull documents from the CMS using Java and COM, I’m not sure it’s necessary to consider any business process related issues in the proof. The underlying technical implementation of any piece of the system can be separate from the business process supported. The proof need only emphasize this underlying technical implementation. As such, I’d favor many small proofs that test the ease with which we can connect to the CMS, Natural Adabas, CTG, etc. In addition, proofing will be something that we must continually do. New issues will arise months from now that will need to be proofed. We can, however, start a lot of this stuff right now.
  • Horizontal frameworks – These are system components that are not reliant on the functional requirements. They represent complete and reusable components. For instance, items that fall into this category are database access (ensure a consistent db access mechanism regardless of whether we’re hitting db2, Natural Adabas, etc.), error handling, auditing, connection management, document generation, security. This represents a lot of the “plumbing” necessary to begin implementing the functional requirements using vertical frameworks. We can start a lot of this stuff right now, though we’ll try to keep it fairly lightweight to ensure we don’t over engineer.
  • Vertical frameworks – These are dependent on the functional requirements. These vertical frameworks help enforce consistency across use case implementations. Vertical frameworks use a bunch of the horizontal frameworks, the results of the proofs, and add all the business functions necessary. Examples of this include workflow, journaling, and claims. We need the functional requirements to start this stuff.

Team Structure

  • Development Environment – All developers need a consistent development environment set up. We need to make sure everyone is using consistent versions of Java classes, jars, etc. We can start this right now.
  • Geography – It would be ideal if all team members could sit in a central location. Ideally, this location would have access to as many whiteboards as possible.
  • Team Structure – We might consider a few different options on structuring the team. Presentation developers, back end developers, etc. would be one option. Another is to divvy up based on use case.

Development Process

  • Iterative – Shorter and full lifecycle iterations will hopefully help us minimize a lot of the typical late project woes (ie. integration, test, deployment).
  • Continous Integration – We should always keep integration in mind. Ensuring a system is always completely integrated avoids the big bang integration nightmares at the end. While things will move more slowly at first, we should see the advantages of this as time progresses.
  • Continous Testing – Developers must test the code they construct, and test it fairly often. It’s effective to write code that automates these test cases. This way, test cases can be run frequently. Top priority should be to fix any errors. If we can keep on top of this, we’ll *always* have an application that is as fully functional as the requirements it presently supports.
  • Continous builds – Compile errors should be fixed immediately. Applications that don’t compile don’t work. When code is changed, it should be built, then tested, then integrated. An automated application build set up to run nightly would be valuable.
  • End-to-End – After we’ve got some of the proofs in place, it’s important to implement an end-to-end solution as quickly as possible. This would be fairly lightweight, and may not do much to support the overall business process. By definition, I think this is what some of us are presently calling the architecture proof. The only problem with treating this as the architecture proof is that there are a lot of other things (horizontal frameworks, technical proofs, development environment, etc.) that should probably be done first. This end-to-end solution includes not just code, but a build process, testing, versioning, deployment, etc. As we build this end-to-end solution, we would continue to fill in the gaps of our horizontal frameworks. We would continue to add to this end-to-end solution over the course of many iterations.


One thought on “The Agile E-Mail

  1. Thanks! Great insights!

    Too many teams are stuck doing nothing! I like to get teams to do the “figuring out what to do” in a productive way. In XP they call these spikes, others call it a set based approach. In other words, let’s get our hands dirty trying a few things. Will learn more and end up with options and a better product.

    Rod Claar

Leave a Reply

Your email address will not be published.