In software development, “lightweight” methodologies are gaining ground on more traditional “heavyweight” methodologies. Both have their advantages and disadvantages, and which one you choose depends in large part on your needs. I’ll examine some key differences between lightweight and heavyweight development methodologies from the project manager’s perspective.
Bringing order to chaos
Project work is often a chaotic activity that can be characterized by the axiom “fighting fires.” Projects often begin without much of an underlying plan, and designs frequently change due to “bleeding-edge” technology issues or even a focus on the wrong solution.
Sometimes a project is simply cobbled together out of a series of quick-paced decisions. This can be effective if the project is small, but as the project grows, it can become increasingly difficult to add new features. The larger a project gets, the more your project management skills are tested. Furthermore, mistakes become increasingly prevalent and increasingly difficult to fix.
Let’s look at a practical example of a large-scale development project—building a space shuttle onboard navigation system. The application begins with a blueprint that is based on numerous aeronautical and mathematical calculations. The project adheres to this blueprint at all times. Any change to the blueprint can kill the project. The tools and materials used to build such shuttle applications are costly and specifically developed for the space shuttle fleet. These are highly tested and validated systems. Everything needs to be planned far ahead on such a lengthy project, and management likes it to be predictable. They have this down to a fine art.
But when we compare such a large and highly focused project to developing software in general, we see something different—and scarier.
The main difference is that the highly structured “heavyweight” methodology used by the shuttle designers is predictable, while the flexible “lightweight” methodology used to develop cutting-edge software solutions is not. These solutions use new technologies and designs and, therefore, the associated risks are very high. As we’ll see, the practical considerations of developing software for a client also factor in to the decision to adopt a particular methodology.
Selecting your methodology
There are numerous software development methodologies in use today, and the list grows daily. Some companies have their own customized methodology for developing their IT applications, while others simply use off-the-shelf commercial methodologies, such as PMI’s PMBOK (Project Management Body of Knowledge). Choosing the wrong methodology can be a critical blow to your project. The essential points you’ll need to consider when selecting a methodology are:
- Budget
- Team size
- Project criticality
- Technology used
- Documentation
- Training
- Best practices/lessons learned
- Tools and techniques
- Existing processes
- Software
Assessing heavyweight methodologies
The traditional project methodologies that many top corporations use, such as the SDLC approach, are considered to be bureaucratic or “predictive” in nature, and they’ve resulted in many unsuccessful projects. These “heavyweight” methodologies are becoming increasingly unpopular. They can be so laborious that the whole pace of design, development, and deployment actually slows down.
Heavyweight methodologies try to plan out a large part of a project in great detail over a long span of time. Project managers tend to want to predict every conceivable project milestone because they want to see every technical detail. This leads managers to demand all sorts of specifications, plans, reports, checkpoints, and schedules. But this works well only until things start changing; therefore, I believe project managers who use heavyweight methodologies will resist change.
The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment, whereas lightweight methodologies propose executing the project steps in parallel. For example, the manager of a project that is based on the heavyweight methodology won’t agree to build the IT solution until the full requirements have been determined, and so it continues for each project phase. Still, any project team larger than 10-20 people and working in multiple locations may be a good candidate for a heavyweight methodology. Heavyweight methodologies can be the better choice when you have multiple teams working at different locations and you need tighter control to formalize key parts of the project.
Demystifying lightweight methodologies
The immediate difference between lightweight methodologies and older methods is that lightweight methodologies are much less document oriented. Lightweight methodologies tend to be code oriented, meaning the team considers the source code to be the project documentation.
Here are some of the advantages of lightweight methodologies:
- They accommodate change well.
- They are people oriented rather than process oriented. They tend to work with people rather than against them.
- They are complemented by the use of dynamic checklists.
- The project teams are smaller.
- They rely on working in a team environment.
- They foster knowledge sharing.
- Feedback is almost instantaneous.
- The project manager doesn’t need to develop “heavy” project documentation but instead is able to focus on the absolute necessary documentation (e.g., the project schedule).
- They are learning methodologies. After each build or iteration, the team learns to correct issues on the project, forming an improvement cycle throughout the project.
The smaller, more frequent cycles in lightweight methodologies also provide more opportunities for stakeholders to review the project definition and redefine it as required for new business needs. After each iteration, you should demonstrate the prototype to the client and collect any feedback. You can then add new requirements and changes to the list, adjusting priorities accordingly. This way, the project manager ensures that the development team is working on those aspects important to the client. After the final demonstration, you can collect feedback and conduct a gap analysis to identify any outstanding functional requirements needed to move the application into production.
Another benefit of lightweight methodologies is their focus on producing value-added releases and addressing architectural risk early in the project. This helps ensure that the finished product meets expectations and that the stakeholders will perceive it to be “a good value.” The project manager can therefore give the client a release of the application much earlier in the project plan than would be possible with a heavyweight methodology.
User requirements
User requirements play a key role in every methodology, whether light or heavy. It’s one of the initial steps that must be determined by the project/development manager. In fact, you can’t start a heavyweight methodology without user requirements. Even a lightweight methodology needs a limited user requirement definition to get going.
You could argue that it’s wise to set some basic requirements and the scope of the project prior to the project start to prevent too many changes, but in today’s fast-changing technological environment, clients often don’t know what they want until you show it to them, and they rationalize that they can’t fully foresee the functionality of the application. Many clients prefer that you walk them through the project in smaller iterations and then pay only for what you build. So if you’re working with a client that constantly introduces changes to the design requirements, a lightweight methodology may be a better choice.
When it comes to shorter project life cycles, especially in Web development, I think the only approach is to adopt very light methods. Requirements gathering will still be part of it, but the key is to identify the immediate requirements and implement them while keeping future requirements in mind.
So which is best?
Alistair Cockburn, founder of the Crystal methodologies, says a methodology is more likely to be used if it is simple, clearly effective, and small in terms of required work products. The acceptance of a methodology is limited by the group’s ability to change its work habits and by its tolerance for seemingly bureaucratic content.
I’m convinced that the lightweight methodology approach exemplified by XP, Crystal, Scrum, Open Source, and ADM will become more popular for smaller teams, and that larger, decentralized project teams will, for the time being, continue to use heavyweight methodologies.
In my next article on development methodologies, I’ll examine the different types of lightweight methodologies project/development managers typically encounter, and how they compare to one another.
