Best Practices A Teams Impediment
Best Practices A Teams Impediment
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
The Journey Begins
My first co-located team in a long time. In fact, it has been so long I thought they didn't exist any longer. The journey begins with an ideal situation not only are they co-located but they are made up of 7+/-2 for the most part. To me this is manna from heaven. I had teams as large as 16 (different story), so this is a very nice to have.
This organization has been practicing scrum for over two years, but the teams I am coaching have little experience with it. My first week there I found the teams struggled with design and code review. I know you are asking what is up with that? Yes, both of these are best practices. Let me walk you through their impediment.
A Best Practice Turned Into A Team's Impediment
How could that be? It is quite simple you see. The architect must review all technical solutions to ensure consistency of code. A review of the solution in itself is not the problem The problem is requiring approval of this solution prior to the team moving on the work. This contradicts agile principles. Particularly, "the best architectures, requirements, and designs emerge from self-organizing teams". You see, while there is value in seeking consistency in code, approval will only serve to create bottlenecks and flawed code.
Making developers execute on a design created by an architect that is out of touch with the impact of the design of the project will misalign the needs of the business with technology and put the project at risk. Let me be clear here, I have no issues with architects. However, if your architect does not code it will put the team at odds with the architect. One way of solving this is embedding the architect as a team lead. This would be a supporting role, to help teams think through solutions. But, I will be trying something else.
Coding Standards for consistency of code!
Another solution is to have the architect develop coding standards with the team. I am hoping to coach the architect and get him to understand the value of the developer's perspective. I want developers to understand the architects perspective and hope they will gain respect for one another. I am also pushing away from the need to approve technical solutions. I am crossing my fingers!
The second impediment: Code Reviews
Code reviews are another great practice, but not when it is misused. The scenario here is the reviews are the equivalent of a sign off. If the reviewer rejects the code, code is not merged. Now, I am not saying that bad code should be moved in. What I am saying is there needs to be a good reason not to allow code to move in. Simply rejecting code on the basis of lack of comments, or not agreeing to a developers way of coding versus the way you may have done it, does not explain rejecting code. Code reviews are an excellent practice and helps to increase code quality. In scrum, not having comments would require the developer, to quickly add them if possible or make that a technical user story for the next sprint.
Working with the teams and the architect on creating coding standards will provide an opportunity to define set rules to when the code will be rejected. This clarity upfront should help the team understand what they need to do to get their code merged.
So, what is your experience with best practices? Do your teams practice code review?
“It is not a bolt to be tightened into place, but a seed to be planted and to bear more seed toward the hope of greening the landscape of idea.”
Opinions expressed by DZone contributors are their own.