Grow a culture of innovation and learning with frequent Developer Huddles

Without skilled developers, the Scrum Framework is no more than lipstick on a pig. Having to create — and hopefully deploy — new versions of your product every Sprint is a tall order. But it's also necessary if you want to reduce the inherent risk of the complex work that is product development. It's a huge disservice to state that developers are only there to code. They are there to solve the complex puzzle of how to deliver a valuable increment within the span of a single Sprint. This requires intense focus, creativity and clever use of technologies and tools to determine what must be included now and what can be done later. 

“Its a huge disservice to state that developers are only there to code. They are there to solve the complex puzzle of how to deliver a valuable increment within the span of a single Sprint.”

But how do you create a culture where this craft is clearly understood? And more importantly, where developers can learn, innovate and experiment to become better at his craft? As a passionate developer myself, I’ll be the first to admit that not all developers connect with their craft that strongly — often because they’ve never been encouraged by their organizational environments to do so. 

Recently, William Water and I had the pleasure to host a session about this at the XP Days Benelux 2019. William was my colleague at NowOnline, a company where we established a pretty strong developer culture. In the workshop, the 30 participants shared and developed low-tech strategies to ignite Development Teams. I will be publishing them in the coming months, as I believe each of them can help you move forward. In this post: start a developer huddle. In the previous post, I explored how to start a book club.

Host a Developer Huddle

In my teams, I always enjoy hosting ‘developer huddles’. Sometimes we also call them ‘tech talks’, ‘coding sessions’ or just workshops. However you call it, it boils down to bringing developers together to learn.

For example, at NowOnline we hosted weekly ‘tech talks’ every Friday-afternoon. I took the initiative to make sure they happened and even hosted the first couple, but this becomes more self-organizing over time. We balanced between topics that focused on coding and development (e.g. feature injection, specific design patterns or new technologies) and relevant soft skills (e.g. customer orientation, how to give feedback, product vision). We also used our networks to invite people from outside our organization to host relevant sessions. For example, two social psychologists hosted a session on decision-making in groups. Another session focused on value-added consultancy. And we often invited developers from other companies to show us what they were the proudest of. I have vivid memories of one particular huddle where developers were eagerly demonstrating the code they were most proud of while at the same laughing about how their passion was shining through.

In one team, we used a simple whiteboard to maintain a schedule. This was the first version we tried. People could suggest new topics or pick the ones they wanted to host.

Another example is ProRail, where we organized huddles for the various crafts. So there were frequent huddles for Scrum Masters, developers, testers and designers in addition to general workshops. At yet another company, Van Meijel, we organized huddles around metrics and continuous delivery.

A huddle by developers, testers, analysts and product owners on how to come up with the most relevant metrics we could (which we did with just paper, printed charts and glue).

Three principles have always been important to me:

• Every huddle should end with asking everyone present to write down the next step for themselves. Now that they know this, what is something they want to explore, try or experiment with?
• The topics and the hosting of huddles should be as crowd-sourced. Although its fine to take the lead initially, this is a good area to demonstrate servant leadership by letting others take the stage as soon as possible (and support them as needed);
• End the huddle by transitioning into a social activity. The least-involving way to do this is to just bring snacks and drinks with you to consume after the huddle. It is a great way to build team spirit and to continue the conversation;

“This is a good area to demonstrate servant leadership by letting others take the stage as soon as possible (and support them as needed)”

Steps

There are many ways to organize “Developer Huddles”. Here’s a simple way to run your first one:

• The best start is to bring together a group of developers to start this initiative. Create a backlog of topics (e.g. with 25/10 Crowd Sourcing), clarify the purpose and create a schedule of upcoming sessions. Picking the same day and time is advisable as it creates rhythm. I’ve listed some potential topics further down this post;
• Invite people as openly as possible. Don’t require or suggest that people join. Instead, invite people based on their desire to learn how to do their current work faster, better or safer. I’ve found that it works better to have a handful of intrinsically motivated members than a whole group of people who don’t really want to be there;
• Open the first huddle by re-iterating the purpose;
• Explore the topic at hand with the group. This can be a short presentation followed by an interactive round to make sense of it together (e.g. with 1–2–4-ALL). The Liberating Structures Celebrity Interview or UX Fishbowl work really well when you have people sharing their experience;
• Close the huddle with something like 15% Solutions to identify what people want to do with what they learned;
• Announce when the next huddle will be and who will be leading that one (or ask for volunteers);

You Know It Is Working When …

• New topics for upcoming huddles are identified by developers while they are doing their work (“You know, we should do a session about X”);
• New faces start showing up for huddles, and visit again the next time;
• People refer to what they learned during a huddle while doing their work;

Potential topics

Developer Huddles can be about anything that matters to them. Here are some topics that I have the fondest memories of:

• A Design Pattern shoot-out where we explored the most basic patterns (eg. Factory, Singleton, Strategy, Facade, Mediator);
• Explore the impact of branching in version control systems like Git and having a single integrated experiment. We adopted Gitflow after this session, with a rule to merge everything back into the master-branch at least before the end of the Sprint;
• Practice with giving — and particularly receiving — feedback. We used the Situation-Behavior-Impact pattern. Despite some initial awkwardness, people enjoyed this huddle a lot;
• Explore strategies for dealing with conflict in your team. You can explore the Pinch-Crunch model, for example, and see how it works in your team;
• Ask people in your team to share their hobby projects. We had one developer who worked on a mobile game in his own time. Another developer played around with Raspberry Pi’s. Seeing someone’s passion for technology is contagious. And that passion can help people connect that otherwise don’t enjoy working together;
• Explore strategies for dealing with technical debt. In this session, we learned how static code analysis can help us get a better sense of the quality of our code;
• Engage in some pair-programming to write automated tests. For example, I participated in sessions on Cucumber and SpecFlow. Or even writing simple unit tests;
• One of the most important things that developers have to learn is to break-down their work into smaller, vertical slices. So hosting a huddle on this is highly recommend. I wrote this post for a huddle that we organized for this;
• Developer Huddles are awesome opportunities to learn about Scrum and empiricism. For example, our Definition of Done exercise can work for this. Or play Lego4Scrum;

Closing words

Creating a developer culture — where developers are eager to advance their craft — is really not that hard. There are many simple and low-tech strategies you can use. In a previous post, we explored how you can start a book club. In this post, I offered my experience with organizing “Developer Huddles”. Its a lot of fun and builds team spirit among developers. Give it a try and let me know how it goes!