Having been a software architect/programmer/consultant for over 16 years, I’ve worked on a lot of projects with a lot of different companies. A few years ago I learned about the concept of agile software development and specifically Scrum. There are founders, die-hards, and trainers out there that discovered, designed, and perfected practice of the various types of agile development – I won’t profess to be such. However, the core concepts of Scrum, gleaned from analyzing commonalities across high-performing teams, really resonate with me, and I’d like to share that today in a way that I often give to tech startup founders who don’t have a software development background.
Computer programming started out with plugging and un-plugging cables (see ENIAC on wikipedia).
In my early childhood, it progressed to tape, then punchcards. My mom used to bring home boxes of punchcards so that when I practiced piano as a wee short 6-year old, I could rest my feet on those, since they didn’t touch the ground. But I digress.
Developing software – compiling programs – took a long time. My father told me once that he had to be extra, extra careful to double-check, triple-check his programs because he’d be waiting in a hallway for hours while his program compiled. God forbid if he had a bug in his code, he’d have to start all over again.
Compared to that, we modern-day hackers are spoiled rotten. One button-push and a few seconds later, flashy splashy GUI mobile apps load up in a simulator or directly on our smartphone.
Just as the process of creating programs has matured and gotten more efficient and faster, the process for figuring out what product features to build, how to communicate that to the various stakeholders and team members (architects, designers, developers, quality assurance testers) has progressed similarly. Over the last few decades, up until the last few years, software projects followed a process called “Waterfall.” You start with the high-level bigwigs who want to create a product, presumably to make something easier, faster, or more lucrative. The bigwigs tell the project managers what they want. That goes in a business requirements document. The project managers work with business analysts to get more detailed and to a higher level of technical specificity. This gets turned into a functional requirements document.
Next the project managers engage with technical managers or architects to translate the functional requirements into even more detailed technical details – down to what the databases should look like, what the functions or classes or methods should be. That becomes the technical requirements document.
2 years and a 200% budget overrun later, the project fails either because it doesn’t launch at all, or because what’s built doesn’t match the bigwigs’ expectations/needs. There are many studies with varying statistics about software project failures: The Standish Group Chaos Report (1995) showed “31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost over 189% of their original estimates.”
What’s the deal? Basically, reality has shown that this expensive game of Operator isn’t the best way for the bigwigs to get what they actually needed. So, how do we ensure the communication path is straightforward, misunderstandings are corrected quickly, and the project is on time and on budget?
Enter agile. Enter Scrum.
Stay tuned for the next post, when the good stuff starts.