Agile and documentation are not two words that are often associated in articles or blog posts. Scrum teams have however to find alternate ways to spread the knowledge among their member. In this article, Viktor Cessan explains how he uses an exercise named History Lines to share knowledge in Agile teams.
Author: Viktor Cessan, https://www.viktorcessan.com/
To help teams share and document tribal knowledge I run/facilitate an exercise I call History lines. History Lines is a mix between an exercise called Journey lines and an exercise Johan Strömberg introduced to me. This is used as a part of a larger workshop for strategic visioning where history is a vital part of shaping your future vision
In this exercise teams are asked to visualize how different things have changed over time and at the end of the exercise you have helped spread knowledge to everyone in the team, the team has drawn new conclusions about their past, and they’ve documented some parts of their tribal knowledge.
I have found History lines useful when:
- Team composition changes e.g. when merging or splitting teams or when on-boarding several new members in a short period of time
- Team members have come to rely on specific people for context
- Bootstrapping new teams
Visualize what makes sense for your team
Depending on the type of team you are working in e.g. feature team, infrastructure team, component team, or management team, you want to visualize different things.
A feature team might find it valuable to plot how customer growth has evolved over time, along with info on competition, team size, epics/projects released, and technical challenges. On the other hand, a management team might find company goals, organizational and staff changes, and people and motivation metrics more valuable. And infrastructure teams will in addition to looking at company goals need to look at the amount of developers and development teams, possibly amount of applications in service, and how releases to production have evolved over time. It could also be valuable to mark out architectural paradigm shifts.
Laundry list of things to visualize.
- Company goals
- Team goals
- Competitive scene (who has entered the scene and who has left)
- Company or departmental events
- Amount of users or customers
- Total staff size
- Amount of developers
- Amount of development teams
- Amount of applications
- Technical challenges / Paradigm shifts
- Learnings
- Motivation (great place to work survey or equivalent)
- Organizational change
Use your imagination and look at your context when deciding what to visualize.
Here is how you can run this exercise
- Start by meeting the team (or representatives) before the exercise and decide:
- which metrics to visualize
- what level of detail that is appropriate for their timeline
- how long the exercise should be
- what to prepare before the exercise and what to create during the exercise. By the way, it is great if you have a product like Magic whiteboard that the team can prepare their timeline on. It saves time and allows the team to quickly get started during the exercise.
- who will be walking through the high level timeline during the exercise
- Introduce the exercise and let the team know that History lines is about spreading tribal knowledge. Also share that the team should first focus on the big picture and once the big picture is known they will go into detail on select areas.
- Once the team has gone through the whole timeline, have them dot vote on areas of interest and then discuss the areas with the most amount of votes.
- Timebox each area and decide how to discuss it first e.g. by looking at the code, design docs, on the site, or just talking about it.
- Once all areas have been discussed go around the table and share takeaways. Example questions you can ask are:
- What did you learn today?
- What are you takeaways?
- How did today increase your autonomy?
- Was there anything that was shared today that challenged previous beliefs and if so, what were they?
This exercise also scales e.g. if you want to do it on a department level as a context increasing activity or if you have multiple teams that are going to work together in a future initiative.
Visualize the big picture before you go into details
If your team and company have existed for more than a few years there is likely going to be a lot of information on your history line. To make sure you discuss the most important areas you need to visualize the big picture first. This means that you should not go into the specifics before you have visualized the whole timeline otherwise you risk spending your time on areas/decisions that happened many years ago and that are less important.
Also, once the timeline is up on the wall, decide and prioritize all the areas you want to talk about so you know how much time you have for each area and what level of depth you should go into i.e. just talk about the why, or look at design documents, or demo code.
Come prepared with a walking skeleton to the exercise
While some teams prefer to create their timeline together during the exercise other teams want their timeline to be ready before they enter the exercise. There is value in doing both but if you are going to create the timeline during the exercise as a team building exercise, I suggest that you at least have a walking skeleton prepared and have decided which metrics to visualize because it will leave your team more time for what is important: exploration.
Common pitfall when facilitating History lines
- Trying to both facilitate and participate. it is better to find a facilitator if you have tribal knowledge that is important to share.
- Talking about solutions (whether technical or not) instead of talking about challenges, problems, and background.
- Not preparing at least a high-level timeline with key events.
- Leaving out business goals and customer growth with infrastructure teams.
- Including too many or few variables in the history line.
- Not leaving time for the team to reflect on what they have learned.
- Beginning at the beginning. If your timeline is 10 years it is highly likely that there are more important events to discuss that the first things on the timeline. You will probably need to jump a little bit back and forth but only once you have decided what areas to focus on.
- Having a too long timeline. If your team has existed for 10 years, it is unlikely that events that happened that long ago are relevant. Consider making it shorter.
I hope History Lines brings you value and if you do decide to try it out, please contact me and let me know how it went.
About the Author
Viktor Cessan coaches systems (organizations and teams) and agile and has over 12 years of experience from agile product teams as Agile Coach, Product Owner, and Team Lead. Viktor mentors and trains managers, coaches, and product owners in all things agile, product management, leadership, and team dynamics. This article was originally published on https://www.viktorcessan.com/history-lines/ and is reproduced here with permission from Viktor Cessan.