Professional Scrum Development with Microsoft Visual Studio 2012: Effective Collaboration

  • 10/15/2012
Contents

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.

NOTE

A self-organizing Scrum Development Team should pick and choose from these as well as other development practices and try them for a Sprint or two. Later, during a Sprint Retrospective, the team can decide whether to continue to embrace the practice, to amplify it, or to abandon it.

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

Figure 8-1 Viewing a history of changes to a specific file in Team Foundation Server.

Figure 8-2

Figure 8-2 Comparing two versions of a file to see the differences.

Figure 8-3

Figure 8-3 Using Annotate to see which developer made which changes in a specific file.

Tailspin Toys case study

Because each member of the Scrum Team is a team project administrator, everyone has full control over every aspect of the team project. This includes the ability to view, edit, and even delete files from source control. Should the need arise to see who made a change, the developers are all trained in TFS and can view history, compare, and annotate as needed. Sometimes they will use the Annotate feature to praise another developer for good work.

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.

TIP

Comments shouldn’t tell the reader how the code works. The code should tell them that. If the code isn’t clear, then you should refactor the code rather than add descriptive comments.

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.

TIP

Fellow Professional Scrum Developer Jose Luis Soria Teruel suggests that commenting in perfectly readable code can sometimes be useful too. For example, in Microsoft Visual C#, you can create documentation for your code by including XML tags in special comment fields in the source code directly before the code block they refer to. If you are developing an application programming interface (API) for third parties, you may want to at least use the summary tag to describe a type or a type member.

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.

Smell

It’s a smell when I see a file with the author’s name at the top. I understand a developer wanting to get credit for his or her work, but this kind of comment tells everyone else to go away. It could be that the code file is really old and hasn’t been touched since the team started practicing collective code ownership. If that’s the case, someone should remove it. TFS tracks this through changesets, so it is redundant anyway. It could also be an organizational requirement to have predefined headers and require authors to add their names. If that’s the case, meet with the decision makers and ensure that the value delivered by the practice outweighs the waste that it seems to generate.

Tailspin Toys case study

The Development Team uses popular frameworks, principles, and practices as they design and code. As a result, there’s not a lot of opportunity for meaningful comments. Only when they are coding some complex LOB methods do they add comments. The Development Team also knows that when checking in to TFS, they will associate a Task work item (which links back to a PBI or Bug work item) and a meaningful comment. Together, these two items provide more than enough context to explain later why the changes were made. Additional comments in code are not required.

Code reviews

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.

TIP

Code reviews can also catch and enforce coding style and standard issues. Be careful spending too much time with these kinds of topics during a code review, as they can become a rathole. A rathole is any discussion that detours the original purpose of the conversation. Don’t get me wrong—discussions around coding styles and standards are very important, but any debate or decisions around changing existing standards, or establishing new ones, should be deferred until the Sprint Retrospective meeting. High-performance Scrum Development Teams know that matters of style are not absolute. Developers should be allowed to self-organize and use whatever style is fit for purpose. Once a Development Team has been working together for a while, their coding standards will begin to emerge. These standards may even become part of the Definition of “Done.”

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.

TIP

Typically, most developers know the code that needs to be reviewed. This can change, depending on the frequency of the code reviews. Developers can forget the changes that they made and the context if too much time elapses. Fortunately, TFS knows what files a developer has worked on for any given date range. From inside Source Control Explorer, the developer can right-click a parent-level folder and view the history. Unfortunately, this will show activity from every developer. There’s no way to filter out other developers’ changes. If you drop the command line, however, this filtering can be accomplished using the Tf.exe command-line utility.

Here’s an example where Dave is asking TFS to list all of his changesets for a given date range:

tf.exe history $/Tailspin/Code/Dev /version:D"07/04/2012"~D"07/17/2012" /user:"Dave
(Developer)" /recursive

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.

Pair programming

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

Figure 8-4 Possible outcomes when pairing developers together.

Tailspin Toys case study

The organization has no policies around code reviews. They leave it up to the Development Team to decide. Sometimes the developers perform ad hoc code reviews. These are done whenever a developer hits the wall or needs a better solution for a complex problem. These kinds of code reviews are almost like an impromptu pair programming session. In addition, the entire Development Team likes to sit down in the conference room and use a projector. Each developer in turn shows off code. With a full room, this approach encourages discussion on design and style. As the team has improved, each review begins by showing the automated tests.

Save to your account

This chapter is from the book