One of my favorite things to do at work with my fellow engineers is to “geek out”. Whether it’s exploring new technologies, helping, or getting help from my fellow engineers, or participating in a proof-of-concept demo, Design Jam’s are a terrific way to get your team together for learning, exploring, and unwinding and focusing on something other than the sprint board for a little while.
I’ve run Design Jam’s at work on several occasions, including at my current place of employment. They’re really quite easy to plan, and go a long way in helping your team be successful. Like any meeting, you want to approach each one with a plan, with some sort of itinerary that tells those attending what to expect from the meeting. This itinerary can be whatever makes sense to your own team, but I have a specific format that generally use for each of the ones that I run that my teams have liked using.
When I run Design Jam’s, I tend to follow this basic itinerary, shifting it around as needed or as makes sense:
- Question of the Week/Tech Topic
- Follow-ups
- Cross-team concerns
- General topics
- Action Items
- Presentations
First, I try to come to each Design Jam with a so-called “Question of the Week” or “Tech Topic”. I find that this makes for a great opener to the meeting, and helps to foster a culture of learning and growth. I’ll shift the subject of the question each week; one week it’ll be a C# related question, the next week a SQL question, and the following week maybe a question about architecture or design. The point is to come with something that will foster conversation and hopefully learning. For example, one of my most recent questions was “What is a pure function, and why would you use them?” This question alone resulted in roughly 15 minutes of questions and conversation around the what and why of pure functions, and the developers/engineers that I work with now have another tool in their toolbelts for daily coding work that some of them might not have had before. Also, don’t feel like only 1 person should be supplying this weekly topic. I’d recommend encouraging everyone on the team to come up with questions or topics; they just need to be ready to speak to it. 
If there were any action items from last week that needed to be addressed, we’ll next talk about them here. Any presentations that might have resulted from these action items will happen later on in the meeting. Now is simply a time to confirm that action items were completed, or what the status is on any of them.
Next we’ll talk about any cross-team concerns. The Design Jam meeting that I’m currently running takes place between two independent but related teams. These two teams develop and maintain separate applications, but the two applications talk to each other in the course of executing their business rules. Having this section of the Design Jam where we talk about any upcoming stories or points of interest that could affect both teams helps to minimize any collisions that may occur when bits are deployed. Hopefully the teams are talking to each other regularly anyways. But having this regularly scheduled time frame helps to make sure that it’s at least happening on a regular basis.
We’ll then move on to general topics, such as discussing announcements made by the company and how they affect the team and their work. Often times in my experience this topic will be skipped as there’s nothing to discuss that week, but it’s good to have it on the itinerary to make sure that these items, as they present themselves, are covered.
Next, if there were any new action items discussed during this Design Jam, or if there’s any left over from last time, we’ll quickly summarize them here. Design Jam shouldn’t typically be considered a work generator. However, I tend to think of actions here being more like “Julie said that she’d be interested in researching how we might use Redis for Project X, and she’ll put together an RFC on it by next week”. Notice that Julie volunteered for this. Again, the Design Jam meeting is meant to be an engineering “geek out” meeting more than anything, so we don’t want to make anyone feel like they MUST do something.
Finally, if there are any presentations that team members have planned on doing, we’ll ensure that they have the time here to present. I recently did a presentation to my own team on using SpecFlow as a tool for executing integration tests against our HTTP API’s. It took about 20 minutes to present, including questions from the team, though we planned on 30 minutes. That bein said, you’ll want to make sure that you leave enough time at the end of the meeting for those that want to present to do so, including Q&A time.
Obviously, you would need to clear the timing with your manager or managers before setting up a Design Jam at your own place of work. Your manager might ask what the benefit of taking an hour each week or two away from regular sprint work would be to that sprint work and to the team and the organization as a whole. I personally see the answer to this question as the following starting points:
- Develop camaraderie amongst your developers/engineers
- Encourage regular communication regarding sprint work and how it affects those outside the immediate team
- Foster an environment that supports professional growth and learning
- Provide time to look at and discuss existing issues in a unique way
- Gets the team as a whole thinking more about the “larger picture”
If you’ve never considered doing something like a Design Jam with your own team, definitely give it some thought. I’ve found them to be extremely beneficial to the teams that I’ve worked with.
Top comments (0)