Whether you are a development manager, project manager, business analyst or newly titled SCRUM master, you may be employed to bring a solution to the prioritization of the never-ending onslaught of software development work for your company. In order to do this, you'll need to enlist a specific software development methodology, but which one?

Weeding through the acronyms

The list of methodologies is an alphabet soup of acronyms like RAD (Rapid Application Development), ASD (Agile Software Development), RUP (Rapid Unified Processes), DSDM (Dynamic Systems Development Model), FDD (Feature Driven Development), and LD (Lean Development), and there are still others with more traditional names such as SCRUM and Waterfall.

Prior to beginning any development project, a careful examination of each of these methodologies, weighed against the culture and needs of your organization, and your personal management style are always in order.

All of these methodologies are Agile (ASD) methodologies, though they vary in form from a little to a lot. Most, however, have several items in common — short-time boxes, face-to-face or real-time communication and a regular re-examination of priorities, just to name a few.

SCRUM is one of the most widely used of methodologies and is, in fact, not an acronym. SCRUM was brought to life by Hirotaka Takeuchi and Ikujiro Nonaka in their ground-breaking 1986 paper "New Product Development Game". SCRUM is an Agile method of project management.

Notice that SCRUM drives project management, not software development. This means SCRUM can be utilized for any number of projects, not just software development. Personally, I have utilized SCRUM for construction projects, hardware rollouts, and home improvement projects. I even attended once a seminar with several friends where we prepared a steak dinner using the SCRUM methodology.

SCRUM is characterized by:

• A living backlog of "items," or things you must get into the queue or "get done"
• Categorizing these items into a "sprint," a short burst of work on these backlog items, ranging from one week to four weeks
• A brief daily meeting called a SCRUM; typically everyone stands during these meetings
• A brief planning meeting where the backlog items move into the sprint
• A brief retrospective meeting where the team members reflect on the last sprint

The SCRUM approach is widely popular because it enables a form of communication across all disciplines that may not normally exist in an organization. Everyone gets a voice, and personnel who don't normally speak are heard. Another benefit is the process control that SCRUM promotes. Things don't get done without everyone knowing and they don't fall off the board.

There are few shortcomings to SCRUM, but opponents will tell you that SCRUM contains too much process, too many meetings, and allows paper-pushers to run your company. In my opinion, if you don't like holding people accountable, or wrestling with a lot of paperwork, then you won't like this methodology.

Another important agile methodology for software development is Feature Driven Development (FDD), pioneered in 1997 by Jeff De Luca for a 15-month, 50-person software development project.

FDD is premised upon six general concepts:

• A system for building systems is necessary in order to scale to larger projects
• A simple, but well-define process works best
• Process steps should be logical and their worth immediately obvious to each team member
• "Process pride" can keep the real work from happening
• Good processes move to the background so team members can focus on results
• Short, iterative, feature-driven life cycles are best

FDD addresses the concepts above with this simple process (numbers in brackets indicate project time spent):

• Develop an overall model (10 percent initial, 4 percent ongoing)
• Build a features list (4 percent initial, 1 percent ongoing)
• Plan by feature (2 percent initial, 2 percent ongoing)
• Design by feature
• Build by feature (77 percent for design and build combined)

FDD is popular for its speed to market, priority setting focus, and "git-r-dun" feel. Opponents of the FDD methodology, however, are quick to point out that there isn't enough communication or touch-points with the real stars of the project — team members. FDD is also limited to Software Development for its use.

Often considered the classic approach to systems or project development, the Waterfall model describes a development method that is sequential, rigid and linear. Waterfall development has distinct goals for each phase of development, where each phase is completed before the next one is started, and there is no turning back without great expense in time and money. An example is a house being built — pouring the foundation must occur before the walls are built.While SCRUM and FDD are agile methods of Software development, some organizations choose to go back to more rudimentary or traditional development methods and employ a non-agile method of project management known as Waterfall, called by some the "original development model".

The Waterfall method used to be more popular when projects were less collaborative and the workforce less communicative. I believe this methodology will become scarce in large, complex and thriving organizations in the coming years.

Choose your own adventure

With all these choices available, what is the best way to choose, implement and keep a methodology going throughout your organization? The best answer is part knowledge and part understanding your organization. In other words, a mix of skill and art.

The knowledge part is easy. Getting a SCRUM master certification, for example, will take an average person a few weeks to achieve. You can even sign up for a boot-camp that will guarantee certification within a week. This is the "skill" part of the equation.

The "art" part of the equation is your organization's culture and appetite for a particular methodology. You have to feel your way through.

No matter which methodology you choose to enlist, one thing is certain: You must stick to the fundamental items of that methodology. For example, you cannot run SCRUM and not hold daily stand-ups, and you cannot employ any Agile methodology and not reexamine priorities on a recurring basis.

While it's true that "no plan survives first contact with reality," once you choose your method of development you must adhere to it as closely as possible and be diligently loyal in its execution.