David Schmitz
CTO
In the last couple of years different companies tried different means for improving company culture.
We at Senacor face basically the same challenges as non-consulting companies.
Meaning: too much to do and not enough time to play, learn, innovate.
So, in 2016 we tried an experiment.
We chose a Thursday in September and all developers were “removed from active duty”.
The developer could use that day for whatever purpose.
Whether or not they build small teams, or do whatever they want alone…only one rule:
the day after the sprint, everybody gets together, grabs some food and shows whatever he or she did, learned, tried.
To be honest, we were not sure about the potential of that approach.
No guidance, no rules, no fixed scope…that means no real result, or not?
Boy, were we surprised.
First experiment
The first sprint was held in September 2016.
40 developers were part of the sprint-team.
To support the developers with ideas and maybe cross-polination of ideas, we asked them to add a tiny note to a dedicated wiki page.
They should just write in one or two lines what they were going to to.
The intention was not to control, but to maybe get developers together.
Some wrote just “No idea yet”, then saw one of the other ideas and formed teams spontanously.
The results were surprising – in a good sense.
- experiments using the android toolchain
- building a mobile-pay app using siri kit
- blockchain with ethereum
- smack stack
- sensor tracking on a football table
- hands on paas with azure, bluemix
- Slack bot with Elixir and Phoenix
- multiplayer Tetris with Node and Mithril
- payara micro with openshift
- …
It was amazing to see so much self-learning in our community.
Code was created, ideas formed without any external influence, well other than time, food, beverages.
The second 24h sprint
The first sprint was so successful and well received, that we immediately planned a second sprint in december 2016.
This one was tougher to schedule right.
Both the christmas season and the typical end-of-year deliveries at our customers made planning hard.
Nevertheless, 39 developers were part of the second sprint, this time we even included some of our consultant collegues, which were interested in the approach.
Once again, the results spoke for themselves.
- a React and Node based tool to improve staffing and project setup
- a Lego and Raspberry PI based robot, that drives through the office takes pictures and analyses the pictures using Amazon Machine Learning
- coding a JUnit 5 extension
- ai with roomba for scanning the office premises
- smart contracts
- crawler and aggregator for cucumber results based on Ratpack
- a BeerFriendFinder app for iPhone based on Flux for Swift
- Machine learning deep dive
- totally over-engineered smart home application using Arduino, Mosquitto and a buch of other technologies
- ball tracking based on open cv with advanced analytics
- writing RFID cards with arduino
- bare metal with Rust
- travel plan based for an actual project đ – yes, this is allowed, too
- …
Lessons learned
Every experiment needs feedback and validation.
So we used a simple questionaire to see what and how could improve.
There were several key findings.
First of all, we discovered that planning is an issue.
People need to be informed at least a month in advance.
Projects must be informed because potentially all developers are unavailable at a specific time and date.
Second of all, it showed, that communication was lacking.
The actual goal and rules were not clear to everyone.
Third, equipment is an issue.
The presentation of the results was badly moderated and the camera/sound infrastructure was severly lacking.
Forth, we need to actually advertise the format internally.
Not all leads know what we are doing during such a sprint.
Transparency needs improving.
Last but not least, the people loved the format.
They want more not less, at least once per month.
So were does that leave us?
The sprints were successes, on all levels.
For the future, we plan to hold 24h sprints at least twice a year, possibly more.
The organisation will be planned in advance.
For example, a dedicated host will be assigned to each office, where participants are located.
The host will be responsible for organizing food and beverages but also for moderating the presentation of the results.
In the future we will also extend our “internal” marketing.
To broaden the appeal we need to improve the transparency.
Everybody, participants and non-participants, needs to understand that the 24h sprint is not some cheap way for “slacking off”.
Finally, we strife to actually include consultants not only developers into the sprints.
This might be an even greater potential, as we all know, that cross-functional teams are key to innovation.
Conclusion
Obviously this is just a single step in the right direction.
Innovation and learning are not a cost factor but an investment.
Do not underestimate the potential of your collegues.
Innovation in general does not “appear” due to some planned process.
This simple measure of giving people some time to do whatever they think is interesting or of value has visible positive impact on our culture as developers.
Developers understand, that the company values innovation.
And the company understands, that innovation and self-learning is fundamental to developers.
You need time and space to innovate.
Learning is key and you should make room for it.