Staying Responsive While Working on Long-term Initiatives

Smallpdf’s Mobile team has managed to strike a healthy balance between staying on top of strategic initiatives and being highly responsive to ad hoc work. Željko Ilić, Mobile Experience Engineering Manager, shares the team’s experience.

Work Prioritization & Risks

Work in product teams can be roughly classified as long-term projects , small improvements, and ad hoc items. Long-term initiatives include roadmap items and research efforts, which can take as long as multiple quarters to complete. Small tasks or improvements, on the other hand, can be feature iterations that are too small to be included in roadmaps. Finally, ad hoc work can include issues like bugs, maintenance, requests, and inquiries from other teams. They can’t be planned but are sure to pop up regularly, which is why it’s important to keep them in mind in the planning process.

Long-Term Initiatives

On the one hand, it’s important to prioritize long-term initiatives that can make a substantial impact on the product and deliver value to users. They’re essential to keep the business moving forward instead of resting on a working product until you’ve missed the cut-off point and stray behind the competition. But when focusing only on those long-term initiatives, the team faces the risk of gradually leaning more towards a waterfall methodology, a front-loaded approach that relies heavily on a linear flow of work from the start to the end of a project.

Even though this methodology has its merits, in many cases, it can bring about less flexibility, a longer cycle time, and less visible progress, which can adversely affect the team’s motivation. Just as ignoring long-term initiatives involves the risk of evolving as a business, too strong a focus on them means sacrificing current users’ experience, as current issues aren’t dealt with, risking losing customers altogether.

Small Tasks & Ad Hoc Work

Focusing only on small tasks, on the other hand, can lead the team towards a more reactive state, where work is prioritized mostly in line with urgency and effort. Working like this can create an environment where the team becomes trapped in a short-term perspective, never being able to focus on strategic direction or deliver any significant impact.

Striking a Balance

Considering the problems that come with each of the above-mentioned approaches, it’s clear that in order to deliver reliable and impactful output, it’s important to find a balance between these initiatives and how they’re tackled.

Setting up an Effective Team

The Mobile Experience team at Smallpdf comprises four iOS and four Android engineers. This number of engineers gives the team enough flexibility to divide the work into two streams:

• Long-term initiatives
• Fast lane initiatives

Every sprint, one engineer per platform is assigned to work on the fast lane initiatives. This assignment is rotated evenly but can depend on the expected workload and availability. Having a designated “first responder” to ad hoc requests and issues, as well as a dedicated engineer for smaller tasks and general improvements allows the rest of the team works on long-term initiatives with fewer interruptions. Rotating this task makes sure that no one is perpetually stuck doing the “grunt work” and everyone is involved in the bigger projects that help to evolve the business.

Organizing & Tracking the Work

Planning, organizing, and keeping track of the work are critical aspects of keeping the team agile, productive, and accountable. Here are some additional details on how we do this:

Long-Term Initiatives

• Long-term initiatives are implemented following the Scrum process in a two-week cycle.
• Work is split into stories and estimated using poker planning in order for scope and prioritization to be negotiated.
• Two to three long-term initiatives typically compete for resources during a quarter. How effort is to be split between initiatives is decided during sprint planning.

Fast-Lane Initiatives

• Fast lane initiatives are done following the Kanban process.
• Tasks are not estimated, but rough continuous prioritization is done, placing the various tasks in priority buckets.
• In cases where the complexity and required effort are unclear, tasks are time-boxed to keep the stream flowing.

Observations

After running this process for a quarter, we surveyed the team to evaluate how it affected their day-to-day work from various perspectives. Even though the results are subjective and far from statistically significant, a general sense of how the team was affected by the process became evident. Here’s what was discovered:

Based on the team’s feedback, the areas with the most improvement were:

• Cycle time: This is the time between an idea and a solution. Reducing this time improves the team’s ability to react to changes and capitalize on learning. We’re tempted to attribute the improvement we see having a dedicated person who handles small tasks.
• Product quality: This could be explained by the fact that fast lane initiatives create room to iterate on released features and make small product improvements.
• Personal growth: While working on fast lane initiatives, a developer needs to tackle multiple topics and consequently expand their knowledge of the codebase and the product.

Although the results are promising, there were some other important learnings gathered from the survey:

• While working in the fast lane, developers can have trouble staying up to date with the current strategic work, which can make code reviews slower.
• Sometimes assigned developers need to escalate the request to the team, in which case the benefit of having better strategic focus is diminished.
• Prioritizing reactive work compared to strategic work is not an easy task. Different teams might have different needs, so assigning one developer for the entire sprint can be tricky, if not impossible.
• Two weeks in reactive mode can put too much stress on a developer, so we are considering rotating responsibilities more often.
• Sometimes a developer can have more impact while staying on long-term projects , while someone else is better suited to dealing with ad hoc requests. We should consider this when assigning a new developer to the fast lane.

For Smallpdf's Mobile Experience team, adding the fast lane to the mix has not only brought a better balance to long-term and short-term work, but has also improved the team’s overall productivity and motivation, all while improving product quality for over 60 million monthly users.

Now, that’s impact! 🚀

Enjoyed this article? Check out our Engineering Blog for info, insights, and tips from the engineers at Smallpdf.