No Excuse for No Requirements

Dilbert on Agile

It’s scary how common this situation seems to be.

So often as a developer, I find choosing to acquiesce in the client’s insistence that their enhancement or change is vitally important and, while they’re sorry it’s such late notice, needs to go out right away.

Rather than demand that I am supplied with at least some semblance of a requirements document (thereby incurring the Outraged Stare of Daggers), I reluctantly smile pleasantly and get on with adding the feature.

Problems can snowball

It should therefore come as no surprise to me (or anyone else) when, after the fifth “last change” the client comes back for, I find myself wishing I’d saved everyone the cost, effort and frustration of having things explicitly written down from the outset.  Yet this situation is just so very common that it makes me wonder why it’s such a hard lesson to learn.

The difficulty in these sorts of situations arises typically when the change being requested is “just a small 5-minute job” or when “the colouring-in department won’t approve this feature unless we change these items”.  Each concession on a development iteration creates a precedent that becomes the expectation for all current and future iterations.  In other words, each unmanaged change that is allowed through without written requirements carries an exponentially proportional degree of risk the further through the delivery process you move.

Why is this so difficult? Well, the client (or their appointed representative) has a great deal of personal ownership in getting the feature exactly right.  If they’ve forgotten or omitted to include a detail that – while arguably insignificant – they absolutely must have, they will plead, cajole, argue and assert their case to the point where it’s often easier to simply comply than to appear pig-headedly stubborn.  The downside here is that you create – or at least contribute to – a sort of Parent / Child relationship where one party is always trying to bend the rules or circumvent established processes and the other is always resisting the temptation to concede to those demands.  It’s unhealthy for your team, it’s unhealthy for your process and it’s ultimately unhealthy for your client because that risk adds up: either as technical / design debt, increased development and testing cost, decreased auditability of design, or any combination of these.

So what’s the solution?  To always say “No” every time to teach your stakeholders a lesson?  Say “Yes” every time and make sure you document the discussion somehow?  Neither of those options are realistic or sustainable.  The best approach is to ensure you have communicated a clear and consistent process for handling this sort of situation up front before the issue actually arises.  I’m a recent convert to the Lean Software Methodology because I like the freedom it offers for requirements changes as part of a defined process.  The specifics I’ve outlined for my stakeholders work like this:

• The development team works in 3-week development cycles with an additional week for requirements review and workshops (workshops MUST include people from development, business analysis and the client)
• Changes can be made at any time so long as those changes have absolutely zero impact on delivery timeframes or test effort
• Any changes can be added to the requirements but will only be commenced once development is complete on the originally-scoped requirements being used as the basis for the current iteration
• Changes that absolutely must be included in the current iteration can be included as long as all parties accept the delivery impacts and risks

To help make the Production Line run as smoothly as possible, there are some basic rules that will help grease the wheels:

1. Always have clear lines of ownership. Know exactly what you are supposed to do and ensure others know your domain of responsibility as well as theirs.
2. Know your environment. You can’t know everything, but what you can know try to know it well.
3. Always factor in at least 10% contingency.  Try to build a culture of “under-promise, over-deliver”.
4. Credibility is king. Don’t make commitments based on uncertain knowledge; always deliver on commitments.
5. If you find yourself in a hole the first thing to do is stop digging. Old cowboy saying.

All these strategies are well and good as long as the business have defined clear and thorough requirements up front, but I can’t stress enough the importance of rule number 1, above.  Make sure your production line process has clear expectations defined for not only what your outputs are, but what your inputs need to be.  The business has an implicit obligation to provide as full and complete requirements to you sufficiently ahead of time so that you can review them, refine them and respond with accurate estimates.  If you regularly find yourself in a situation where you’re being asked to “just sneak this one little change in”, something is broken. You owe it to yourself and your broader team to get it fixed. Fast.