Most things evolve over time, and processes should too. If they don’t, they risk becoming outdated and hard to work with. Then people begin to ignore them. After that comes chaos, and things get really messy.
That statement may feel a touch melodramatic, but it makes a valid point. Modern software development works on a basis of small incremental releases with several feedback loops to keep it on track. We can apply the same approach to the development process itself, allowing our workflow to be managed in an optimal manner.
By evolving our processes at the appropriate times we ensure that the critical work remains the priority rather than the process itself. And that’s the approach we take.
Some time ago we wrote about how we use Agile techniques in our development workflow. Since our recent growth financing round in January and subsequently doubling the size of our team, we felt it was a perfect time for an update on where we are now and how we have made changes to meet new demands and continually improve our processes.
With that in mind, let’s take a look at where we’ve been – and where we’re going.
Our original approach
When Bipsync started out way back in 2012 our methodology was as organic as you’d expect – and want – that of a new start-up’s to be. We naturally evolved into a Scrum process driven by Danny who, as CEO of a small-team, became a de facto product owner. Next we moved toward a Kanban model to further support our rapidly growing client base and all-important feature requests and roadmap items that would further enhance their product experience, as well as help us to establish our place in the market as an RMS category leader. That took us to the start of this year, when serious growth meant that we had to consider changes.
That’s an extremely brief overview – it was far more detailed than that over the course of five years – and that story is available here.
Where are we now?
Ultimately we’ve hybridised.
We recognised that doing all our development in a Kanban format was not making the best use of resources that would enable us to build the exciting new features we really wanted to. Our customers workflows and their productivity on the platform will always be our most important objective, so it stands to reason customer support requests and improvements will always get prioritised.
This presents an interesting challenge: we want to provide the highest level of support we can to our customers while also continuing to innovate and create amazing new features for our customers. How could we reconcile and balance those two items?
Our solution involves using a dedicated process for each of the two different types of work we deal with – support and feature development.
First, feature development. Our roadmap feature development is performed in a ten-working-day sprint format to allow us to adapt and inspect each new feature cleanly and incrementally. This gives us all the benefits you normally get with sprints such as:
- Small incremental lower risk releases.
- A chance to adapt as requirements ebb and flow.
- The opportunity for clear and rational thought on why we are building something.
Through sprints we plan cleanly and concisely, reflecting on what we have done to inform what we should do next. This allows us to release value for both Bipsync and our customers as early as possible from our development time.
It’s pretty much a dictionary definition of an Agile sprint:
Alongside these feature development sprints we manage client support development in a Kanban style. By its nature support is often reactive and harder to plan for, so the flexibility Kanban offers makes it a perfect fit.
Each week we have a few developers working on our support queue, and we rotate so everyone takes their turn. This means our developers see real world usage of the product and issues that customers may experience. At the start of each week we plan ahead as much as we can, but we are prepared to be flexible so we can reprioritise our tasks at a moment’s notice if so required.
There are two aspects to the way the support queue is prioritised. First we consider the issue we know is causing problems for our customers. Secondly we consider the technical concerns, which if left unresolved may cause or compound those issues in the future.
By taking this approach we have reduced ticket resolution time and increased resolution rate.
More importantly, we are increasing our predictability. This means we can more reliably forecast when an issue is likely to be fixed, keeping our clients better informed regarding their support.
Where do we go next?
That’s always the question here, and it’s almost always impossible to answer. We’re committed to continue to evaluate, and tweak, our processes and workflows in order to remain as efficient and predictable as possible.
Ultimately we want to have enough process to guide us day-to-day, but enough freedom to give our developers the room to be creative in shaping how our product evolves. We believe this will allow us to continue to not only meet, but exceed, our customers’ expectations.
