Frameworks aren’t prescriptions
I’m sure if you were to speak at length with anyone at Verto, you’d probably come to find we do things a little differently. We don’t settle with an approach strictly because it’s been prescribed as ‘standard practice’ and ‘that’s how everyone does it’. We don’t want to allow ourselves to be boxed in by traditional frameworks.
Perhaps it’s bold or cliché to say but we really do obsess over constant improvement. We not only want to do better than our last iteration of an idea, but we also seek to improve existing frameworks to better suit our velocity.
I manage a team of empowered and highly passionate developers, all driven by new challenges and making a real impact in the digital healthcare space. We love the thought of being able to create new technology with the potential to push Canadian healthcare forward.
As Verto is a growing company, one of the challenges we face is ensuring that we preserve our innovative roots as we scale and add new key members to our team. We not only want to keep our team focused on the deliverables within a particular sprint, but we also want to encourage creative ideation. Like most startups, we’ve gone through a number of ‘tries’ in search of the perfect balance.
Some of these ‘tries’ have been wildly successful, while others…not so much. I like to think we can now look back upon those failed ‘tries’ as light-hearted inside jokes (perhaps you know the type) and that it’s a leading by example situation where the team feels like they can try new things in a safe space. However, one of the initiatives I believe has succeeded was creating and enforcing a 20% “Development Buffer”.
Buffer time breeds creativity
The idea of a Development Buffer is not new and we certainly did not come up with it. However, I think the way we view and use this buffer varies from more traditional usage. At Verto, the development buffer time is not allocated solely for contingency planning because the project might go over points or because we may encounter more bugs than anticipated (we do that as well). Instead, we aim to protect this time so the development team can use it for research, learning, experimenting, and innovating at a rapid pace.
We are by no means perfect. Some weeks our buffer does get spent on production bugs, unplanned away time, and tasks that have taken longer than expected. As the year comes to a close and we push to wrap up many key client projects and our next major release, it has been challenging to keep this time protected. Despite this, we have already seen so many development buffer projects come to fruition by allocating this time and some of them are even shaping the future vision of our product.
How do we manage it?
Hopefully, you’re already starting to realize that the idea here is to keep the team motivated and prioritize developer experience. By allowing time to flex creative muscles, you open a lane for inspired devs to push your products and solutions to new places. The more you can protect this buffer time for developer innovation, the more amazing projects and advancements you’ll see come to fruition!
How you manage this time depends on your industry, business model, existing processes, and team dynamic. For our team: we track each of these buffer items as a ticket on a JIRA board, which is entirely separate from our sprint board. Rather than having the project managers or product lead add these tickets through a traditional sprint, we’ve removed as many barriers as possible to keep these going–including not giving them story points (gasp!).
These tasks are managed by our Development Team Leads and our more senior technical resources. Together, they own the Development Buffer Board and collaborate with other teams to determine viability and priority.
Finding the time
As we don't manage the Development Buffer Board in sprints, we consider these tasks best-effort. Anyone on the team can propose an item for consideration and if approved by a Team Lead, they can work on it in their spare time during the sprint. This time could be during a Friday afternoon or a slow Wednesday morning while the Devs have blockers on their other sprint tasks.
At Verto, we’ve also implemented ‘no-meeting’ Wednesday mornings, so employees can focus their time without interruption (we highly recommend this for any company). This time is perfect for our Development Team to work on their buffer tasks. The goal is to ensure they have enough time to progress on these tasks and provide updates by the end of the week.
Building bridges
In good conscience, we can't take all the credit for these tasks. We've gathered ideas and pain points from all our teams (Product, Implementations, QA, DevOPS, Support). We rely heavily on good designs, thoughtful product decisions, and dedicated manual/ automated testing to get these buffer dreams into Production.
Part of the magic of this process is that we have built strong relationships and have established a solid rapport with other teams. Now we can get quick approval and rapid feedback on tasks that will enhance our product.
All sides reap the rewards
This simple process has allowed us to churn out many beneficial and innovative projects and our Devs now get excited to work on and share the results of these projects. To give them a platform, we set aside time each week for the Devs to present what they’ve been working on, called “Dev Demo Days”.
When you provide your team with a platform to share their creations, you enable them to demonstrate the value added to the company. Through this, you're helping to foster a sense of purpose and community, which makes them feel great about what they do! You’ll bolster a culture where your Devs can experiment with a new library or build automation to save themselves and the team a ton of time if they clear their assigned work early.
Again, some of this buffer time might have to go towards checking off some tedious tech debt work that your team has had on their to-do list for months. However, your team will still feel inspired by the work they're doing in their buffer projects, making it feel less tedious.
The point is to enable creative thought, collaboration, and innovation. Empower your team to take responsibility and ownership of their work while removing as many barriers to progress as possible.
The bottom line: break up the sprint
Let’s face it: if your Devs spend the entirety of each day working strictly on sprint points and code reviews, they will eventually burn out. Why not give them the time to focus their energy on something that excites them?
Providing these small but meaningful breaks from regularly scheduled client work will help build well-rounded developers. They’ll start to see past the requirements docs and direct their energy and creativity towards something beneficial for the team and themselves.
I highly recommend you find ways to introduce Development Buffer into your sprints and hope you are pleasantly surprised by the results.