In response to a post Why Agile isn’t the answer., I received a reply that contained:
“We need a better name than specification for the what.”
I’m not about to suggest that the person replying was asking that we create yet another blanket term like Agile, but I nonetheless responded that we don’t need a better name.
The reason we don’t need a better name is because names are labels. The words Agile and Waterfall have become labels that divide. That’s why I use them in my post titles to attract interest so I can share valuable insight. But I’d rather be discussing my insight alone without any labels. I’d rather people judge the merits of a methodology without needing binary stereotypes–Agile or Waterfall–to decide if a methodology is good or bad.
Methodologies aren’t good and bad. They’re just methodologies. Much like a hammer can be used for good or bad purposes. Methodologies can be used skillfully and unskillfully.
Judge individual methodologies and judge them in the context in which they’ll be used. If you use a hammer to remove a nail from a board, the wood won’t splinter. If you use a hammer to remove a screw, the wood will likely splinter. If you know what you’re trying to accomplish, you can pick the best tool. Or even better, you can invent new tools that are a better fit.
Stop professing adherence to the one ultimate methodology. There is no one methodology, no two projects are ever executed the same. Learn practices based on hypothesized benefits. Mix and match as you desire.
In the spirit of this, here’s the practice that I hinted at in my prior post:
Practice: Setting goals and objectives upfront is a wise way to ensure a project will be worthwhile.
Elaboration: Goals and objectives are the WHAT and WHY. They are business outcomes. Business outcome means there’s a way to directly correlate them with creating value for customers. Goals are long term value, objectives are short to mid term outcomes that are predictive indicators of the long term value.
Example: Residents, in a nursing home, are slipping through the cracks at a nursing home. Not literally, figuratively. Let’s say there’s a noticeably high rate of residents missing physical therapy visits. And let’s also say that missing physical therapy visits quadruples the likelihood of a resident falling and seriously injuring him or herself. An objective might be to decrease the % of patients deemed slipping through the cracks (with missed physical therapy visits).
The goal is to prevent potentially fatal falls. A predictive indicator of success would be decreasing the % of patients from 20% which is the average for the last year, to 5% which is reasonable based on research that indicates it will be very difficult to decrease the number below 5% (for whatever reason).
Armed with this information, you have the context within which to carry out change and determine if you’re making progress. If you uncover a technology deficiency as the cause of missed therapy visits, then technology may be a solution. If you uncover a non-technical deficiency as the cause, then all the software in the world won’t help.
Benefits:
– Understanding long term goals and value garners commitment and provides the means to re-commit should other priorities arise.
– Objectives provide the context within which to pick a methodology (iterative, fully planned, or somewhere in between).
– Without objectives, most projects are doomed to failure.
– People often have a poor understanding of the business outcome of a project and thus have no ability to adapt because they don’t know what they’re adapting to accomplish. You’d be surprised with the most iterative of approaches, if there isn’t an established, communicated objective, there’s endless flexibility which really is a lack of flexibility.
Drawbacks:
– Requires an upfront investment in understanding goals and objectives. In many cases only a few hours are necessary. Nonetheless, not every initiative is important enough to justify this investment. You have to learn to discern when it will and won’t be beneficial.