Transitioning from waterfall to Scrum and getting the Business team to buy-in

Problem

When I worked at CaterTrax our tech team was composed of around 30 Engineers. However, the way we were developing software often missed the mark. We would promise something three to five months out, work towards that date, deploy for the customer, and would then find out it was off. We would deliver our product on time but the features were not always right, the release was sometimes too big and we would end up missing something in regression. I narrowed the problem down to the length of time it took us between developing a product and testing it. The Engineering team would develop a product, while QA tested something that had been developed before and prepped it for a release. Often they would find an issue with the feature they were testing and would push it back. The Engineering team would then stop working on the new task and fix the issue, before picking up the new task again. Once done with the new task, it would go into the QA's pile of work. This would then happen over and over again. It could be weeks between when software engineers stopped developing for a project and when QA started testing and finding bugs in it. The result was a quality problem, so we needed to shorten the feedback loop.

Actions taken

The decision to transition from waterfall to Scrum was taken. This shift was rough for both the engineering and the business departments.While the tech team and PMs bought into the shift, the business team did not. The CEO and the VP of Sales either would not or could not grasp the concept. They viewed the world from a cost of labor perspective and wanted clear lines between labor costs and outputs, so they were very uncomfortable with the idea of an arbitrary weighting of effort. They would always ask about hours and how many days a feature of a product would take, rather than the effort and number of iterations it would require.

When first implementing Scrum, we started at a really low level. QA members were put into Scrum teams and began holding all the ceremonies and started testing during the iteration, rather than at the end of the project. Once the engineering team transitioned to Scrum, quality improved dramatically and our commitments were being met. After three to four months we saw the first signs of Business team buy-in. The full transition took about five months, but unfortunately, the CEO never bought into the Scrum method.

Lessons learned

Scrum is not for every team and company. To make use of the framework to its fullest potential, the business needs to buy in, not just the engineering team. If waterfall is working, I would advise retaining this method. There needs to be a business case to change a working method, and working software is the best argument for Scrum. Here are my tips for gaining buy-in from your Business team for a new working method:

1. Develop a business case — why is the current process not working? How will the new methodology address this?
2. Get feedback from the Business team about their concerns and purposely target these concerns (e.g. discuss how you will meet current deliverables).
3. Meet commitments utilizing short feedback loops (i.e. through demos and QA) and quality, working software.