A lot of talk has been given in the last 10 years to the concept of Agile Development. Since it’s creation in 2001, it has swept the software engineering industry. I remember first hearing the about it back in 2013. I was working as a Software Engineer as a C# developer. I was getting ready to take some time off, and my manager had mentioned she wanted to investigate Agile development, and incorporating it in our team.
I did a quick search for something on Agile I could read while on vacation. I stumbled on the book, “The Phoenix Project”. While not specifically on Agile, it gives a great basis on flow constraints. It’s an easy read, and really opens up the mind on how to spot bottlenecks in a flow process, and how to alleviate them.
In a lot of ways, this is what Agile development is all about. For years (and even for a lot of companies is still the normal flow), the way we developed was what was know as “Waterfall Development”. You spend a lot of time designing every minute detail of your software, get approvals, go back, refine the design, get more approvals, and finally, start coding. Once you’re done coding, you test, fix, test, fix, blah, blah, blah. Eventually, after several months, you release a finished product. And then you go back, and start designing again.
This flow has several huge draw backs. If there is a need for your company to shift directions, and you’re halfway through the development phase, how do you, as a company, react? Do you drop what the developers and project managers have spent weeks to months designing, and start over? Do you let part of your developers finish what’s been started (making the process even longer)?
From a current industry approach, is releasing software once or twice a year acceptable? Is this maintainable if you’re build a cloud based platform?
These questions, and a million more like them, are why Agile is taking over. Any SAAS platform that is doing Waterfall development will never be able to keep up with their competitors. The concept of CI/CD (Continuous Integration and Continuous Delivery) cannot exist in a Waterfall environment.
When I came back from vacation, my manager did her best to implement Agile. Looking back, she didn’t have the training and understanding to really implement Agile. I give her huge credit for trying. It’s very difficult to move to Agile without the buy off the upper management of a company, and it’s hard to get that buy off if you don’t fully understand the framework. And none of us really did, so we really only integrated a small piece of Agile.
The next company I worked for started out very small. They had been around for quite a few years, and the primary product was starting to get some maturity. I was the third engineer hired at the company, and it was definitely a Waterfall approach. Over the first year and a half I was there, the company saw remarkable growth, which included building out a large dev team. One big issue with Waterfall is that it doesn’t scale well.
As the company grew, the founder was getting spread to thin, and so a CTO was hired. He was well versed in Agile. He came in just as we were going into a debugging session before a release. He watched us struggle with the thousands of tests required to ensure full integration worked seamlessly. As the next iteration began, he began to integrate Agile and Scrum into our operation flow. While it took a while for us, as a dev team, to really get up to steam on the mindset, once we did, the amount of quality work getting completed skyrocketed.
My next post will delve into how we moved from Waterfall to Agile, and some of the hurtles we had to overcome.