C3927DC8-5C3A-442C-9D1D-51BD87399904@1.00xCreated with sketchtool.back to articles
Developer
Product
People

Best Practices in Iteration to get Products Successfully to Market

After 30+ years of working for Enterprise startups, I made the move to Quizlet, a consumer-focused study platform, and high growth company. Quizlet’s users are learners, which means mostly students, teachers, and people who want to teach themselves something new. I purposefully chose to join the Quizlet team as Senior Technical Program Manager to do exactly that — teach myself something new — and I have not been disappointed.


Over the years, I have seen a lot of different approaches to managing engineering organizations and the processes used to release software. I started my career using the Waterfall method, and can attest that it’s not the most effective. Pivoting to Agile was a huge relief and has fixed many of the problems of spending too much time trying to get things perfect to only find out it’s not what your users even wanted. At Quizlet, our commitment to how we organize the process confirms that being agile is key to doing Agile right.


We recently changed our engineering organization from horizontal teams — meaning a web team, mobile team, backend team, etc. — to vertical teams, which we call Pods. Each pod acts like a small startup with specific areas of focus. At first, it was a bit of an adjustment for me to get used to continuous deployments and fullstack teams, but I really appreciate the new way to organize work. With this shift, we have found great efficiency and innovation in the areas of team management, sprint deployment and results.


A fully formed Pod can grow up to 12 people, including an Engineering Manager, a Product Manager, a Designer, a Product Analyst and around 8 engineers across Web and mobile platforms. The teams are given complete control of how they go about achieving the goals of the team. They are encouraged to take risks and set audacious goals, and together develop a plan and execute on them.


In Jira, we came up with a creative way to track all the various team members work. Instead of having just the traditional issueTypes (Epic, Story, Task, Bug), we created one of each of these per platform (iOS Bug, iOS Task, iOS Story, etc.). Using different colored icons for each type (Red for bug, Yellow for task, and Blue for Story) and using different icons for each platform, helps us see the status by platform more clearly. It also allows us to do reports that show all the bugs on iOS across all the Pods (issueType in (“iOS Bug”)).


We also came up with some new Status fields to help us track the front-end of defining a new User Story. One of the issues we were trying to solve was pulling in User Stories that weren’t fully fleshed out. We would spend too much time during the sprint, finishing up the spec. To address this we added new Status fields; Spec & Research, Design, Needs Estimation, and Ready for Sprint. These help us make sure a Story is fully defined before it gets put into a sprint.


We do the traditional 2 week sprints with stakeholder, estimation, retrospective, and sprint planning meetings. We spent some time discussing whether moving to 3 week sprints was a good idea. We even have one or 2 of these every year, and decided they wouldn’t help solve our problem of not always hitting our sprint goals. The key to that is getting solid estimations, which takes time and experience to get good at. We try not to beat ourselves up too much about not making our sprints and are always working to get better. There is no perfect process.


From my past experience, large QA organizations had often enabled engineering teams to be lazy and not own the quality of their work. The traditional QA process and organization often caused problems with development velocity, as the QA team had a hard time keeping up with changes. When you continuously release, you catch things immediately and actually remember the code you wrote so you can fix things quickly.


At Quizlet, engineers create their own test plans, unit tests, and manual tests on their pull requests. Our small QA team is a partner of the engineering team and is responsible for enabling our engineering team to succeed at owning the quality of their code. They embed themselves into the Pods so they know what features are coming, and then are used to help the engineers come up with a test plan. QA has a set of test cases that they can point an engineer to so they can use them. This has worked amazingly well. I am a big fan of engineers owning the quality of their code as issues get addressed sooner and the quality is better.


The best thing about Quizlet is we are always trying to better ourselves. We encourage each other to be an owner and create the change you want. And we look for people who want to do the same. Checkout out our open positions and connect with me on LinkedIn! #LearnOn

You may also be interested in

  • Jun 2, 2017

    Talking Denver with Serial Founder- Josh Churlik

    Spotlight
    Founder
    People
  • Feb 27, 2018

    5 Reasons Why You Should Absolutely Apply for the Denver Startup Week Ambassador Program

    Developer
    Spotlight
    Headline Events
  • May 13, 2017

    Insider Advice to Land a Job in Denver Tech

    Developer
    Headline Events
    Growth