Tom and Jerry work in an agile development team building a web application. The team has 4 developers. In the planning meeting, Tom is assigned to a product backlog item (PBI). The PBI is simple. Anyone in the team can implement it.
Tom implemented the PBI the day after. It worked. A pull request (PR) was created and asked Jerry to review it. It is a normal process of the team.
Jerry left a comment in the PR:
Hi Tom, we already implemented the same thing at X feature. There is a common method that you can reuse.
A very constructive, useful feedback. Except the consequences:
- Tom has to throw away his implementation and reuse the existing one
- Waste of time from both sides: implementer and reviewer
Does it sound similar to you? – A common problem: Developers re-invent the wheel.
Why
The fact is that it is hard for a developer to know everything in the system. For many, that is impossible. Developers take PBI from the sprint backlog and work on them. How could they know what are already implemented? What could they reuse?
Discussions can help if you know what to discuss. Asking questions on the team can help if you know what to ask.
Reflecting on your team, how many times do your developers ask questions regarding to the implementation, to what to reuse. It is easier said than done.
Developers tend to write their own implementation. Because they think it will be faster and safer for them. So they just write code. And one cannot ask that question for every single PBI.
What Could We Do to Improve?
I am not a big fan of theory saying that developers should be proactive, ask questions. Yes. They should and they might will if that is the business logic. Or that is something unclear in the specification. Implementation? Not really.
Well-planned in the planning meeting can help. However, people have not talked much about technical design (or implementation hints) in the planning meeting.
Asking questions in the daily stand-up? I have not seen many questions asked in that regard. Most of the messages in the daily stand-up are status report. Just they are expressed in a different way.
So what could we do?
Give implementation hints in comments of PBIs
Each developer has different knowledge about the system. When an PBI is reviewed, some might have an idea of:
- What it is
- How to implement
- What could be reuse
- Reference points such as old PBI, Pull Request, or a specific commit
So instead of keeping them in your head, write comments in the PBI. When a developer starts implementing the PBI, he/she has a good starting point. From there, he/she can start discussions, asking questions. Because they know what to ask and who to talk to.
In a team, the most skilled, familiar with the code should look around the team backlog. Try to give as many hints as possible. Anyone can do it as well.
The approach has a compound effect. The teamwork is at the next level. Developers care about other PBIs, about the team. It also encourages conversions, engagement. When a developer leaves a comment, the conversion has started.
Take Away
Give implementation hints, folks, give implementation hints. Your teammates do not know what you know. The developers working on those PBIs will thank you. And in turn, they will do you a favor. That is where the conversation, the engagement begin.
