I’m a software engineer at a company that implements a “20%”. Every couple of months, we have a one (sometimes two) week sprint for the 20%. As you’ve pointed out, it works out to be less than 20%, and many engineers choose to keep working on their primary projects to catch up on delivery dates.
In the weeks leading up to the 20% sprint, we create a collaborative table in which engineers propose ideas and pitch those ideas in a meeting on the Monday morning of the sprint. Proposals fall into two categories:
Reducing technical debt. E.g. deprecating the usage of an old library.
Prototyping a new idea. E.g. trying out the performance of a new library.
I find the 20% sprints very valuable. A lot of the time, there is work I would like to be done that doesn’t fit well within “normal” priorities. I believe such work to be valuable based on my experience and knowledge. However, it doesn’t have sufficient visibility from the perspectives of the higher levels. Therefore, this sort of work would never make its way into our everyday work without the 20% sprint.
Excellent write-up. Thanks, Elizabeth.
I’m a software engineer at a company that implements a “20%”. Every couple of months, we have a one (sometimes two) week sprint for the 20%. As you’ve pointed out, it works out to be less than 20%, and many engineers choose to keep working on their primary projects to catch up on delivery dates.
In the weeks leading up to the 20% sprint, we create a collaborative table in which engineers propose ideas and pitch those ideas in a meeting on the Monday morning of the sprint. Proposals fall into two categories:
Reducing technical debt. E.g. deprecating the usage of an old library.
Prototyping a new idea. E.g. trying out the performance of a new library.
I find the 20% sprints very valuable. A lot of the time, there is work I would like to be done that doesn’t fit well within “normal” priorities. I believe such work to be valuable based on my experience and knowledge. However, it doesn’t have sufficient visibility from the perspectives of the higher levels. Therefore, this sort of work would never make its way into our everyday work without the 20% sprint.
Ironically, it seems to me that “agile” development took autonomy away from software developers, and “20%” gives it partially back.