I've had the benefit of working at various companies where Lab Days or Innovation Days are a thing - or a thing I've been able to introduce.
This repo contains the code and outputs of Lab Days - either professional or personal. Projects here will be quick plays to try a new technology, solve a problem, or just learn something new - ideally, all three.
Not all Lab Days will result in successful outputs but that's OK - failure is an incredibly valuable way to learn. Where I've failed I'll typically aim to ensure I record any lessons or thoughts in the README or accompanying presentation
Each dated folder will typically contain a project for each Lab Day ; check the README.md file in each folder for further details.
Want to know how to run your own Lab Days? Read on....
Lab Days are all about playing, learning and sharing - at speed. With that in mind, I find the following are crucial to success:
-
The team should get together a few days before Lab Day and choose a topic, outcome or idea they want to achieve ; this should be recorded in a README, Confluence, or whatever your chosen collaboration system is
-
People are free to choose their own ideas for the day ; avoid "the business wants you to look at topic X". Solving team or company problems is fine, but this should be owned by the team, not dictated to
-
Solo is fine, and pairing and tripling are great too! Try and mix it up between days ; if you are solo one day, look to pair up with somebody the next. Sometimes this can be best achieved by not having your own idea, but asking if you can pair up with somebody in the planning session.
-
These are not 'normal' days, so no ceremonies - no standups, no progress meetings, no support rota. Everyone should be free to focus on their time without distraction ; if the company can't facilitate this, figure out why...
-
As no ceremonies, the team are free to work on their schedule - start early, finish late, whatever works for them
-
Work using the Pomodoro technique ; 25 minutes on, 5 minutes away from the computer to stretch and clear the head. Taking frequent breaks often feels counter-productive to engineers - we often feel like we're just getting 'in the zone' - but the importance of pulling yourself out of the forest frequently can't be overstated. I find it's often whilst staring into the abyss of the coffee machine that my current mini-blocker gets resolved.
-
Avoid trying to do things properly - Lab Days are about quickly proving something, not standing up a production environment. If you regularly build infrastructure in Terraform and are trying to use a n ew technique in AWS - don't research the Terraform resources to build it, start hacking around in the console and API. Focus on doing the what in the quickest way possible ; cutting corners and experimenting is fine because you're hacking away
-
Record notes as you go ; README's are great for this, but even a private Slack channel with short 'trying this' notes can be a great way to record what you're working on with a timestamp.
-
Aim to have something to show at the end of the day ; a live demo, a recording, or a slide deck on how your grand lofty ideas went horribly wrong and what you would do next time to avoid them - anything is incredibly useful for yourself and others.
### After
It's presentation time! Lab Days are only half-effective if you don't share the knowledge - so:
-
Hold a team presentation even the morning after ; limit the opportunity for people to dip back into the project after Lab Day to polish and improve
-
Each person or team that has done a topic has five minutes to present - hard limit. Set the timer and start the soft round of applause at 5m00s on the dot
-
Celebrate the successes and failures and take the opportunity to learn about new things you've done and the strange - even wrong - ways that they've been implemented.
Changes released in each version can be found in CHANGELOG.md