Going Agile Part III: Budgeting Finite Resources
How do we know if the products we build will 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.
Optimizing Resource Allocation
Once we had given our development process its Agile boost and ironed out a very precise way to feed and prioritize our roadmap, we needed to make sure we were allocating our development resources in the best way possible. But, how could we accomplish this?
We needed a solution that would work just as well today as it would years into the future as we expected our development team and the need to handle more and more simultaneous projects to grow exponentially.
Solution: Budgets!
One of the ideas we experimented with that got some great traction out of the gate surrounded the concept of using a traditional budget planning model and applying it to our development resources and the needed time expenditures necessary to complete development projects.
If you think about it, you can see the strong similarities between how a household or business manages its finances and a development team manages its roadmap and its developers, using a finite amount of resources to allocate against necessities and wants. Plus, the concept of financial budgeting can scale endlessly, which is important for a growing development team and company.
Some Great Benefits
With this in mind, we created a budgeting system where each pillar, or project segment, is assigned a budget of hours and a bucket of work that we believe can be completed within that budget of hours.
In addition, this simple concept of budgeting limited resources, serves as an easy way to communicate to stakeholders and the exec team how much of the roadmap can be completed during each sprint for each development team.
Allocating Our New Budgets
Understandably, pillars like feature development which lead to the bright and shiny features that pique customer interest and give sales and marketing bells and whistles to promote, would get the most love, but how much more love than the other, more foundational and functional pillars? How could we ensure a balance between sizzle and steak?
To do this, we review and dissect pieces of work or user stories completed within a certain time frame and categorize them into a pillar. As a Product team, our goal is to understand where this work is being divvied up – and communicate the breakdown to our stakeholders.
Should we be focusing more on the code-refactoring pillar and less on the feature development pillar? Probably not. But this exercise gives us a good baseline and allows us to improve transparency across departments.
In Conclusion
These three product development success stories – going agile, our PVS roadmap scoring system and the proper budgeting of finite resources – are the foundation for how we build compelling products. To be completely honest, we never know if a product will be a success. But at CAKE, where our guiding principal is continuous improvement, we strive to reduce our risk through repeatable processes so we can quickly pivot when things seem to be suboptimal.
I hope this look inside how we develop products and features here at CAKE not only shows how dedicated our team is to the success of our customers, but also offers some insight into ways that may help you improve your own business and development efforts.