I am always looking for ways to add richness to a working environment. I seek creative ways to engage colleagues and solve problems by creating an environment for value and innovation to emerge. One way that I discover new ideas is by connecting with similarly responsible professionals from other companies. While I was on-site with a partner company, I spent a considerable amount of time chatting with one of the engineering managers, who had thankfully shared their concept of a developer sprint with me.

The Developer's Sprint

The Developer Sprint concept is a feature of SAFe, which stands for the scaled agile framework. Allowing time for innovation and planning as a follow-up sprint after a release - in this case, we are talking about releasing software. Teams practicing SAFe spend an iteration reviewing their current state and make improvements to their processes. My manager friend described the Developer Sprint as a sprint where the engineers spend time preparing for the work ahead.

What is in it for me

As an engineer myself working on projects with other engineers, I have always found pockets of opportunities that I never had the chance to spend time realizing. The majority of what I spend my time doing is taking in requests from the people around me, providing clarity where details are missing, and calculating how long it would take to deliver on an idea. Working on a team, I never heard questions about how well we were doing. Questions like:

• What is getting in our way of being able to achieve this?
• What is slowing us down?

It just never happened because we always focus on the next increment. Often, the increment quality is measured by the number of new ideas that the team produces. Rarely is a group asked to introspect on their processes, inclusive of the objectives they are being asked to accomplish. Here is where my excitement started. If I could do a good enough job framing out what I expected from the team beforehand, I could create an environment that would improve our work. I also put myself in the individual contributor's position and thought back on all of the missed opportunities. If I were given just a portion of the duration to spend on things I felt were necessary, it would have had drastic changes to the events we hoped to achieve. Finally, I understood that I would also have more ownership of the outcomes by spending time in this way.

We talk a lot about ownership and accountability. The developer sprint philosophy seemed compelling to me in the ways mentioned, but how do I run them?

Designing our first Developer sprint as an experiment

When I work with a team, there are several ceremonies I like to establish.

• Onboarding
• On-call rotation
• Private coaching and group coaching
• Time for learning and discovery
• Time for communicating what is happening in the environment around us
• Time to discuss the possible future

For our first Developer Sprint or Dev Sprint, I knew I could not just spring this event on the team, so they had to become a part of the planning. If I give the planning and prioritization responsibilities away to the team, I also need to provide the team with means to set expectations and hold the team accountable. Since I was treating this as an experiment, I had to control how much investment I would sacrifice for learning. With these immediate boundaries in mind, I then went to the team and proposed the idea. I took feedback from the team, including asking the question:

Is one week enough for this experiment?

The developer sprint experiment outline

We set up our first developer sprint like this:

1. We decided one week was enough time to get something meaningful over the line. We also agreed it was a safe enough amount of time to lose based on what we were signing up for in the current quarter.
2. The product and technical people had to provide the strategic targets for the quarter well in advance. We had to give the team enough time to think about the most effective ways to spend their time.
3. To help establish accountability, we stole from the hackathon process and introduced the pitch day. Those participating in the developer sprint would pitch their ideas to the team. The team would provide feedback based on relevance to the objectives they knew they needed to achieve. The pitch day also gave the technical and product people an opportunity to give feedback and listen to how people described what they understood about the work.
4. The second stage of establishing accountability is that the pitch day's promised outcomes have to be presented with our stakeholders to conclude the developer sprint. Team demonstrations are a standard feature in a scrum, so we had the means to make this happen.
5. Experiments require analysis, so gathering feedback is essential. We promised to perform a retrospective on the developer sprint.
6. During the developer sprint, we reduce meetings. All traditional ceremonies are limited to an as-needed basis. These are meetings like one on ones, various guild or group meetings, or meetings with other teams—anything that we could pull off of the calendar we would.
7. And finally, I sprinkled in a little bit of novelty by establishing a peer-review process. After the demonstrations, participants pick their top performers in three strategic categories:

• Project completeness: can we ship it?
• Cleanliness: Does it make sense? How well did it ship?
• Leadership: How well was the project executed?

People are not allowed to vote for themselves, and they may select only one selection per category. I then established some very simple prizes (toys, board games, and candy), things people wouldn't miss but would feel great about themselves—a little bonus, which is not too strong to create unhealthy competition. While friendly competition may emerge, it shouldn't take priority away from improving our quality of life.

Results from the first experiment

The first developer sprint went well enough. It gave the product and technical leaders an idea of how far in advance we need to be thinking to allow the team to plan well. It also awoke a new perspective for the individual contributors in our little organization. We concluded the developer sprint with our demonstrations, and it took us half of the day, four hours, to get through all of the things the team accomplished within that one week. The energy coming out of the newly discovered enthusiasm was contagious, and we all had a new outlook on what was possible.

One of the engineers on our team identified a strategic project requiring many product teams to build new features. At the same time, we had very different goals. This person decided to take advantage of our team's position to do something good for all of the other teams to do this work. This engineer knew that the other groups would have difficulty collaborating and put the goal at risk. They decided to spend the developer sprint scaffolding out code components that could be used by all other teams in the organization. The engineer delivered these new shared components, and the rest of the company stood to benefit, which ultimately ended up in the hands of our customers.

