As a developer, you and your team must take functional or non-functional requirements and create elegant solutions based on product benefits, team skills, general limitations, and impact. Teams are also required to make design decisions, some which are short term (tactical) and others that are more long term (strategic).
How a team makes these decisions varies from team to team, project to project, and styles of work. Documenting decisions in the form of solution design and creating an agile story to wait in the backlog for future implementation is a very strategic way of working.
However, issues begin to occur when a team loses sight of what the design decisions are, why decisions are being made, or how strategic solutions might resolve them. This can lead to repetition within the project in terms of completed activities and repetitive conversations among you and your team members.
This phenomenon is known as the agile goldfish. While many of the benefits of an agile way of working (flexibility, quick completion of requirements, and team strength in many areas) are great, they can also be the consequence of the agile goldfish.
In this blog, we will discuss what can cause this phenomenon and the steps that can be taken to turn your teams and projects into agile elephant enthusiast that are equipped with long-term contextual knowledge.
The agile goldfish
The agile goldfish happens for various reasons, including lack of documentation, high turnover, reliance on longer serving members of the team, and repeatedly deprioritized sprint activities. Let’s take a moment to dive a little deeper into those issues.
It’s common for agile teams to change often. Sometimes this is due to encouragement for members to complete work they are not familiar with to increase overall team knowledge. This can lead to a short team cycle within an organization. The high turnover of knowledgeable members is also exacerbated by outsourcing to contract teams both onsite and remote.
Each time a new member is added into the team, they must learn the decisions that were made before they arrived. Some of the decisions are obvious while others must be learned through either documentation or the passing along of information from one person to another.
The word of mouth approach is problematic in that the conversation can quickly become second, third, and fourth hand. New members to the team might not get the context during a handover but are expected to relay the decision later, when their source of information has left the team or organization. This can make it difficult for all team members, including new ones, to be on the same page.
Low documentation output
The Agile Manifesto details that code should be prioritized over documentation. Some teams might take this literally, while others do not feel they have the time to generate documentation in the wake of delivering content quickly.
To alleviate this, descriptive code practices suggest code should read like a story, often sidelining any comments at all. While the code might be readable, it is highly likely the code will not explain why it was written the way it was. In short, it has the what but not the why.
Documentation is important, but not enough. Keep in mind that someone new to the team might not fully understand the documentation without having the full product background, specifications, or standards being used.
The agile turtle
In nature, a turtle can live for up to 100 years, giving it the ability to pass knowledge on to their young. In the same way, an agile turtle is a long-serving member of an agile team who can provide context and experience to a situation.
Seasoned team members have a plethora of knowledge but might need time to familiarize themselves with a situation. The reliance on the agile turtle becomes a blocker in decision making and can lead to weeks of unproductivity, should they leave the team unexpectedly, or simply take a long holiday.
Lastly, raising an issue, imagining a solution, and then leaving those ideas under prioritization review can leave you and your team in a rut. Rather than a task being tackled sequentially and being flagged done or not done, tasks instead can be sent to the backlog where they can burrow deeper and deeper into the system.
That is not to say that the task is not important. It just might not be the most critical thing all the stakeholders are willing to bet on. While the task might have some comments included, it will unlikely be enough to avoid a secondary design and discussion phase before potentially ending back on the backlog before implementation.
So, what can be done to take your team from agile goldfish to agile elephant?
The agile elephant
Elephants, in contrast to goldfish, are known to have great memories with ancestral communication, passing information from one generation to the next. Below are some of the ways in which information can be passed along to reduce occurrences of the agile goldfish and instead create a team that emulates an agile elephant.
As a new member joins an agile team, they must first understand the project, the contextual information that is used by the project, and why each decision has been made. This can be easily done by providing the new team member with specifications, industry standards, or product information to read. It might also be hands-on practice to understand the systems they are using or even pre-recorded content that explains how and why the system works the way it does. The more content or materials that are provided to your new team members, the better their onboarding experience will be.
In the first few weeks that a new member joins the team, they might be required to work alongside another member of the team (ideally an agile turtle). Throughout, they should be encouraged to question decisions and why the system works the way it does. After a given time, the new member can take the active role in the pair and begin making assertions that can be validated and supported by the agile turtle. This leads to the team having a mutual understanding of the project and is a perfect setup for success.
By recording architectural decisions for reference in a document, it can make it easier for you and your team to have a visual understanding of design decisions. Try documenting a single architectural decision per slide or page for better clarity and understanding. This is a great way for team members to have something to refer to at a glance as a refresher.
Architectural decisions should also include:
- Accepted and rejected solutions
- Referenced alternative solutions
- A high-level overview
- Related decisions
This is useful for both existing and new members of the team as a reference guide but should not be used as a replacement for documentation.
It is important to use documentation, even in agile implementation. By creating good documentation that is up-to-date, any new member can understand what is in place, as well as why other alternatives have not been used. It is also important that the search functionality can accommodate a team who doesn’t know what they don’t know. “10 ways to achieve agile” has an in-depth section on the document process if you’d like more information on the topic.
To stop agile teams from routinely repeating the same conversations, decision process, and reaching the same result, it is important to move away from the agile goldfish way of working and move towards the agile elephant. By allowing information to transcend across different generations of teams, you and your peers ultimately create a better way of collaborating with one another.