I encounter it all the time — the one-size-fits-all approach to developing software. The underlying methodology can be anything from waterfall to Scrum, Lean, Kanban, XP, etc. People often fall into the “that’s the way we have to do it” trap.
These one-size-fits-all (OSFA) approaches may arise when a team is successful and wants to repeat. They try to ‘bottle’ what worked and use it over and over.
OSFA can happen in the reverse too. A team fails and wants to avoid a repeat so they bottle-up controls, checks and audits, add them to their development approach, and hope to catch problems before they spill out.
It can be seen in any size company though is most common in larger firms. It happens in regulated and unregulated industries. You see it in government and non-government environments.
Many of us are comfortable with the OSFA approach. It gives us a sense of security in that we can approach every problem in the same manner and expect similar results. The project may take longer but at least we’ll get the desired result — we hope. (In practice the end result tends to deviate from the expected simply because the problem domain is different enough to cause new and unexpected problems.)
It’s not the least bit agile.
Even if an agile approach such as Scrum, XP or Kanban is being used, making every project fit a pre-defined set of detailed guidelines is not agile. Remember that stories are a basis for ‘conversation’ — exploration, discussion, collaboration.
Stories are not detailed problem statements complete with positive and negative outcomes. The engineers and scientists among us (myself included) find this discomforting. We want neatly defined problems that we can go off and solve.
The good news is that stories are a great way to draw out details and define work effort (yes, use cases work also). Some of your story estimates will be too high and others will be too low. If the team is generating good story estimates on average, the expected results should be close to the observed results. If not, use retrospectives to self-adjust.
I find that non-technical people are more comfortable with stories and their inherent lack of rigor. The business folks generally want the technical team to handle all of the error handling, scalability, performance, etc. details. (There will be exceptions to these observations, I’m sure.)
If you truly want to be more agile, that is, responsive, adaptive and accommodating:
- Ask more questions.
- Listen more and talk less.
- Be educated and then educate.
- Make small, short-term promises.
- Deliver, deliver, deliver.
Oh, and forget OSFA. Sure it works but it takes far too long and it’s just not agile. Keep your approach simple, high-level and adaptable. Monitor a small number of key metrics and seek continuous improvement.