Improving the release cadence of FusionCharts across the organization

Background

FusionCharts is one of the top JavaScript charting libraries worldwide. It enables developers to create stunning data visualizations on their applications and websites.

During my first 12 months as a Product Manager, I successfully executed projects such as rebranding, building integrations for JavaScript frameworks, and optimizing conversions. As a result, I was promoted to Head of Products and tasked with leading the entire product team.

As Head of Products, I was responsible for both the "Core Product" (the JavaScript library used by developers) and "Developer Experience" (the website and documentation used by decision-makers to evaluate the product without writing a single line of code). FusionCharts is one of the products where the user persona and buyer persona are completely different.

Problem Definition

• The growth team couldn't perform experiments on the website quickly: The growth team couldn't iterate quickly on the conversion funnels, leading to many missed growth targets.
• Increased churn due to long release cycles: Many customers were not renewing their licenses due to very few or no updates. Some releases took almost 18 months to complete, impacting the company's bottom line.

Discovery

As mentioned earlier, the product team was split into two parts: Core Product and Developer Experience. The Core Experience team collaborated with the Growth team, while the Core Product team worked with the Sales team. Each product team had different output expectations:

After spending time with both teams, we identified different root causes for their problems and required different approaches to mitigate them. The following were the root causes for each team:

Execution

Since both teams had different problems, no solution could work for both. Fixing these problems required 9-12 months of work, with various iterations based on each team's comfort and culture.

Improving the predictability of the Developer Experience with Scrumban

• The Developer Experience team used the Kanban model, with a public Trello board visible to everyone. Various teams would dump their requirements onto it. However, the team was distributed across two cities, leading to much non-verbal communication.

• Lack of communication and poor scope definition made it difficult to implement things on time.
• We first implemented Scrum, including backlog grooming, standups, sprint planning, retrospectives, review, etc. We replaced time-based estimations with points and velocity.
• A two-week sprint would start with taking requirements from the growth team. Using story points and velocity, we could estimate how far we were from the deadline and improve our delivery.

• However, this led to slower release cycles, as the growth team had to wait two weeks before changing the experiment. Not very agile, right?
• Hence, we decided to transition back to Kanban with a hint of Scrum, aka Scrumban. Scrum ceremonies had advantages, such as daily standups, sprint planning, and retros. At the same time, Kanban focused on speed and transparency.
• Each 'In Progress' card had a limit based on 'Story Points' to ensure we did not overcommit.
• Daily standups ensured we had clear requirements and were on track to meet our committed deadline.
• Reviews helped us determine if there was room to improve the 'In Progress' limit so that we, as a team, could improve.

Implemented quarterly releases for the core product

• The engineering team of the Core Product excelled in core competencies such as code quality, stability, and estimations. They didn't follow a story points-based approach but provided absolute time-based estimates, which were spot on.
• Their major concern was scope creep and the roadmap. When the product team took over, it made their lives much easier and helped them be more agile.
• Before the product team's intervention, the engineering teams often followed the waterfall methodology. However, after the product team was formed, we followed a combination of Scrum and Kanban.
• Unlike SaaS products, FusionCharts resided in the customer's application, so the quality of the product was always crucial. Also, frequent release cycles like weekly or bi-weekly would make the customers' lives difficult, especially in enterprises.
• Hence, we implemented quarterly releases that included one week of planning and estimations, six weeks of development in Scrum, a review, and four weeks of QA cycle in Kanban mode with two weeks of buffer.
• We iterated between Scrum and Kanban but eventually found that a combination of both worked in our case.
• One week of planning ensured the engineering and QA had enough time to gather estimations. Six weeks of focused development cycle ensured there was no loss of productivity. And four weeks of Kanban, they ensured that the software was thoroughly tested and that all the bugs and regressions were addressed immediately.

Conclusion

• With Scrumban, the Developer Experience team released many major projects, including rebranding and redesigning Dev Center (a developer API documentation website that is more developer-friendly).
• Regarding the Core Product, it took almost 18 months to move from FusionCharts v3.12.0 to v3.13.0. However, all releases after v3.14.0 were made every quarter. Even after FusionCharts was acquired, the same practice continued. You can see it yourself by navigating through the entries on the version history.

Your agile is someone's waterfall!

• This was the biggest lesson I learned. Everyone wants to do agile, so they assume others are doing waterfall without understanding the methodologies.
• Focusing on outcomes/delivery and understanding what your team is comfortable with is important instead of forcing something just for "following processes." Processes are created for teams; teams are not created for processes. Every process will vary from team to team.
• Phrases like "sprints should never be modified" are used to shrug off responsibility and make the team anti-agile. The Agile Manifesto focuses on speed, quality, efficiency, collaboration, and outcome. It doesn't even mention sprints, scrum, or points. So, in the end, the outcome matters, not the processes.