{"id":12840,"date":"2017-06-12T18:25:04","date_gmt":"2017-06-12T17:25:04","guid":{"rendered":"http:\/\/blog.intercom.com\/?p=12840"},"modified":"2020-07-30T12:57:56","modified_gmt":"2020-07-30T11:57:56","slug":"the-right-amount-of-process","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/the-right-amount-of-process\/","title":{"rendered":"Having the right amount of process at your startup"},"content":{"rendered":"

Discussing software development and engineering processes is a great way to end unwanted conversations at parties.<\/p>\n

Dull because it feels like a long-answered question. In the dark old days we used waterfall<\/a>, now that we have iPhones and reality TV, we use agile<\/a>. It could be an agile scrum, kanban or a process you\u2019ve built yourself<\/a> but the debate is over: everyone\u2019s agile now.<\/p>\n

These engineering processes are comforting, especially at a startup when it feels like you\u2019re flying the plane while you\u2019re trying to build it. Having any plan is better than no plan, right? Not really. Companies that insist on having a set process in place before they build product are doomed to fail because they\u2019re starved of feedback for too long. Make sure your process isn\u2019t sabotaging progress.<\/p>\n

Where did it all go wrong?<\/h2>\n

If you\u2019re lucky enough to be unfamiliar with the concept of development processes, they\u2019re the way software teams figure out what needs to be built, how to prioritize it and who should do the work. It\u2019s not a complicated idea, though there\u2019s a whole industry of training and certification that would like to convince you it is. Waterfall is a \u201cfigure everything out before we start\u201d model, loved by banks and insurance companies. Agile is more a \u201cfigure it out as we go\u201d model, loved by tech companies and banks trying to look cool.<\/p>\n

Sometimes we tightly grasp our agile artifacts and rituals but stubbornly insist on stepping back to the last century. The worst outcome? Building something we know is wrong because our process won\u2019t let us stop. To better understand how we construct these traps for ourselves let\u2019s look at where the old way, waterfall, came from.<\/p>\n

Back in the 1950s people had seen small teams of competent engineers successfully deliver small- to medium-sized programs. Logically, if small teams make small programs then big teams make big programs. Round up a hundred people who can type, show them a computer and you\u2019re ready to go! Naive but understandable in the first days of our industry.<\/p>\n

Unsurprisingly, this way of thinking didn\u2019t work so well. Herbert D. Benington, one of the contributors to SAGE<\/a> \u2013 a US defense project that ran considerably over time and over budget, distilled the lessons of big projects into a paper: Production of Large Computer Programs<\/a><\/em>. Page 11 has this diagram:<\/p>\n

<\/p>\n

Herbert didn\u2019t call this \u201cwaterfall\u201d – that name wasn\u2019t coined until the 1980s – but it\u2019s exactly as we\u2019d understand it. Figure out the problem, figure out how you\u2019re going to solve it, design, build, test and ship. It\u2019s a non-iterative flow of discrete steps drawn from the manufacturing world where the cost of change increases dramatically the later it comes in your process. As an industry we love to borrow from this world, taking ideas like Scrum and Kanban from auto manufacturers and photocopier makers.<\/p>\n

When waterfall starts creeping into agile<\/h2>\n

Everything changed in 2001 when a set of principles were nailed to a pixelated photograph and the Agile Manifesto<\/a> was born. The four core values are a huge mindset shift from the waterfall diagram above:<\/p>\n