From Waterfall To Agile

Problem

"Every company goes through some sort of analysis to decide what is the best software development life cycle fits their organization. In most cases, this happens when organizations decide to move from one model to another. Software organizations tend to use titling to describe what their software development life cycle is, such as agile companies, Waterfall companies, or hybrids. For me, both at Inuit and LexisNexis, my organizations were very much Waterfall organizations trying to go through an Agile transformation. We needed more predictability and wanted to get customer insights in a far more iterative fashion."

Actions taken

"This was a very difficult task to achieve, as we didn't have engineering talent that came from an Agile background. At Intuit, all my teams were staffed with people who had been in the same company for five to six years. They knew how things operate and there were hard deadlines because of compliance. It was very hard for a company with these restrictions to move to an Agile structure. We started from an engineering standpoint. We got an Agile consultant, brought them into the office, and got them to develop an Agile framework for everyone in Engineering, regardless of their role. We then had a two-day offsite where we had Agile coaches talk to us about how things worked, and how you should think about it. One downside of this two-day training was that the engineers couldn't learn to write high-quality user stories in this timeframe, so we had to spend time later developing their skills. Next, we decided to roll it into our teams. We explained to the teams they would have two-week deliverables based on what was in their backlog, and they would do everything they already were doing but in smaller chunks of time. This worked well right out the gate because we had a good backlog of items. Then, we started to build CI/CD so we could start continuous deploying and integrating our applications into our different environments. However, some of our applications were for desktop users and desktop users don't upgrade every two weeks, so we needed to find the right cadence for our end users. At Intuit we missed the mark in terms of following the right structure to make the transition successful. We got there, but we took a much longer route than was strictly necessary. With LexisNexis, it was much easier. We had the same issue to solve, but I knew how to do it in a better fashion. we rolled out Agile to one team at a time. I acted as an Agile coach for one team. Once they had learned everything they needed to know, one of the team members then became an Agile coach for another team, and so on until all the teams were trained."

Lessons learned

"Starting with engineering was probably not the right place to start. It's better to start with both your product team and your engineering team because if your product team hasn't bought into the process, your engineering team can't really deliver on a two-week cycle. In addition, it's not always the right decision to use external coaches. They don't know your company's culture or how your organization operates. One of the Agile mentalities is self-organizing teams. When you have an external consultant, you aren't letting teams self-organize, the consultant is managing everything. By doing things internally, it empowers the team to take ownership of the process to make the organization successful."