Photo by Dylan Gillis on Unsplash
Introduction
One of the most valuable lessons that Agile gives us is that we constantly need to discover ways to become better by trying and doing things, instead of planning the best way to do them. I recently facilitated a Knowledge Sharing session in my team without planning it too much, and I’ll walk you through some interesting takeaways of that activity.
Breaking the habit
What does a normal day in your team look like? People working on stories, then talking in the daily meeting? Maybe some of them reviewing code, pairing or investigating a tough bug? What other activities do you have for learning purposes? If you feel like you and your colleagues are just “consuming backlog” or “doing the same every sprint”, maybe it is a good time to stop and think about what other things you might be missing. We need to pay attention to potential warning signs, like “oh, I don’t know how this thing works, so I don’t have an idea for this story’s estimate”. That could be the sign we need to do some learning as a group.
Sharing something you know to others is a long-term benefit for your team, and also for you, because we learn better by teaching others. It needs to be encouraged, discussed in retros, reinforced, and practiced either formally or informally (like in pairing sessions). Let me describe the example that motivated this article. We detected a topic that most of the team members didn't know: how to set up metrics and alerts for our apps using Appoptics (the APM tool we are using). I did have some experience with it, so in our daily meeting, I proposed a session to share what I know and to collect everything we know about metrics and alerts.
When adding a meeting to the week, we have to be careful about the “too many meetings don’t let me code” problem. So in this case it’s better to reduce the friction and respect everyone's focus time, for example, by chaining the meeting with another meeting: “What about tomorrow, after our IPM?” “It’ll be only 30 minutes”. Everyone was together, we just needed some extra 30 minutes for the session. As James Clear says in Atomic Habits, “make it easy” (3rd rule for building a habit).
Let's make it!
I didn’t have anything super planned and I made it explicit with the team. I proposed the topic literally the day before presenting it. No time for revisiting a speech, building slides, or preparing examples. Just to jump and see how it goes.
I had a high-level idea on the topics I wanted to cover, they were 5 in total. I didn’t know how much time each topic would take, and I didn’t know exactly what to show. I started from one line of code triggering a metric value that helped me connecting the dots and chaining all the remaining topics. As I was talking through those topics, I was also asking if there were questions so far, to ensure I was being clear.
I have to say, I was scared at the beginning, mostly due to the lack of preparation, but it went better than I expected. Are there better ways of presenting it? Sure. Are there better examples than the ones I used? Of course! The most important thing is that, as a team, we took the time we deserved to learn a topic that we’ll need in the short and long term future.
If the activity time is not enough, or if we need to do some additional understanding, or anything goes wrong during the meeting, we can have additional sessions. It’s not a one-time thing. We can even repeat the same session for new team members.
The term Knowledge Transfer is commonly used to refer to these types of activities, but I prefer calling it Sharing because it feels more equal. We are increasing our collective wisdom by doing this activity. It does not matter who is “transferring” to who.
Some tips you might consider about the meeting are:
- Share the examples you used. If possible, build simple examples that can better illustrate what you are sharing
- Start with some questions and check at the end if those were answered Record the meeting for future reference (more relevant in this fully remote, pandemic context, which also gives us more asynchronous ways of working)
- Share any additional information, link to documentation sites, and anything that can help to make more connections to the topic
- Ask for feedback (Management 3.0’s Happiness Door can be useful)
Conclusions
- Time for learning should be a recurring topic in every team, and it’s worth asking ourselves questions like “are we taking the time we deserve to learn?” “How can we own our learning” “how can we make it a team habit?” “How can we avoid knowledge silos”
- It’s not recommended to delay those activities with the intention of making them perfect, just try them and see how they work. Add more activities and adjust if needed.
- As a facilitator/person that knows the subject, it is ok to be afraid (for several reasons). But trust in the safety net your team can build around you, and ask for feedback every time you can.
- As an attendant, do not hesitate to ask questions, provide feedback and try something out based on what you learned!