09/04/2009
Methods Overview
Throughout the 90's there was a large push for software development to follow a Procedural (also called Waterfall or Critical Path) method of development. Organizations such as the Project Management Institute (PMI) became well known for providing certification to guarantee that projects follow these methods.
In the midst of the Dot-Com craze there was a bit of backlash as people realized that there must be room for exploration in any project. Terms such as "Agile Development" and "Rapid Prototyping" took center stage as "the correct" model of software (and business) development, and we saw how well that worked out.
The reality is that most professional software development teams can be described as falling somewhere on the spectrum of Iterative to Procedural. Many projects ideally start out more iterative, and become more procedural as they progress (see diagram).
(PDF - 44kb)
REMEMBER: Agile does not mean "Wing It"
Many developers confuse "Agile" with lack of a plan, but nothing could be further from the truth. Developers and stakeholders working on a prototype must be just as accountable to clear and consistent goals, deadlines, and deliverables as more procedural developers and stakeholders. The key difference is how goals and deliverables are defined.
Awareness and Clarity is Key
The larger the project, the more Procedural the overall project needs to be. As stakeholders and development teams transition from "Adding Features to an existing site" to "Building New Infrastructure" it's critical to focus on:
- Awareness - What is measured, improves. Simply making sure that everyone is on the same page in terms of where each feature is on this spectrum will make sure that people have realistic expectations. It will also ensure that developers and stakeholders have a common vocabulary to discuss what the goals are with each feature, as well as providing a tool to hold each other accountable to their roles.
- Less is more, except when it's not - The reason Dilbert is full of jokes about how committees can't make decisions is because there's a truth to that. We've all been in meetings where 10 smart people couldn't figure out a "simple thing." At the same time, we've all had plenty of cases where involving more people greatly enhances the end product. We call this "The Less Is More Threshold," and it's important for all team members to understand when this threshold is crossed for any given feature or project, and adjust roles accordingly.
- Change Management - Make sure you train and support your team as you become more procedural. This includes providing constant reminders of the changes, and focused support when Stakeholders or Developers feel that expectations aren't being met, or aren't realistic. Ideally this support will be in place BEFORE stress levels mount. Remember, stress only exists where there are unrealistic expectations.
- The Big Picture - It's also critical that someone is watching over the big picture of this project to ensure that adjustments are being made on this spectrum correctly.