Transitioning Your Team to Agile in a Waterfall Organization

Problem

I was working at an organization where the life cycle of building a product was extremely long and very slow. Sales would sell a product that hadn't yet been built, then the product managers had to figure out what to build, after the idea would go to U/X so they could design frames, and finally the frameworks would make their way to the engineers so they could build them. Consequently, after we had roadmapped out a product it wouldn't be until a year or year and half later until that product was actually sold. In essence, the product, and thus so the engineering team, ran very waterfall.

Actions taken

A waterfall approach simply wasn't efficient for our product building process and for our development team. This was because essentially engineers were waiting on the previous group before they could begin their share of the process. Therefore, I decided that moving our engineering team to Agile would be a dynamic effort to battle inefficiency within our particular area of the organization.

"Moving our engineering team to Agile would be a dynamic effort to battle inefficiency within our particular area of the organization."

The knowledge required to run Agile was foreign to me. In fact, I was surprised to learn that nobody within the company had run Agile and so it was foreign to the company as a whole. As a result, I was required to look outside of the organization to gain the know-how needed. I took on the task and tackled the challenge by enlisting in a third-party class. I became a certified Scrum Master and a certified Product Owner.

In addition to completing the class, I also had to pitch the idea of transitioning to Agile to leadership. The industry as a whole was moving towards Agile so it was well received by most who wanted to stay on the cutting edge. For the doubters, though, I had to make a little extra effort to get them on board. To do so I presented them with two options: Option A, if we continued with our (then) current process it would allow us to deliver a product within X months; and Option B, if we started running Agile - even with the cognitive loading time for the team to get acquainted with Agile, plus additional meetings, and extra planning - we could deliver a product in half of X months. Approaching it from this revenue-driven standpoint easily helped convince the people who weren't fully on board initially that Agile was the direction to go.

"Moving our engineering team to Agile would be a dynamic effort to battle inefficiency within our particular area of the organization."

Agile wasn't adopted by the whole company, though. In fact, most of the organization continued to run waterfall outside of the development team. The overall process of having the sales team sell something and then engineers receiving it remained, but once the engineering team had the requirements then we as a group ran Agile. In addition to the prosperity of increased revenue that was pitched to the executives, Agile's supplementary benefits consisted of preserving individual's workload, making sure developers were able to work on features that interested them thus keeping them engaged, and from a broader business perspective ensuring that the engineering team didn't bottleneck the workflow.

Lessons learned

• There is a plethora of information out there about Agile. There is also plenty of material on Kanban, Scrum, and Sprints. An overabundance of info means that there are just as many ways of doing things. However, I advise you to abstract that all out of your brain. The key is to focus on understanding the framework and how it all works. Don't get caught up in the details. I believe that if you move away from waterfall to Agile that it is a step in the correct direction and towards making your process more efficient. Whether you do two or three week Sprints is not as important.

• Transitioning to Agile is an investment and was an interesting process for me. There were a few issues that came along with it - more meetings, additional planning, and less time to do actual developer work. But in the long term it helped build applications that were sustainable, somewhat future proof, definitely error proof, and easier to run. It was also effectively transferred to bigger teams that built applications.

• Agile isn't limited to just engineers. Anyone can run Agile.