Planning, Specifying, and Documenting
Big companies are well known for putting out complex products and completing complex projects, but they have a secret:
Planning and documentation.
Big companies love to plan. They love to document. They love to specify. When you work at one, it seems like that’s all they want to do: plan, document, and specify. But there’s a really good reason for it all: that’s the only way huge complex projects get completed.
Planning, documenting, and specifying should serve one purpose: to break things into small enough chunks that the complexity is removed. Once complexity is removed, then implementing becomes possible. Getting to the point where complexity is removed should take as long, or longer, than the implementation.
That sounds crazy, that planning should take longer than doing. But for complex projects, that’s the best way to assure success.
And in software development techniques like agile and scrum, that’s exactly what happens. At the beginning of a sprint, there’s supposed to be a planning phase to decide, “what’s going to get done?” But even before it can be decided “what” will get done, specifications on exactly “what” is need to be in place. Once that’s decided, then the things that make the list can get implemented. At the beginning of a project, most of the implemented items should be documentation and specifications, even (or especially) in scrum / agile.
Without quality specifications, how do you know if you’ve implemented something correctly?
You don’t.
But on small teams, or in small companies, often it seems like complex things just get winged. No documentation. No specifications. Just “make it work!” That’s a death knell. If you’re winging it, how do you know when it actually works? How do you know when to stop implementing? How do you plan your time or say no to additional features? It gets really hard.
External contractors never accept contracts that aren’t well defined. Why would they? How could they get paid if the customer can always say things aren’t done yet?
Why do small companies and small teams think they can treat their work any differently than a big company or an external contractor?