Whenever I speak to teams, there is always a sense of reliance on a handful of people in handling legacy code and understanding the system. One of the inside secrets within the software community is “It’s easy to develop code, hard to maintain and even harder to let legacy code thrive”.
With agile development, documentation has come to on need basis. Aftershocks that we are seeing from such patterns are
- Unpredictable time to complete a feature
- Long tail around regression testing
- Lesser accountability towards tech craftsmanship
While most of the time is spent on getting the functionality to work as expected, it’s understandable from the team’s perspective to not invest the required time to create the safety net. As there would also be the next priority that’s burning and needs immediate attention.
For this vicious cycle to stop there needs to be a commitment from teams to increase their knowledge in the products that they are supporting. This blog is illustration of some of the experiments that have been successful.
Architectural Guild
One of the keys to unlock the gridlock of knowledge within teams is to improve collaboration. Some of the experiments that have been highly successful are creation of architectural guild within the technical leaders and team members to accept the challenges that they are encountering.
As design thinking philosophy says, it’s important to have shared understanding of the problem prior to creating solutions. Solutions can come from anyone and the collaboration will aid in accelerating faster decision making. Importance of problems and a backlog of areas that team wants to focus could be a backlog.
Code reviews beyond scrum teams
Another experiment the team ran is to actively seek code review comments beyond the scrum team boundaries. In the beginning, the code reviews took longer than expected. And the team that made the changes needed to rollover stories when the code reviews couldn’t be complete within the sprint.
Eventually, they inspected how the code reviews were conducted and found some practices that helped them. Laying them here for others who could benefit
- Stories that changed common or framework type elements, had separate stories to accept and incorporate feedback
- Value of the code review was more widely communicated within the engineering community
- Created a short retrospective among reviewers on a regular basis to understand improvement areas
After 4 cycles of running this experiment, it no longer remained an experiment but a way of life. This helped not only increase the code quality to improve, but collaboration within teams to foster.
Reducing number of products supported
One of the teams that I coached, I observed that they had five developers and each developer had expertise in five different legacy products. During the sprint refinement, stories from the product specialty would be pulled in by the expert.
It made sense, as most of these stories had a timeline tagged along and the team had decided to stay in their own track. For a sprint, the team decided to pull lesser number of stories, and more time on upgrading their knowledge. However, it was much slower than expected and team continued to go back to old ways to staying on track.
While this retrospective item was discussed, decision was taken to reduce the number of products maintained by a scrum team. This dramatically, changed the team’s view of staying in the same track. Each lane got wider and the number of tracks reduced. This helped the teams to create a joint vision and took an opportunity to deepen the expertise in these legacy products.
Culture eats strategy for breakfast
The best laid out strategy would be bound for failure, if the teams are not imbibing the why’s of agile. The next experiment built on the previous experiment and made all the teams take responsibility of lesser number of products with wider responsibilities. Each team(s) was responsible for development, maintenance and decommission of their product area.
Image Courtesy: Harvard Business Review
The way the leadership started looking at is, rather than breaking silos how do we unite teams under the same goal. While each team had its own development plan in terms of having a backlog, all the teams had a common theme.
With a common theme percolated and common success factors generated, the teams found more reasons to collaborate rather than compete on limited resource of knowledge.
These are some of the experiments and learnings that I have carried from my coaching experience. Would love to hear from you on what you are doing do unite the knowledge expertise.
A note to myself 🙂 and all of you, each context is unique and coaching by its nature needs to adapt to the situation and would love to hear from other coaches on experiments that have been conducted and how teams have moved towards high performance.
