Many principles behind nimble development become natural over time. The nimble approach requires a quick assessment of an entire project with the goal to identify the key components, the moving pieces, the critical functions. Those are the first things you’ll build.

What you build at first doesn’t have to be great. It doesn’t have to have a fancy interface or complete screens. Under the hood it just needs to work. Start simple. If you build something simple at first, you’ll be more nimble later on.

It is important that you have something working as early as possible and that you complete the loop. Most likely the project is to build or program some functionality that has some sort of start and finish. For example: create user, read user, update user, delete user. Understand the life cycle of what you’re doing. Identify it at the beginning of every project you start. It’s there and it’s critical.

Then write it down where others can see it and edit it. Because others on the project, probably yourself, will ask it many times. More important is how you’ll use it to stay focused.  It’s a shield, cattle prod, a shepherd’s hook, to guide us away from the dangerous scope creep cliffs¹². Writing down the critical path of your project is like putting a stake in the ground. You can point to it and say, “we must stay close to this.”

The following must be asked and understood by those designing, building, and supporting a product. Every person working on a project, trying to understand the details and scope of a project, inevitably makes decisions based on insufficient or incorrect information. Document collaboratively the answers to these questions and the result will be a more nimble solution in less time. Someone on the project will need to know the answer to at least one of these questions.³

• How will this be used?
• What components will we use to make it work?
• How will the new and existing components perform together?
• Are we using the most appropriate technology and design?
• How will we release this for testing and use?

Whatever you build shouldn’t break what already works. The less that has to be tested the better. The less stuff you interfere with the better. Implement new functionality in a way that doesn’t break what already has been tested and released. Being nimble means knowing how to avoid sticky and slippery areas.

1. Flashback: Catcher in the Rye. [↩]
2. I used to be very, very good at this. I first heard this term from my manager, urging me to stay focused on what needed to be done. [↩]
3. Rainwater, J. Hank. (2002), Herding Cats: A Primer for Programmers Who Lead Programmers. Apress. Page 109. [↩]

In software and web development what matters most is what you deliver. If you don’t deliver something, a piece of software or service, you’ve got nothing to sell. And when you do deliver something, you can’t neglect it or the cries for help and improvement from your customers. Being nimble is critical to success.

For a business whose product is ethereal in nature and whose usefulness depends on human interaction and the flow of information, there is a constant challenge of deciding what to do next. What design, bug fix, or new feature will ignite and keep the interest of your current and future customers?

In some development organizations, a development leader’s job is not to decide what new design or feature will bring in the money. Their job is to build whatever upper management says. This means being able quickly understand what is needed, how it relates to what already exists, and the ability to quickly assess and devise solutions to the problems of implementation. The sooner something is released the better. Sales and marketing count on it.

New information, the world economy, and a zillion other things can cause priority to change, forcing a shift in attention from one thing to another. Oftentimes customer need or competitive market forces result in new projects that quickly become priority, jostling for position with existing high priority projects.

There are many types of development methodologies out there promising high quality, low cost, and short turnaround times. They typically fall into one of two camps; waterfall or iterative. Waterfall methodologies break projects down into distinct stages and roles while iterative methodologies focus on the deliverable itself with one team seeing the project to completion. There are advantages and disadvantages to both¹.

To survive in any development organization, a nimble approach is needed. When you are told to deliver something and you have a small team of people to do it, an iterative approach seems reasonable. However, not all small teams are tightly knit and cohesive just because they’re a small team. You might also have to work with other small teams from time to time. Unless there is sufficient communication, planning, discussion, and collaboration during a project, the chances of it being high quality, quick to build, and with low maintenance, decreases.

The Nimble Development Methodology is a hybrid of the waterfall and iterative methodologies. Small development teams work together from beginning to end and focus on building and delivering something functional by discussing, designing, defining, and documenting the project collaboratively throughout the development process. The key to nimble development is the focus on project components in order of their criticality.  This encourages the delivery of something useful, though sometimes minimally, in the  shortest amount of time. By documenting just the right amount during development, when attention and effort is shifted to something else, enough detail is left to make it easy to pick up where it was left off.

Nimble development is all about quickly assessing, understanding, and addressing the most critical aspects of a project in order of importance. It then becomes a matter of developing and releasing in that order. This might mean working on the hardest part of something first, but this approach increases the odds of delivering something useful in the shortest amount of time. It also allows for quickly shifting gears toward or away from new or existing projects.

Using the nimble approach, documentation and requirements are created, maintained, and adjusted every step of the way. Using a wiki or other collaborative document application, project requirements, specifications, and notes such as future concerns, ideas, deployment needs, and system configuration notes, are written in concert with development by the architect, developers, analysts, and managers working on the project.

1. See here for a pretty well written comparison of the two methodologies. [↩]

Trac is a development team’s dream.

Subversion an engine upon which Trac draws, but it has equal power in other areas.

It’s Wiki for example. Or the RSS feed provided by the timeline…which means filthy integration potential for IDE plugins for which a number have already established footholds for Eclipse and Visual Studio.