Making a resistant company more Agile.
6 December, 2017
When I first started at Zoosk, the engineering team were using their own version of Waterfall. When they had projects, they'd plan the full scope of the project ahead of time. They'd break down everything into minute details before starting the project. Then, if they discovered something was going badly during the middle of the project, it would cause major project delays.
The team would also avoid giving anything to QA until they had finished the entire development. If, during testing, issues were found, it would be too late and the team would have to go back and start over to fix the problems. To fix this, they tried a modified version where they would have dynamic teams organized by each project. However this version still did not solve most of the problems discussed above.
Because of this, it was difficult to estimate when a project would be delivered. In addition, although we knew the scope of a project upfront, it was always changing, and the projects were always getting bigger and bigger. Lastly, because of these issues, we were not able to meet our goals.
Because the team was so small and dynamic and everyone comes together to get a project done, when I came on-board I thought a little more process would help the team.
One thing I thought would work was Agile Scrum, used from the product level to engineering. At the product level, instead of thinking about big features, Product Managers would break features/stories down to minimal viable product and build as product increments. Engineering would then work on smaller goals every sprint to ship out these product increments. So I set out to get team consensus and prove to them that this wasn't just another process they had to learn and follow. New processes always have a stigma attached to them, as people question why they have to follow a new process.
I met with all the key stakeholders, including engineering leads, product leads, project manager and my SVP and I introduced my plan to them in terms of structure and process. My first stakeholder meeting was a complete disaster. The stakeholders didn't agree with my plan and questioned if we can improve the existing process and not drop everything and move to a new process. I then took a step back and realized that I had to show them a working process and also I had to make it look like it was their idea. Ultimately, we all want to improve the process and efficiency of the team.
I examined the existing process for one of the teams and started to plug in small changes. This way people didn't think I was changing the entire process. Instead, I used terms that were non-standard to Scrum, so that they would relate the new processes with the existing ones. This opened up the stakeholders to further discussions, as they were able to identify where their current process had gaps. Since I was directly working with one team as their Scrum Master, I was able to explain with concrete examples of what is working and what is not. I was also able to work with the product manager of that team to align with our process. I then rolled out the process out to a second team. The stakeholders became very supportive as they saw working examples of improved efficiency in this model. These two teams became an advocate for other teams on how the process helped them.
Further discussions with the stakeholders went really well. I had to compromise on a few things, but the stakeholders met me halfway. Three months down the line and we were completely Agile. Now everyone is supportive of it. The best thing is that everyone felt like they were included when updating the processes.
Lessons learned If you're trying to transform a company, so that they will use a different process, you have to find a way to get support from different groups of people so they can fight for your cause. In addition, make small, incremental changes so that nobody feels threatened by the new processes. Lastly, be willing to listen, compromise and be patient so everyone feels involved in the process change.
Deepak Paramanand, Product Lead at Hitachi, explains how his early efforts in stand-up comedy and experience of interaction between a performer and audience helped him better understand his colleagues and customers.
Product Lead at Hitachi
Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.
Founder / CTO at Forward
Caroline Parnell, previously managed product teams at O2 and Vodafone, shares some of the techniques she applied with her team to ensure diversity of thinking during product discovery workshops.
Most recently Head of New Product Innovation at Previously O2 and Vodafone
Justin Potts, VP of Engineering at MoneyLion, tackles the ever-intriguing problem of simplifying the architecture and thus reducing the overall complexity of the systems.
Head of Engineering at MoneyLion
Himanshu Gahlot, Director of Engineering at Lambda School, recalls his own journey transitioning from a large corporate to a small startup and how he managed to adjust with ease most of the tools and processes to the needs of his smaller and more agile company.
Director of Engineering at Lambda School
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.