My Journey to Agile

Comments [0]

Years ago, I worked for a large consulting company that embraced a Waterfall methodology. In a Waterfall methodology, a team completes each project phase before beginning the next phase. For example, we would complete all design for a system before writing any code, and we would complete all the code before starting testing. 

In theory, it made sense. Why try coding something unless you are 100% sure what you want to build? Waterfall also seemed the logical choice when handing off requirements to junior developers or to an offshore team. The more explicit we were with what we wanted, the less ambiguity to the coding party and the less chance they would misunderstand our needs.

But there were significant drawbacks to this approach. Many issues did not arise until we had begun coding, while others became apparent only during the testing phase. In those cases, we had to return to our design phase and re-do work already completed - often months earlier. This process was inefficient and expensive.

I once led a team designing the interfaces between dozens of backend systems at a large electronics retailer and the e-commerce site they were building. We spent months exploring each system, how to access it, and how to expose it to the front end. By the time we finished, some of the backend systems had changed significantly. Others had been wholly replaced. In those cases, our only choice was to return to work on the updated systems. We eventually completed our task, but we were months behind schedule.

Later, I left the large company and joined a small consulting firm that introduced me to Agile methodologies. This company had developed a variation of the Scrum Agile methodology. Their approach focused on creating one small feature at a time - design it, build it, test it. If anything went wrong, we knew about it right away and had minimal rework to do.

By executing an agile methodology, my teammates and I immediately became more productive. The most significant advantage I saw was in the "fail fast" mindset. We anticipated that things could go wrong - sometimes by our actions and sometimes by factors outside our control. We wanted to know immediately when things went wrong so we could fix them immediately. So, we designed, built, and tested our features in smaller chunks. Testing caught issues while the code was still fresh in our minds and before we had added extra dependencies. 

In addition, we held a daily standup meeting. Every morning, each member took a minute or so to describe what they worked on yesterday, what they planned to work on today, and any issues that might block them. The meeting gave everyone insights into the activity of others on the team and allowed the opportunity for one of us to unblock another's issue. By standing up, we kept the meetings to a reasonable length. Who wants to stand up for a 1-hour meeting?

I have not looked back. I consider how I can use an agile methodology to improve the process of every project I work on. It is rare that it will not.