Capturing the emergence of opportunities

In complex systems, we can never predict where we will end up. The best thing we can do is use our best judgment using existing patterns to determine where we are trying to go. New opportunities or new ways of seeing how we fit in an organization can emerge from experimentation. The story shared earlier about the engineer that built the standard code components, we now actively seek out such opportunities and add them to our goals. We inherited new stakeholders and created a new type of value proposition for our team. We continue to get new investments and responsibilities, the mark of a successful team or organization.

During the developer sprint experiment, please pay attention to how people describe the opportunities they see in front of them. Capture these new ideas and see how they can add meaning to your culture and the broader community.

Feedback from the first iteration

I was able to distill a few things we noted about how the developer sprint resolved:

1. We had a lot of distractions. Several projects were still in motion, and we did not do a good enough job in protecting the team's time.
2. The team allowed for the earlier sprints commitments to roll into the developer sprint. We wanted to fix this.
3. The team generally wanted more time to spend in the developer sprint.
4. The team management (myself the manager, our program manager, and product owner) also agreed that the outcomes from the developer sprint were highly valuable. Additionally, team management was also thrilled about the emergence of new ways of working with the broader community and the sense of engagement everyone shared.

Closing our first developer sprint, we knew we had a pretty good formula for operation. And we would focus upon doing a better job of clearing the schedule, protecting the team's time, and extend the developer "half" sprint into a full sprint. Our experiment closed with zero adverse effects. Our group met or exceeded all objectives for the quarter. With results like these, it is hard not to perform another experiment with the developer sprint.

Iteration two of the developer sprint

For iteration two, we extended the developer sprint by an entire week. The team was delighted, already adding enthusiasm for the event. This time the group already started to think about what they would spend this time doing. They thought back on all of the conversations we had about computer languages and frameworks. They thought about the pain points our customers were seeing. It was up to the team's management to keep an open mind about scheduling to take full advantage of opportunity emergence--much like what we experienced in the first experiment and the common code components. What is beginning to happen naturally is that we invite our team to think about their customers broadly. We are distributing what it means to think about the product strategy.

Developer sprint two ran better than the first iteration. The team had an additional week, which gave them a buffer to tolerate the inevitable rollover of work from the previous iteration. We also noticed that the team took on a bit more risk in their ideas; they pushed their boundaries of what they thought was possible. Some common themes were:

• Personal development as a subject matter expert in a technology we were promoting as a new standard. Specifically GraphQL.
• Learning a programming language they needed to become more independent.
• They are learning a NEW programming language to make a tool more portable and easier to use.
• We are building a new tool to make the development of other types of software more accessible.
• They are exploring partner companies and their API's to educate the team and provide working examples.
• They are cleaning up design decisions in a library they developed for the sake of being able to apply this solution more broadly, making the lives of our team and the ones that depend on us simpler and efficient.
• Develop a new way to communicate what is happening in our CI/CD pipeline and automate away laborious processes that humans would better off not handle.

Side effects worth mentioning

Closing the second iteration, the team began to challenge detractors from the developer sprint. They began to collaborate on tightening up traditional sprints to better prepare for the next developer iteration. The team has a new stake in the agile process. The developer sprint gives the team a parallel to the traditional sprint workflow to dogfood our scrum process. Naturally looking for ways to improve every sprint iteration, we start.

Real feedback from the team

As part of the feedback loop, we ask the team to participate in an anonymous survey. We use this survey to get a sense of how the team responds to an experiment, and we look for opportunities to improve. We ask what went well and what can we improve.

Here are the responses from the team:

What went well

• The ability to shape our ongoing sprint and also the dedicated time to pursue the projects you feel would help our company. It gave us opportunity to show that an individual or a team can accomplish same thing in 2 weeks without any interruption which would take probably months when we involve outside factors. This forces us to rethink which blockers are really blockers and which one are just noise or our unwillingness to try something new and disruptive.
• Ability to pursue interesting and useful ideas
• Time to work on something that will benefit us in the coming quarter(s) outside the scope of product work. Feeling of accomplishment at the end. Support from external teams was great. 2 weeks is the right amount of time.
• Was able to familiarize myself with a few technologies we don't normally use, as well as think more deeply about CS concepts
• Creativity, freedom, ownership and time to explore new things
• Let me work on meaningful work I may not otherwise have the time for! Great innovation and personal development come from it.

What can we improve

• Nothing at all. More of it. Make it a company culture. More like a festive our company Refresh You Spirit Sprint.
• Everyday distractions (support, reviews, etc) make it hard to focus on the project.
• Made me work late, because I was interested. Not sure that's a bad thing though. I enjoyed it. Some distractions but not as bad as last dev sprint.
• Maybe having the quarterly goals a week earlier would help for better planning.

Is a developer sprint right for you and your team?

The thing about complex systems is that you cannot copy a process into another organization and expect the same outcomes. But if we break down the exercise and prepare to run a developer sprint as an experiment, then the learning process can begin. If you can carve out a corner to try a developer sprint on for size, start small. Establish a feedback loop and use that information to make informed decisions about what to do next. Stay open-minded and remember this is not a structured process but an exercise in experimenting with developing productivity, engagement, and resilience within an organization.