- Individuals and interactions over processes and tools
- Collaborative development practices
- Collaborative development tools
- Chapter burndown
Collaborative development practices
Even the simplest software product requires a team with many talents. Beyond having the standard capabilities of design, code, and test, there can be many types and levels of talent within each discipline. Every developer has a unique background, set of skills, expertise, and personality. Each brings something different to the team. For example, you may have two C# programmers with similar resumes and experience. The way in which they analyze and solve problems will vary radically. Both approaches can be fit for purpose according to the requirements, but they can be very different.
A high-performance Scrum Development Team understands this reality, and even uses it. These types of teams recognize everyone has a different way of solving problems, and so long as those solutions fit within the parameters of the product and the Development Team’s practices, they should be embraced. Long, drawn-out discussions and arguments over approaches and coding styles tend to generate little value, and typically only lower Velocity and morale.
In this section, we will explore several contemporary practices that boost the Development Team’s effectiveness during collaboration.
Collective code ownership
Extreme Programming (XP) gave us the notion of collective code ownership. With this approach to ownership, individual developers do not own modules, files, classes, or methods. All of those things are owned collectively, by the entire Development Team. Any developer can make changes anywhere in the code base.
Consider the alternative to collective code ownership, where each developer owns an assembly, a namespace, or a class. On the surface, that may seem like a good idea. The developer is the expert on this component, as well as the gatekeeper for all changes. Strong code ownership like this has a tendency to block productivity. Consider the situation where two developers (Art and Dave) are working on separate tasks that both need to touch a common component owned by a third developer (Toni). Dave will have to wait while Art’s functionality is coded and tested. A collective code ownership model would allow Dave to code the feature himself. The source control tools in TFS would track who made what changes to which files and enable a merge (or a rollback) to occur if there were any problems. Another potential problem with strong code ownership pops up when refactoring. Modern refactoring tools, like those in Visual Studio, can do this safely, but if the file or files are locked, then productivity is blocked again.
Adopting a collective code ownership mentality can take time. This is especially true if the Development Team used to have strong code ownership. Pairing and shared learning is a way to break up the turf and politics. Just as it takes time for the Product Owner and organization to trust the Development Team’s ability to self-organize and self-manage, it also takes time for the individual developers to trust each other.
Tracking ownership in TFS
The biggest advantage with collective code ownership is the boost in the social dynamics of the Development Team. Because each developer has full control over all source code, there are less boundaries and more opportunities to find solutions. Remember that in Scrum, the Development Team owns all the problems and all the solutions collectively. This includes the artifacts of those solutions, namely the source code.
Should you ever have a need to determine who made a specific change to a file, TFS can help you. By right-clicking a file or a folder and selecting View History (as shown in Figure 8-1), you can see a history of changes, including who made them, the type of change, the date and time, and a (hopefully meaningful) comment. If you want to see what was changed between two versions, you can select them both and right-click, choosing Compare as shown in Figure 8-2. The UI will show removed text in red and new text in green. If you want to see who wrote which line of code in a specific version of a file, you can use the Annotate tool as shown in Figure 8-3.
Figure 8-1 Viewing a history of changes to a specific file in Team Foundation Server.
Figure 8-2 Comparing two versions of a file to see the differences.
Figure 8-3 Using Annotate to see which developer made which changes in a specific file.
Commenting in code
With collective code ownership comes a certain amount of responsibility. Other developers on the team will need to understand the code. If a developer or pair of developers is working on a rather complex part of the code, they should consider adding some comments. This can be a block of comments that give another developer enough information to understand this code. The comments can also be regularly sprinkled throughout longer algorithms. You can think of comments as being messages to the future, and it might be you reading those comments a year from now.
When commenting in code, only comment about what the code can’t say for itself. If the code is well formed and follows popular patterns and principles, it probably doesn’t need comments. When someone looks at the source code, its logic and purpose should be apparent. Keep this in mind while you are coding. Constantly ask yourself how clearly your code is telling you, or another developer, what it is doing.
Remember that comments live inside your source code files, and as such, they become inventory just like the code itself. Comments can even be a form of technical debt if they are wrong or misleading. Be diligent about updating your comments or removing them as you refactor and improve your code. Adding more comments isn’t necessarily a good thing unless they add value. Perhaps it’s time to refactor the code into simpler units rather than adding more comments. You should prefer unit tests over comments. The best comment is a set of working unit tests with high coverage.
A code review is a simple way to assure code quality by having another developer look at the code. This assurance can cover multiple levels of quality. It can assure that the code works, is fit for purpose, is absent of bugs, is absent of avoidable technical debt, is readable, and meet’s the team’s agreed-upon coding standards, as well as the Definition of “Done.” Additionally, the developer whose code is being reviewed can use the conversation as an opportunity to learn about the way that he or she writes code.
Professional Scrum developers recognize that the candid feedback (otherwise known as criticism) given during a code review is targeted at the code and not themselves. For new developers, or developers new to code reviews, there can be a tendency to take these criticisms as an insult, even becoming defensive. Over time, these developers will see that even experienced developers make mistakes. Everyone is human. Everyone screws up now and then. Everyone can improve. Code reviews are just another type of shared learning activity, where any developer can learn from another.
When reviewing someone else’s code, you should avoid appearing as a “senior” developer. The truth is that you may be the senior developer, but because everyone is equal within a Scrum Development Team, it’s all about the sharing and learning. Choose your tone and your words carefully as you identify problems and improvements in someone else’s code. Developers new to Scrum may be put on the defensive. Don’t aggravate the situation by also going on the offensive.
Code reviews don’t have to be a formal process. They can happen spontaneously. They also shouldn’t be despised or avoided. High-performance Scrum Development Teams actually look forward to code reviews. This is because those teams know that the code is owned collectively. Problems and criticisms aren’t directed at a single developer; rather, they are learning opportunities for the entire team. Every code writer and code reviewer will have different perspectives and approaches to solving problems.
Professional Scrum developers should build solutions that are fit for purpose while avoiding gold plating. Gold plating is any design or coding that is above and beyond what is absolutely necessary for the task at hand. For example, if a PBI requires a method that calculates the sales tax for the state of Washington, and the developer adds additional logic to handle the nearby states, that’s gold plating. The developer may try to justify the extra coding as being required down the road for a future Sprint. In order to maximize value and minimize waste, Development Teams should solve today’s problem today and tomorrow’s problem tomorrow (in the next Sprint, as it is in Scrum). Code reviews can be a good way to unearth gold plating.
You can think of pair programming as a form of code review—one that happens in real time. The practice of pair programming has two developers sit together at one computer. One developer types at the keyboard (drives), while the other observes, navigates, spellchecks, and otherwise reviews the code being typed. The two developers will switch roles frequently.
A benefit of this two-person approach is that the driver can focus on the tactical (coding) activities, while the observer is thinking about the broader, strategic solution to the problem. This collaboration leads to better and simpler designs and fewer bugs, in shorter periods of time. Pairs of developers working in close proximity like this are also less prone to get sidetracked from the task at hand.
During pair programming, knowledge is passed back and forth. The two developers can learn new practices and techniques from each other. Pairing a newly hired developer, or a developer with a different or weaker skill set, with a developer who is stronger will help improve the overall effectiveness and Velocity of the Development Team. Some teams scale this idea using an approach called “promiscuous pairing.” Each developer cycles through all the other developers on the team, rather than pairing with only one partner. This behavior causes knowledge of the software product and its inner workings to spread throughout the whole Development Team. This reduces risk if a key developer leaves the team. Figure 8-4 demonstrates the possible outcomes of pairing weaker and strong developers together.
Figure 8-4 Possible outcomes when pairing developers together.