The Nimble Development Methodology
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 both1.
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.
Comments
Leave a Reply