3 Practices for Integrating Learning into the Work Week
dev processes teaching

3 Practices for Integrating Learning into the Work Week

webs
webs

Photo by Kelly Sikkema / Unsplash

Pretty much everyone has heard of the lunch and learn, you spend your lunch at a workshop or talk in order to learn something new. Lunch and learns are great, but sometimes spending your lunchtime to improve your professional skill set isn't exactly appealing. We all need a break. There are some processes that you can embed into your work day to get that learning in and make it a normal part of the professional day to learn new things. If you're an executive this is a benefit because your people will always be learning new things so you'll have a killer skilled workforce. Also, it'll be part of the work they/you typically do anyway, just a bit more intention and purpose around the learning part. It'll also reduce stress and keep folks happy because they/you won't have to spend leisure time feeling like they/you have to read and research in order to keep up with the latest trends. It's a win all around.

Spikes

Smile for me, iguana
Photo by Christopher Beddies / Unsplash

Duration: Hours to days

When to use it & what's the benefit

If you're thinking about doing work but there are a lot of open questions, that's a good indication you should do a spike. A spike is narrowly scoped research on a topic, tool, or implementation strategy. For example, a team I worked on had to move resources in Azure from one resoure group to another for an application that was in production. In order to make sure we knew as many of the possible consequences as we could, we did a spike. We looked at and experimented with moving each resource in dev first and developed a plan for how to do it. We documented the plan and wrote the stories for the actual execution work to be done.

You're already there, why not just execute on it?

There are a couple benefits to keeping spiking separate from execution or implementation. First, it keeps the work small so that the pair that develops the strategy, can move on to something else. Next, it makes the work move fast. If we were to go down the path of implementation and run into a blocker, then back up and try something different, then hit another blocker, it could extend the work by days. By taking the time to contemplate the things that could go wrong via a pre-mortem of sorts, we can save ourselves the time of actually making those mistakes. Finally, it's good for knowledge sharing and documentation. The pair that works the spike will create the documentation for the strategy. If a different pair executes on the strategy, they can make changes and updates to the documentation if there are steps that are unclear or that don't work as expected. This also ensures knowledge is spread across four members of the team instead of residing with just one or two. Also consider sharing your spike findings during a show and tell as another place/way to spread knowledge.

Tech Huddle

Photo by Francesco Ungaro / Unsplash

Duration: 5-20 min

Meeting that can take place right after standup or as a separate meeting to discuss technical topics and decisions.

When to use it & what's the benefit

If a discussion breaks out during standup and it's of a technical nature, taking it to tech huddle ensures that non-technical stakeholders don't have their time taken up by conversations that aren't relevant to them. This also keeps standup focused on reporting what was done, what will be worked on, and blockers.

Show & Tell

A meerkat whispers to another meerkat at the Memphis Zoo.
Photo by Joshua J. Cotten / Unsplash

Duration: 30 min or less

When to use it & what's the benefit

Show and tell is an informal place to share knowledge. Typically we will discuss 1-3 topics during the 30 minute session. There is no requirement to prepare a slide deck. It's not formal. That's a key feature of show and tell. This should be a forum to ask questions and explore tools and concepts. It's also a good place for people to test out talk topics or get more comfortable with their technical presentation skills. Topics can be technical or non-technical. It's up to the team how they want to define it. It can also be a place to do demos that are too long for standup or tech huddle. For example, if you just did a spike on a new testing framework and you want to do a 10-15 min demo of it for the team, show and tell would be the place to do that. One note, while it might be slotted for 30 minutes, if you just have one person sharing, then don't feel like you have to take up the full time. It's meant to be something at which people like attending and presenting so don't make it a slog.

What practices do you use to integrate learning during your work week? Do you have questions about these practices? As always, feel free to @ me on Twitter.