Innovation sprints are a thing that software teams sometimes do. Sometimes it's just a way to let engineers work on tech debt tickets that have been sitting around for awhile and sometimes they make it more of an event like a hackathon with project teams and prizes, etc. There's nearly always a stipulation that it must be somehow "work related". 1/8
More than anything, it's a problem if you feel like you can't ever have tickets that "fail". It should be OK to have tickets where you try a thing, realize it isn't going to work as planned, and either pivot or close the ticket in favor of a new one. Life is uncertain, and that's normal. You learn nothing by only doing what you already know. 4/8
On my team when you take a ticket you are in charge of deciding how to implement the feature. If you need help or advice, you can ask anyone or even get the whole team together to figure it out. But if you want to try applying some new technology to your work you can certainly give it a shot. It doesn't need to be a special occasion. 6/8
As a concrete example, in our current project we decided to use a single table DynamoDB instead of multiple tables or a SQL database. We chose to do that because we found this talk, and it blew our freaking minds.
https://www.youtube.com/watch?v=HaEPXoXVf2k
7/8
Has it been a little harder to use a technology we're less familiar with, plus a way of using it that we're less familiar with? Sure. But it's really fast, it's less expensive, less complicated than I feared and so it was absolutely worth the risk. Innovation pays off, and it can be an everyday thing. 8/8
Engineers should be encouraged to keep up to date on the latest technologies. For example, my team watches re:Invent carefully because we're an AWS shop and all the fun new stuff tends to come out during the conference. Many times they've released something that scratches a specific itch we've had. 5/8