Finishing a Scrum sprint early means time for innovation
When you finish your sprint early, you get legit time to encourage forward thinking and push developers to innovate.
Scrum imposes an intense pace. In fact, your team will work at the highest of its velocity to deliver product increments with high business value. It would not really make sense to commit to less than that. But, is it not at the detriment of innovation and creativity? Do you get any time in your sprint to let developers try out new things?
Well, you might not have realized it yet, but Scrum is a great framework for innovation. There is a trick that will: motivate your development team to adopt forward thinking in daily work; drive technical innovation across the company; and improve the general quality of products.
In this post, I will explain why I decided to introduce more innovation in our sprints. I will also tell you where I found the time to do so in sprints. And, what results our team got from this practice after more than 15 sprints (of two weeks each).
It all started with some frustration.
During sprint plannings and sprint retrospectives, I noticed some frustration from developers. Why? Because with Scrum, they rarely get the chance to be creative, innovative, develop new technical skills, or experiment new technologies. In fact, sprints impose a high pace. The development team works at the highest of its velocity to mainly deliver product increments with high business value.
For a few sprint plannings, a member of the development team, named Gab, kept pushing for the implementation of Hystrix. And, this suggestion made absolute sense. In fact, in our microservices-based environment, Hystrix was a great solution to control the interaction between services by providing fault and latency tolerance. But, in our company, we were not using Hystrix. It had never been in the technological pipe either.
There, I was between a rock and a hard chair. On one hand, I did not see how I could add the implementation of Hystrix in a sprint. We had so many high value business features waiting in the product backlog. How would I justify the cost of implementing Hystrix to our business sponsor? How would I prioritize it over business features? On the other hand, I really wanted to encourage developers to think forward and take initiatives to drive technical innovation and improve our products. But when?
Do you get any “free” time during your sprints that you could use to introduce innovation?
When one sprint ends, the next one starts right away, right? This is best practice. But, does it mean that you have no free time in your sprints? Of course not.
Here is when you get this free time.
It is so difficult to plan a Scrum sprint in a way that the developers work at full capacity throughout the entire sprint. It might happen that a Scrum team over estimates the work and effort necessary to reach the sprint goals. I mean, who would know, in advance, what it takes to achieve a task or even reach a sprint goal?
Hence, it may happen that your team finishes the sprint early, or that a developer finishes off all of his tasks before the end of the sprint. In fact, people naturally tend to be careful. So, how would you manage this « unexpected » and « unplanned » available capacity you have until the end of the sprint?
I guess that most of the time, product owners will use the product backlog to assign new tasks to the developers. This practice raises many questions that I will not talk about in this article. I am sure there are many other practices that product owners use to manage a sprint finishing earlier the planned. Here is my favorite practice:
How about giving your team this free time to create, innovate, and improving your products?
Wait, giving developers free time to innovate does ring a bell, does it not?
This idea, or inspiration, originally came from Google’s legendary « 20% policy for side projects ». I am not quite sure how it works there, or even if it is still in place, but I truly believe it is a great idea for multiple reasons. In brief, you encourage forward thinking and give your employees a real opportunity to personally take initiatives, defend their ideas, and implement solutions.
As I said, Google’s “20% policy for side project” was just an inspiration. In this context, I am not talking about side projects. I am talking about finding quick wins to improve the products we are working on.
And, here is how it goes with Scrum.
I asked Gab to take some time to analyze Hystrix and plan a short presentation for our Scrum team. At the end of this meeting, we added the following Epic to the product backlog: « Hystrix implementation in the Delivery component ». Under this Epic, we had a 3 user stories. All together, we estimated the implementation of Hystrix to approximately 5 man/days. (Arf, I don’t like to talk estimates in man/days. The real estimates for these stories were 2 hamsters and 1 dog, but this is another story).
There we had theses stories in the product backlog. We now had to find a way to add them to a sprint.
A few weeks later, Gab finished his tasks early in a sprint (on a Wednesday). The other developers were on track with their tasks. No worry there. So, this was a great opportunity for Gab to start working on the implementation of Hystrix. By the end of the sprint, he had only one task left. We planned it as a priority for the next sprint. There, in two sprints, we added this new technology to our component. Today, Hystrix is implemented in multiple components in our company.
Why does this work great with Scrum?
I truly believe that you cannot cheat with Scrum. As a Scrum team, you know your velocity. The product owner will challenge the team to achieve as much work as possible during the sprint. The team will most probably commit to quite aggressive sprint goals. At some point, all stakeholders (business sponsors and customers) get the idea of what the Scrum team can deliver in a sprint. They will expect no less.
As long as you maintain a high level of velocity (or improve it), and as long as your business sponsors and customers are happy, you should believe that you are doing right. For all these reasons, finishing a sprint early should not be a problem. It should not be considered as bad estimates. It is not cheating. So, why not giving this time to developers so that they can innovate?
5 rules to manage these innovation initiatives
- Any initiative must intend to improve a product. This is not a proper google-style side project.
- The initiative should be presented to the Scrum team and concerned stakeholders, such as architects, for validation.
- If accepted, then add the initiative to the backlog for the follow-up. I like to label these stories as “innovation-story”.
- If you started it, you must finish it. Your initiative should not remain an unfinished PoC.
- When implemented, communicate it to all interested stakeholders.
The upside and the downside
On the upside, giving this free time to the development team will enhance forward thinking. Team members will know that they can share their ideas and actively contribute to the technical evolution of products. It will also be a chance for them to gain new technical skills. As a whole, the motivation of your team will remain high. This will also help you build more robust products while driving technical innovation in your company in general.
On the downside, this is quite complicated to manage due to its unpredictable nature. In fact, getting free time at the end of sprint will not happen on every sprint. It is more about being ready to seize an opportunity to innovate when it comes. Also, I want to raise two risks here. You have no control on who finishes a sprint early. What if it is always the same developer? And again, if you start something, you must finish it. Otherwise, you have the risk to have eternal proof-of-concepts (PoC).
Conclusion
Innovation is important. Your team members should feel that they can have an impact and drive technical innovation within the team, but also across the company in general. I believe this is key to maintain motivation high. Then, working with Scrum sets a high pace. Introducing innovation in sprints requires your team to have a high level of maturity.
I would definitely recommend trying this practice once you consider your team mature enough. Do you have a fast and constant cruising speed? Also, it is key to have a relationship of trust with your business sponsors and customers. If this is the case, I suggest you give this practice a try.
Working this way, our Scrum team implemented Hystrix, FlywayDB and Selenium within 12 sprints (6 months). In parallel, our team always committed to sprints at the level of our velocity, or higher. Our business sponsors and customers were still happy and satisfied with our work.
