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.
Marc LeBrun, VP Engineering at Flow Kana, shows the value in establishing a collaborative relationship with a withdrawn but highly-capable employee. We can then use that bridge to draw the person back into the team and elevate everyone’s performance.
VP Engineering at Flow Kana
Kowsheek Mahmood, Principal and CTO at ArchetypeTech, explains how he adapted an ineffective team by determining and implementing team-evaluation processes to better align the team on product delivery.
Principal & CTO at ArchetypeTech
Viacheslav Bessonov, Chief Technology Officer at Algalon Capital, outlines how he improved communication internally - with his fully distributed team, while also improving communication with the customer - located across various time zones.
Chief Technology Officer at Algalon Capital
Alessandro Pintaudi, Product Management Director at Payfit, talks about how teams need to focus more time on building the right things and how to keep doing it with scale.
Product Management Director at PayFit
Maria Petrova, Principal Product Manager at Zalando details how she strategically mapped out features using a KPI tree to drive measurement, ultimately helping the development team understand their role.
Principal Product Manager at Zalando
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.