How technical sprints can drive innovation and resolve tech debt through developer empowerment

Whilst Agile has revolutionized the way we work in software development, the pace of development is fast and delivery can feel relentless. It’s typical for developer teams to struggle to find dedicated time for R&D and to catch up with the persistent technical debt -- especially when under constant pressure to deliver the next feature or product iteration. 

For developers on longer term contracts, they deliver code, release and tomorrow they’re picking up the next iteration. There’s often no time to pause to celebrate success and take a break. In fact, the risks of team burnout and technical debt accumulating to worrying levels are very real.

But while addressing technical debt is an important activity to prevent costs of further work, it doesn’t allow developers the time to regroup and upskill. It can hold them back from exploring new technologies such as AI or other innovative ideas.

However, there is a way to keep teams energized and empowered, with time to stop, reflect and hone their skills. Technical sprints are a bold solution that can make the development team more productive and keep them at the cutting edge of technology as well as providing space to resolve technical debt, both of which provide a huge benefit to  their clients.

A quick intro to technical sprints

A technical sprint is a scheduled two-week period where developers are empowered to work on something outside of current client priorities that interests and benefits them -- whether that’s investigating a new technology or working on technical debt. It is usually every five or six sprints that the team engages in this liberating technical sprint where no customer driven work takes place.

The only caveat is that it links back to their client work or investigates future technology that might be beneficial to the company and its clients. To keep projects running smoothly, whilst the technical sprint is underway, the teams should carry out pre-agreed priority client project tasks and essential maintenance.

Benefits of technical sprints for teams and clients

The biggest benefits of technical sprints for teams and clients include:

• Team welfare and motivation: Giving designers and developers a mental reset makes them feel good within their working environment, reduces burnout, and boosts team morale as they are allowed to experiment on new innovations. A technical sprint is likely to see a reduction in absence or sickness of individuals in the team and maximize employee tenure. 
• Cool innovation: From a professional development perspective, technical sprints give developers the space to stay at the cutting edge of technology. For instance, if they spend 52 weeks of the year focused on client delivery, they will struggle to explore the possibilities of emerging technologies like AI unless they are doing creative work in their personal time.
• Technical debt gets resolved: Product managers are always looking for time to address technical debt when teams are constantly under pressure to make the next new shiny thing for the customer. Technical debt is picked up in the tech sprints which gives the team personal pride to finish things off and keeps the client happy.
• Team stays on top of technology changes: Since the work and PoCs in the technical sprints are related to the client work, clients have access to the latest and greatest changes in technology for their use cases. The development team can stay at the cutting edge of tech and keep abreast of evergreen vendor changes. This allows them to use the right tool for the job and explore more technologies. 
• Clients truly feel the value: These developer-driven investigations into possible technology can benefit clients in the future. For instance, we built an AI receipt scanning Proof of Concept using new technology which will introduce huge savings for our client in the future. Another example is using AI powered image recognition to improve 'Report It' processes at a local authority. Although there can be steps to take these from PoC to production in the future, the technical sprint can give ourselves a head start so that it can be prioritized on the roadmap.

Key considerations for implementing technical sprints

Ahead of announcing a technical sprint, it’s essential to get buy-in from the client and team to make sure they are behind it. Always speak to the team first, explaining that it’s about keeping a step ahead while exploring new technologies and staying on top of technical debt. If the team understands and are up for it first, it’s easier to run past the client.

The best timing to communicate to the client is mid-way through the engagement, once the team has proven their value. Product teams are usually told they are empowered and that they should just go for it, however if there is pushback, perhaps mention to the client that this is how the team operates as part of Agile development.It’s important to get your key client-side stakeholders on board and supportive, maybe agree to trial a single tech sprint first, demonstrate the value it can bring before committing to a regular cadence. 

The timing should be every five to six sprints, and it should be a two-week cycle. This allows developers ample time to come up with an idea, play around with the technology and create a PoC. Just occasionally we might shift back a sprint based on calendar timelines if some go-lives are clashing for half the team.

It’s also important to strike the right balance between innovation and business-as-usual maintenance. While most developers usually work on both innovation and tech debt during the sprint, we also respond to customer support on any live issues, such as something going down or someone raising a bug. Ongoing support is essential to keep things running smoothly.

Ground rules to ensure an effective technical sprint

It’s essential to have some ground rules for introducing a technical sprint, to make sure all goes to plan:

• Backlog sessions: Having backlog sessions for future sprints, is useful to review and break down the real work so that the team can get straight on with it during the next future sprint.
• Stand ups: We still have daily stand ups where the developers will talk about the different things they’ve been looking at, and what their ideas and plans are, and if they are stuck on something.
• Show and tells: At the end of the technical sprint, we have a show and tell where they show back to the rest of the team what they’ve done. 
• Support response: This is the continued customer support to resolve any live issues. Sometimes certain individuals will tie up loose ends from customer driven work (like getting an agreed release out)
• Be relatable to client work: The work conducted in the technical sprint needs to be relatable to client work so that it could bring value to the project later
• Retros: A ‘retro’ should take place at the end of every tech sprint. This is the chance to get feedback from developers on what’s positive and what could be improved. Regularly retroing and tweaking technical sprints will ensure they work well for developers, clients and the business.

To sprint or not to sprint

While technical sprints are a well-respected practice in modern software development, there are occasionally circumstances where they won’t work. In particular, technical sprints might not always be viable for shorter-term engagements or development cycles,  If some of the team are juggling smaller-term projects, there may be too many moving parts to take the break for a tech sprint.

Taking a break from client work every few months is a considerable ask, even for the most understanding clients. But the powerful revelations in the “show and tell” at the end of each technical sprint keep developers, clients and the business motivated for the future.

Owen Hodge is Product Manager at Headforwards.

Image Credit: Martinmark / Dreamstime.com