Open Dev Days at Adobe Hamburg

by Jonas Honisch, Timo Eckhardt, and Stefan Makswit

The problem

In a previous team retrospective, the question was raised if we, as engineers, are as innovative as we could be. Surprisingly, the answer went like this: Um, NO! Of course, we are working within an innovative company, but we didn’t think about this applying to our work. That needed to change.

But where to start? At least this step was easy.

A while ago we established the concept of guilds (inspired by the article of Henrik Kniberg & Anders Ivarsson from Spotify). So, this is what we did — we founded the Innovation Guild. Mind you, a guild is an engineering-driven format to take on a topic. In other words, the initiative was not imposed but supported by the management, so we were encouraged, and we had their trust.

We used the first meetings to step back and ask what innovation means for us.

Gathering data during the initial brainstorming meeting

A first insight we gained was that innovation can happen in many different situations with varying degrees of impact. Some examples might be starting to use another, better-suited library; building a service based on a new framework; or using advanced machine learning techniques for solving business-relevant tasks. But in all of these scenarios you need some level of freedom to try something new. To innovate, you need to take a risk with the possibility to fail.

Also, working as a software engineer means to work in the tension field of creating value and dealing with tight time schedules in a fast-moving environment. Sometimes, this can lead to situations that feel like you are cutting a tree with a butter knife, not noticing the person who is handing you a chainsaw. In such an environment, it’s hard to look up from what you’re doing and take a risk on something new.

Against this background, our first goal was to encourage our colleagues to try new things or start working on a side project they’d had in mind but hadn’t pursued. In order to create room for new ideas, we decided to organize a hackathon for the ACP-CS Hamburg team. We think hackathons are a great format, as engineers can use them to spread their ideas, connect with fellow teammates, or just brood in a quiet room for two days and try something different. We also hoped to create room for seed projects that could last beyond the hackathon and enrich our engineers’ daily work. The hackathon happens within a dedicated time slot; in our case, we requested two days, which made it easier to get the green light from the leadership team.

Open Dev Days

After we got approval from the leadership team for the two hack days, we went to work on all the details to make the best of our innovation event.

First, we needed a name for the two-day event. A short brainstorm resulted in “Open Dev Days” over “Hackathon,” to give our event a more serious coating.

To motivate more engineers to participate, we decided on a more grassroots, word-of-mouth announcement. We printed small posters and spread the good news at daily stand-up meetings.

Whether it was our advertising or the free cake, nearly every engineer of the ACP-CS Hamburg team showed up the day of the event.

The agenda was introduced, followed by a speech from our engineering director. He set minimal constraints regarding the topics we worked on and the expected results. The only expectation of the participants was that they present their work on Friday afternoon—either showing off a prototype, sharing a project design, or explaining what problems occurred while working on the project. If everything failed, at least the “gains of experience” can be interesting and useful for the others. We also decided against having a jury and prizes to make sure that everybody was shown equal appreciation. This idea is based on our belief that creativity comes form collaboration and not competition.

The pitch phase followed. Every engineer with an idea was granted 90 seconds to pitch her idea and name requirements, number of collaborators, or skills needed. In the end 17 idea cardboards were hanging on the wall. Every engineer joined a team by putting a sticky note with his or her name onto one of the cardboards.

Pitched ideas on the wall

Hereafter, the teams scattered among the booked meeting rooms and empty offices and went to work. During this time, it seemed that the office was quieter and more focused than usual. An interesting aspect was how differently the teams approached their project. Some first “groomed” their ideas then broke it down into a project plan. Others started to code right away — whatever suited the idea and the team best.

On Friday afternoon, everyone was eager to push their project into a state they could present. Each team had seven minutes to showcase their result. We saw a colorful bouquet of ideas and will pick three for this blog post.

Pictagram

In the spirit of eat your own dog food, a team of four engineers created a picture-sharing app named “Pictagram” (not to be confused with a famous competitor), using our cloud solution as a backend. They showed how quickly a full-stack prototype could be implemented using React Native.

Project status: Prototype, not continued.

Where is my Commit-bot?

A team of six created a Slackbot. It shows the deployment state of a specific feature that has been committed to the master branch of a services repository.

Project status: Finished, deployed and in use.

This is how the Bot looks in Slack

Which features will (possibly) be broken by my changes?

Tatiana created a tool to find relevant code files for a certain topic. 
Example: If I plan to apply a change to the rendition pipeline, I type “rendition” and the tool shows a list of Java bundles and key classes that are involved, each with a relevance score. The search engine is powered by machine learning and is trained on all project sources in advance.

Project status: Prototype, planned to be continued by the Documentation Guild.

***

When the applause after the presentations ebbed away, we headed to a small craft brewery Überquell, near the office. The crowd of innovators slowly trundled in and grabbed one of the craft beers to enjoy with pizza and live music at the rustic wooden tables.

Encouragement and trust

Of course, Open Dev Days were a success. Teams were motivated, the projects produced cool results, and everyone who attended gave it a thumbs up. In a follow-up retrospective, we also gathered ideas what we will change next time.

Participants: First of all, for our next event, we will invite everybody from the Hamburg site. We have many teams here with different focuses aside from Cloud Services; we also have teams working on audio, video, and photo software. We believe opening this event for more participants will inspire each of us to think outside our box, and to get a greater glimpse of other technologies, projects, and Adobe in general.

Venue: Because we had a very nice venue for the closing team event, we also thought about doing the project presentations at the venue.

Forming teams: Building project teams should not be restricted to the day we run the pitch event. People should be encouraged to talk about their projects as early as possible and form teams around them.

***

Open Dev Days created a great momentum of creativity and innovation. The question we have to answer now is how to keep that momentum. Innovation is not a one-time effort but a process of recurring activities to keep people inspired and encourage them to think outside the box.

Creating an innovation framework

Open Dev Days will not be a one-time event. It will be repeated twice a year, around the 4th of July and around Thanksgiving.

Because ideas arise constantly, we established a tool to collect them. If you have an idea, write a few words, share it, and then everyone can read and participate.

We want people to drive their ideas. As it could be a mental barrier to work on a side-project as part of the daily work, we created a dedicated space. Two of our meeting rooms in the Hamburg office are now reserved for working on these projects. These rooms are open on Fridays to encourage teams to work together on their projects.

We also see guilds (mentioned above) as part of our innovation framework. Guilds allow people from different disciplines and feature teams who share an interest in various topics (e.g., quality assurance, system monitoring, various programming languages, etc.) to meet regularly. They discuss ideas to improve our daily work, share experiences, identify problems or upcoming challenges, and more. This fits perfectly with the approach of having dedicated time and space to work on such projects.

***

After our first event we learned that innovation in a company cannot be introduced with one event — it is a mindset. It is like a garden, requiring fertile soil, constant attention, and a lot of work.

Follow the Adobe Tech Blog for more developer stories and resources, and check out Adobe Developers on Twitter for the latest news and developer products.