Going Agile Part I: Developing Innovative Products at a High-growth, Dynamic Company
CAKE has experienced an explosion of growth. Over the past year, we’ve increased revenue 71% year-over-year, grew our team by 72% and significantly expanded our SaaS platform. It’s an exciting time.
However, how do we ensure the products we build will continue to be widely accepted and adopted – that what we’re building will be a success?
I believe this is a question that we may never be able to answer with 100% confidence. But, what we can do is mitigate risk through continuous improvement and sound decision-making. During my tenure at CAKE, we’ve done some pretty cool things to address this question. In this three part blog series, I’ll share three of our biggest success stories with you.
The Scrum Way
One of the coolest things we’ve done to ensure that what we build will be successful in our dynamic environment is switch our development methodology from Waterfall to Agile. Humans are a skeptical and cynical bunch, so the process of transforming development methods can be a daunting task. It can be fraught with unforeseen challenges to overcome and, even worse, slow development, compounding the development team’s fear of change. However, ultimately the result will be well worth the challenges along the way.
When I joined CAKE a little over a year ago, we prioritized all of our R&D efforts and built one product at a time. It worked well within the confines of the small team that we had at the time, but the signs that our team was about to explode in size were clearly evident. While not a bad problem to have, this growth would definitely pose development challenges as CAKE continued to scale in size.
So, we turned to Agile Scrum to address our eminent issues with scaling, in addition to helping with managing our rapidly changing priorities, responding to the demands of the business, and ultimately, improving predictability.
This was certainly a tall order to fill. The expectation suggested that this new project management philosophy may not be the end-all, be-all solution to these challenges, but could still lead to improvement while also highlighting additional problems that we had not yet identified.
Since training was essential in addressing the fears of the team and ensuring both the product and engineering teams were on the same page, we hired an Agile coach to help. This had a very positive impact on morale, alleviated fear and built confidence throughout the team.
Now, we are Agile!-ish
Today, we have specialized, cross-functional teams that work on project segments called pillars – things like feature development, code refactoring and internal operations development to name a few. These teams spend shorter time frames building smaller project components, capitalizing on each team member’s strengths in reaching each individual team’s sprint goals.
While we follow most Agile rituals such as standups, grooming and retros, there are still aspects of our development process that do not lend themselves to adherence to the strict definition of Agile Scrum. Our user stories, for example, at times resemble a Waterfall requirements document and we sometimes project plan with Gantt charts. Our goal was not to change overnight, but be flexible, pick the right Agile tools and adapt to the given situation. Hence, we say that we are Agile-ish.
Overall, switching from Waterfall to Agile has made our team even stronger, more adaptable to business needs and more dynamic, addressing multiple projects at one time. Our planning has improved and today we better meet the needs of our internal stakeholders and CAKE’s clients.
Stay Tuned!
Over the coming weeks, I will share two more product development process success stories with you – our home-grown Platform Value Score which helps us prioritize projects and how we use the concept of budgeting to better allocate our development resources.