Zume Retro Part 2: Everything You Know is Wrong
Back in May, I wrote an article about key learnings from my time at Zume and mentioned that there would be a few more posts. A lot has happened since that first article that delayed the subsequent posts — namely, 2020 continued to surprise us all, and I’ve been busy working on my new startup. However, the time has finally arrived to move the remaining lessons out of my notebook and into the world. So without further ado.
A quick hop to 1992. Zoo TV Tour. Floating cars with bright headlights. TVs and massive screens are flashing provocative messages. “Taste is the enemy of art.” “Ignorance is bliss.” “Watch more TV.” “Everything You Know is Wrong.” Masters in reinventing themselves, U2 were calling us to question, to challenge, to rethink all that which we hold self-evident. The following lessons’ theme is that you shouldn’t be afraid to challenge core assumptions, beliefs, and practices. Two-week sprints? What would happen if we try a two-day sprint? Quarterly planning? Why? 10% of the sprint goes to tech debt? What if it was 10% of the team? Commute 2 hrs a day? What if we all worked from home 🤔?
One of the main benefits I had in arriving at software engineering later in my career was that I wasn’t afraid of questioning and rethinking default practices and processes. As a VP of Engineering, I was able to revisit these practices and experiment with stark alternatives.
Lesson 4: Burn the roadmap
“Mann tracht un Gott lacht” is an old Yiddish saying, which means “Man plans and God laughs.” Have a plan. Have a backlog. But don’t waste too much time planning too far into the future — planning an entire quarter at an early stage venture is futile. Life will happen. You will ship the product, and your assumptions will be validated or invalidated. You will need to iterate. If this is not happening, you’re moving too slow. You’re not experimenting. You’re not talking to your users. You’re not learning fast enough. Work on shortening your time to ship. Having more than 2–3 sprints worth of work roughly planned out is often unattainable, and if you are embracing an agile mindset, not needed.
My team and some other folks within the business unit struggled a bit with this at first. People kept wanting to see our ‘roadmap.’ So, I’d point them to our backlog. I kept emphasizing that the backlog and our next 2–3 sprints are the roadmap. If you want more than that, spend more time with your customers.
Lesson 5: Rethink your Artifacts
Before the January RIF, our engineering and product teams relied heavily on Jira for project and sprint management, user stories, and bug tracking. I felt like Jira had become too convoluted. I wanted my team to move fast and not get caught up with confusing (and often slow) software and terms.
We ended up using Notion for tracking our backlog and sprints, and Linear for tracking tasks within projects. We tried using Trello in the beginning for the Project backlog, but we found Notion gave us more flexibility and room to define projects and spikes in more detail. We likely could have just used Notion for all of it (since we began using Notion instead of Confluence for notes and documentation) and not used Linear, but Linear worked well for individual projects with multiple tasks.
“Individuals and interactions over processes and tools.”
The point here isn’t so much regarding which specific tool to use, but rather to not take any of your tools for granted. Remember the Agile Manifesto’s first principle: “Individuals and interactions over processes and tools.” Creating a culture in which we valued individuals and interactions over the processes and tools was paramount. Notion got out of our way and let us focus on the individuals and interactions.
If you find yourself fussing too much with the tool, throw it out. Use a whiteboard and sticky notes. They work great. And if my team was co-located, we would have done just that. But since we weren’t, and since COVID-19 forced us to work entirely remotely, figuring out which tool and how best to work with it was necessary as I’m sure it is for many teams right now. But don’t be afraid to experiment and remember what’s essential: individuals and interactions.
Lesson 6: Smash the Bugs
One of the things we struggled with during my time at Zume, like many engineering teams, was cutting down our technical debt and tackling bugs. There were times when we had a real handle on both, and other times when we felt like there was no end. Part of the problem was that leadership expected the engineering teams to devote a certain percentage of their sprint to tech debt and bugs. Still, product demands and business needs often felt much more pressing, and we’d neglect to prioritize the tech debt. Also, responsibility for the tech debt and bugs wasn’t entirely intuitive or straightforward, causing confusion and more delays.
Our engineers, whom all served in the engineer-on-call rotation, often felt like they didn’t have the tools to debug production issues, nor were they familiar enough with all of the stack to begin to identify the root of the problem. The context shifting that came with on-call was also dreaded and detracted from their core work.
And finally, deployments to production became daunting. Who was deploying? When? Did they notify all the relevant stakeholders? Were they ready to handle any issues that came up?
Within my team at Zume Forward, we decided to form a dedicated SWAT team focused on tech debt, bugs, and deployment. The SWAT team would also be the only ones to be on-call during that sprint. Every sprint, we rotated the members of the SWAT team. The incoming team had a clean hand-off with the out-going team and had time to ramp up and get familiar with each other and the tech debt backlog.
In addition to allowing all the non-SWAT team members to focus on their sprint without bothering with on-call, it also ensured we crushed all bugs and production issues quickly and had a dedicated team focused on mitigating our tech-debt. The SWAT team’s attention was not distracted by feature development and coordination with PMs and designers.
It also made it extremely clear who was responsible for deployments and ensuring they happened seamlessly. The process of reporting bugs, triaging, and prioritizing them became a lot clearer — there was a team dedicated to it. The SWAT team reviewed bugs daily and used Kanban to continually re-prioritize their backlog.
Conclusion
‘Everything you know is wrong’ doesn’t just make for good rock and roll. It’s true. Or is it? Keep on questioning, tinkering, and moving. We’re living in interesting times — times that demand we rethink it all, always.
