Chapter 8

Effective Collaboration

There’s a buzz—a kind of energy—that you can feel when a high-performance Professional Scrum Team works in harmony to solve a problem. Each Developer gets totally absorbed in their task. They each do their part integrating the design, the coding, and the testing. Slices of working product are assembled and verified. Definitions of Done are met. PBIs are moved to the Done column. Everyone loses track of time. Everyone feels happy and satisfied. They are experiencing flow.

Bruce Tuckman wrote about the stages of group development. He identified four stages in the development model: forming, storming, norming, and performing. In the initial, forming stage, the individuals come together to form the team. They may not know one another. They may not know everyone’s strengths and weaknesses. This leads to the storming stage, where each team member competes for their idea’s consideration while working together to resolve their differences. This stage can sometimes be completed quickly. Unfortunately, some teams never leave this stage. Once the team members are able to resolve their differences and participate with one another more comfortably, they enter the norming stage. Here, the entity of the team begins to emerge. The members can converge on a single goal and come up with a mutual plan. Compromise and consensus decision making occur at this stage. Professional Scrum Teams strive to reach the fourth and final stage, known as performing. Not only do these teams function as a unit, but they also find ways to get the job done smoothly and efficiently. They are able to self-manage effectively. In my opinion, very few teams reach this stage, but every one that does has mastered the art of collaboration, can enter and exit conflict gracefully, and can constructively build a better product.

I propose a fifth stage to Tuckman’s stages of group development: swarming. As you will learn later in this chapter, swarming is a collaborative practice where all Developers work simultaneously on the same PBI. They continue to work on all the related tasks or tests until the PBI is done. Swarming is a proven practice while working in a complex space, such as software development. Positive results can be demonstrated almost immediately.

In this chapter, I will highlight some practices and tools that enable more effective team collaboration. By learning and adopting these practices, a team will increase its ability to reach the performing stage of Bruce Tuckman’s model, and hopefully the swarming stage after that.

Individuals and Interactions

The Agile Manifesto clearly states that though there is value in process and tools, there is more value in interacting with individuals. In other words, agile software development recognizes the importance of people and the value that they bring when working together. After all, it’s people who build product, not the process and not the tools. If you put bright, empowered, motivated people in a room with no process and inadequate tools, they will still be able to get something accomplished. Their productivity may not be what it could, but they will produce value. They will know to inspect and adapt their processes, always looking for improvement. The group of people becomes a team working toward a shared goal. Conversely, if the people don’t work well together, no process or tool will fix that. A bad process can screw up a good tool, but bad people can screw up everything.

Software development is a team sport. To succeed in this sport, game after game, the team must share the vision, divide the work, execute, inspect, and adapt as a team. In other words, they must collaborate and learn. Even a team of rock stars (also known as “10x developers”) is doomed to fail if they don’t collaborate with one another. If the striker on a soccer team has their best game ever—scoring four goals—but the opposing team scores five, it’s still a loss. The other team, with more “mediocre” players, probably collaborated better.

Note A 10x developer is an individual who is thought to be as productive as 10 other developers. In theory, the 10x developer would produce 10 times the outcome of any normal developer. Some claim that the 10x developer concept is a myth. Although there are certainly practitioners out there who are more productive than others, 10 times seems to be a stretch to me. One thing is certain: team members of this echelon are very rare and it would not be prudent to try to assemble a team of them. Instead, do what you can to foster and develop the team you have into a Professional Scrum Team—striving for a 10x team!

A few years ago, Ken Schwaber did a series of podcasts where he answered frequently asked questions about Scrum. My favorite question that he answered was, “Do I need very good developers for Scrum?” His answer was insightful: “You need very good developers for software development.” You can do Scrum with terrible software developers, and you’ll get terrible increments of functionality every Sprint.

When I hear about teams that have tried Scrum and given up because it was “too difficult,” I know that they are not talking about the complexity of Scrum itself. These are software developers. They are some of the smartest, most creative problem solvers you’ll ever meet. Besides, Scrum is easy to understand. Chapter 1 pretty much covered it, soup to nuts. No, what these people are talking about is the discipline of practicing Scrum correctly by using the Scrum Values within an organization that allows them to do so, the right way, every day. Not being able to do that is why they gave up.

I agree with the Agile Manifesto. This has been evident throughout this book as I’ve pointed out the value of interacting and collaborating with individuals. I have discussed process and tools as well, but I’ve been vigilant in pointing out that not all application lifecycle management (ALM) tools and DevOps automation frameworks are healthy for a team. Most are. Some, however, can lead to one or more dysfunctional behaviors. For example, social media, tablets, video games, and other devices are appealing and fun, but sometimes the kids (or Developers in this case) need to get outside and interact with others.

Years ago, I was asked to build a web-based work item approval system on top of Team Foundation Server. The client designed it so that email alerts would be sent when a work item changed to a certain state. This was before Microsoft added that functionality to the core product. These emails contained embedded hyperlinks that would redirect the user to a webpage that allowed managers or leads to authorize the state change. It was a sophisticated system—it even knew which users could cover for others if someone was out of the office. My company built it. The client installed it. It did exactly what they wanted, but they ended up not using it. The reason they mothballed it was that it was too mechanical and removed the opportunity for individuals to meet face to face and have a conversation. This was a learning opportunity for me and something I keep in mind whenever I see a shiny new feature in Azure DevOps or Visual Studio. I ask myself, “Does this feature encourage collaboration or discourage it?”

When it comes time to meet and collaborate with members of your Scrum Team or stakeholders, here are some tips to consider:

• ■   Establish the scope and the goal of the meeting, stay focused on those topics, and achieve the desired outcomes.

• ■   Meet face to face, especially if you anticipate a substantive conversation.

• ■   Meet at a whiteboard, especially if you’re intent on solving a problem.

• ■   Set a timebox and be prepared to explain its purpose.

• ■   Leave the gadgets in the other room, unless they are required.

• ■   Employ active listening techniques.

• ■   Have a clear facilitator.

In this section, I discuss some of the general—but important—collaboration practices that a Scrum Team can adopt.

Collocate

As I write this, teams everywhere are sequestered away, working in home offices, home basements, and home bedrooms—all thanks to the coronavirus (COVID-19) pandemic. Social distancing policies are keeping us purposely “dis-located.” Organizations have switched to remote work models. Are these changes temporary or permanent? Time will tell.

It’s important, during times of crisis like this, to lean into the Scrum Values. When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and help build trust for everyone—regardless of where they are working.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and, to some degree, the challenges of performing the work. Scrum Team members expect one another to be capable, independent people.

We can all agree that communication and collaboration provide more value when practiced face to face, rather than remotely. At least I would hope that everyone knows this, because we experience it every day of our lives. When two people communicate face to face, they exchange more than just words. There are facial expressions, body language, and other nonverbal gestures. This kind of sideband data can be just as important, if not more important, than the audible conversation that occurs. For example, the look on a Product Owner’s face when you suggest a solution to a problem can short-circuit the need for a detailed explanation. Thank you, collocated Product Owner. You just gave me back 20 minutes of my day!

Remember that Scrum has several formal events (meetings) built into the framework where collaboration can occur. In addition, members of the Scrum Team should be continuously “meeting.” These are not traditional meetings, where someone speaks and everyone else listens. These are short, collaborative, timeboxed meetings with the specific purpose of solving a problem. In fact, I wouldn’t even call them a meeting, but more of a conversation with a clear outcome. It’s important that they occur as needed, with no logistical impediments. For example, if two Developers need to discuss something with the Product Owner but all the conference rooms are booked, they should meet anyway, somewhere, anywhere. To some degree, business formalities, and even etiquette, go out the window during the Sprint when the Developers are in the zone, developing business value.

I may be old school here, still clinging to pre-COVID-19 thinking, but I believe collocation should be a requirement when forming a Professional Scrum Team. It shouldn’t just be a nice-to-have feature. It shouldn’t be discounted because we can “make remote work.” When working in the complex space—as with software development—collocation directly influences complexity, which directly influences the quality of the process, which in turn directly influences the quality of the product.

Just to be clear, when I talk about collocation, I don’t mean just being in the same time zone, city, or building. I’m not talking about having always-on cameras and large-screen displays on wheels. Although these options are better than some I’ve seen, I still prefer to see teams in the same physical room or in adjacent physical rooms. The Product Owner should be nearby, too. This way, high-fidelity, face-to-face communication can occur on demand.

Tip When collocation is not possible, bringing a dislocated team together periodically is a proven practice. This builds the sense of team and supercharges them. It reconnects and reenergizes the relationships and commitments. This is especially true at the beginning of a new development initiative, so they know who they are working with. Even better is to bring the team together, each Sprint, for the sake of Sprint Planning. Some of my colleagues have worked with large-scale development efforts where those organizations bring their overseas teams together once a month for the sake of a scaled Sprint Planning event. In their opinion (and mine), a focused, in-person Sprint Planning can help avoid the waste of 7–8 teams building the wrong thing over the next month. In other words, spending $100,000 on travel is cheap compared to wasting $1 million on building the wrong product.

Professional Scrum Teams know the value of collocation, and they strive for it. That said, there may be cultural, political, or financial reasons for not being able to collocate. This is the reality that I see as I visit larger organizations. The most common justification I’m given when I ask why the team is not collocated is that it “saves money” to have one or more of the functions supported or outsourced remotely, usually overseas. When I hear that, I hope that somebody, somewhere is doing the math, and considering the waste of coordination, handoffs, and rework, not to mention the potential for a decrease in quality of the product. Even if this decrease is not detectable or measurable, the decision makers should consider what the increase in quality could be if they were to bring the entire team together.

Note Do I think that Developers working remotely as part of a “dis-located” team can’t be professional? Of course not. They absolutely can be professional and the team absolutely can collaborate, deliver high-quality software, and create business value. For some tips and tricks, I recommend downloading fellow Professional Scrum Trainer Stefan Wolpers’s Remote Agile Guide from https://age-of-product.com/remote-agile-guide. Stefan starts with some basic techniques and tools for practicing remote Scrum with distributed teams and also how to apply Liberating Structures in the remote realm. For more information on Liberating Structures, visit www.liberatingstructures.com. An attribute of a Professional Scrum Developer is to inspect and adapt constantly, such as looking for ways to improve their process. Collocating a “dis-located” team is one of the biggest improvements that can be made, usually resulting in a marked increase of productivity and quality.

As you’ve probably heard, every company is now a software company and these companies consider their custom software to be a strategic advantage over their competitors. I will sometimes ask executives where they would be without their line-of-business (LOB) application or public-facing website. They all agree that it would be a complete disaster. Not only has their staff forgotten how to run the business manually using paper and pencil, but they don’t even know where to find the paper and pencils. Next, I ask them why they try to save money by limiting their capabilities and productivity of the team developing that custom software. At this point, I’m either asked to tell them more or I’m escorted out of the building.

Note I once had a conversation with an IT director of a very large organization. He explained to me that the Product Owner worked out of the main office, as did the coders. The testers were overseas—nearly 10 time zones away. He shared with me a problem that they’d been having for the past few months. He said the coders would code a feature and then go home for the night. The testers would come in, download the binaries, begin testing, and run into a bug. This blocked them from doing any further testing until the coders could fix it. The coders would come in the next day, see the lack of progress, fix the bug, and have to wait until the end of the day for the testers to do their thing. Sometimes this dance would take 3–4 days before the work was finished. He asked me how Team Foundation Server could help him. I answered by asking why the testers weren’t collocated with the rest of the team. He told me it was because they save money by sending the testing work offshore. I’m glad we were having this conversation in person because he was able to see the awesome facial expression I made at that point.

Set Up a Team Room

Having all Developers work in a shared, common room can be a powerful practice. Whiteboards containing plans and design notes are visible to everyone. The Sprint Backlog and a burndown chart can be updated easily and seen by everyone—whether on physical boards or flat screens. During critical design points or bug fixes, this room can become an incident room of sorts as the Developers engage in tactical planning and operations. Communication becomes more open and happens in real time. Developers tend to focus their productivity on solving problems, while minimizing time spent on wasteful activities. Team rooms allow everyone, including stakeholders, to feel that buzz that I mentioned in the beginning of the chapter.

However, not every Developer wants to work in an incident room every hour of every day. There needs to be the opportunity to have private conversations, take phone calls, or just take a timeout from the rest of the team. Developers are smart and can self-manage to come up with solutions for these situations. I’ve seen Developers put on headphones; adjourn themselves to private, quiet rooms; or work away from the office for a short time as needed. Ideally, the managers and the organization trust their people to the point where they can accommodate their needs. If they don’t, then that is a smell and possibly a big impediment to self-management. Continually generating business value in the form of working product is a way for the Scrum Team to earn (or re-earn) that trust.

Some personalities and cultures see collocation as an impediment. These Developers may actually be counterproductive in such an environment. Remember that Scrum is about people, and people are human. Their idiosyncrasies map directly to their ability to collaborate and work effectively as a team. The rate at which a team is able to create business value is a function of the team’s productivity. Perhaps for these people, being in close proximity to, but not in the same shared room with, the rest of the Developers is good enough. Could it be better? A creative Scrum Master, fostering open and honest Sprint Retrospectives and improvement experiments, might get the Developers to change their minds. Remember that culture is hard to change.

My recommendation is to set up an open-space team room and just try it out. See if management will let the Scrum Team take over one of the conference rooms for a Sprint or two. If, during the Sprint Retrospective, the Scrum Team honestly believes that they were more productive, then the Scrum Master can work with management to create a more permanent, open-space team room.

Note An open-space team room is not the same thing as an open-plan office. Open-plan offices are typically inhabited by employees working on different tasks for different projects. Open-space team rooms are inhabited by Scrum Team members working on a common product. Both environments can generate noise, but the type of conversations found in an open-plan office will be more contrasting and, thus, more distracting.

Fabrikam Fiber Case Study

The Scrum Team has been collocated since day one, with Paula in a nearby office. When they are working, they regularly meet and collaborate whenever and wherever it is required. Day to day, the Developers sit near one another in a large, open-space room with a half-dozen whiteboards. Because the Developers use laptops, there’s a minimum amount of gear and clutter in the room, and individuals can be more nomadic as they pair up and work.

When one of the Developers needs to focus or requires some personal space, they will put on headphones or go to a quieter room down the hall. When a Developer has to travel or otherwise work remotely, the team will set up a dedicated computer with a Microsoft Teams connection, including video. Microsoft Teams is used anyway to share code and screens between Developers. Scott (the Scrum Master) continues to do a good job in educating the organization. Although the stakeholders know where the team room is located, they know to avoid it when the Developers are working—unless, of course, they’re invited in. Scott still has to remind people of this from time to time.

Meet Effectively

Professional Scrum Developers know to only attend the essential meetings. To be clear, I’m not talking about the built-in Scrum events, such as Sprint Planning, the Daily Scrum, Sprint Review, or Sprint Retrospective. I’m also not referring to the regular Product Backlog refinement sessions, or those impromptu but important meetings requested by the Scrum Team in order to clarify or get feedback from a stakeholder. Gee, come to think of it, Scrum has built in to it, all of the meetings that Developers would need. I hope, in fact, that I’ve made it clear that these “meetings” are important and that they should be attended by all the involved parties, face to face.

No, I am talking about all the other meetings that an organization might require its staff to attend. You know the ones I mean. They are mandatory and read-only (they don’t ask for your feedback), and they provide zero business value to the product being developed or the team’s process. Unfortunately, some of these meetings cannot be avoided. They are a fact of organizational life and a requirement to keep your job and get paid.

When you are invited to such a meeting, try to identify its purpose and expected outcome. This may be stated in the invitation, but if not, you may have to ask the organizer. I know some individuals will not accept a meeting invitation if no clear agenda or objective is given. From this information, hopefully you can determine who the intended audience should be. Will the meeting be technical? Will decisions be made? If you don’t fit the audience profile, try to skip the meeting, or send the Scrum Master instead. Being a proxy for the rest of the team at meetings like these is one of the duties of a Scrum Master and a great way to protect the team’s focus.

If the tables are ever turned, and you find yourself organizing a meeting, you can follow the same advice:

• ■   Only schedule meetings that are absolutely necessary and that can’t be satisfied by one of Scrum’s built-in events.

• ■   Outline the agenda and expected outcome in an invitation.

• ■   Keep the meeting as short as possible.

• ■   Establish a timebox to enforce it.

• ■   Send invitations only to those people who need to attend.

• ■   Discourage forwarding the invite to other people.

• ■   At the beginning of the meeting, explain the timebox and possibly its concept.

• ■   Have a clear parking lot and a working agreement for handling off-topic/distracting tangents.

When someone who is versed in Professional Scrum sets up and runs a meeting, they will end up sharing good behaviors and practices, such as transparency, active listening, and timeboxing. This is a fantastic way to get others in the organization more educated on Scrum, the Scrum Values, and some complementary practices. If appropriate, email any retrospective notes to the attendees, including action items. These behaviors may begin to infect the organization as other business units and teams will want to get some of that “Scrum goodness.”

Tip One way to keep meetings constructive is to say “yes, and…” instead of “yes, but... ” If the current topic or solution being discussed is one in which there is partial agreement, saying “yes, and…” comes across as being constructive, open, and respectful. If someone hears “yes, but…” then they might think their idea is being discounted, or they may feel limited in what can be accomplished. If, however, they hear “yes, and…” they will think that their idea was accepted, or at least understood, and they will be more open to ideas. More importantly, the person will be more open to collaborating on a shared solution, which should always be the goal to prevent discussions from becoming polarized and deadlocked.

Fabrikam Fiber Case Study

Paula and Scott are good at running interference for the Developers. For meetings that are not related to the development of the product, Scott or Paula will attend. For those annoying “all hands” meetings that cannot be avoided, Scott will do his best to be a proxy, letting the other team members know what has transpired.

Listen Actively

In my experience, software developers tend to have short attention spans and be impatient with anyone who is not as smart as they are or who doesn’t have the answer that they are looking for. Of course, I could just be talking about myself. But as they say, acknowledging that you have a problem is the first step in overcoming it. For me, active listening was that cure.

Active listening is a communication technique where the listener is required to give feedback on what they heard to the speaker. This can be as simple as nodding, writing a note on a piece of paper, or restating or paraphrasing what was said. This demonstrates curiosity, sincerity, and respect for what the person is saying. It also helps alleviate assumptions and other things that get taken for granted. Opening a laptop, scrolling through texts, or otherwise getting distracted by anything else is not active listening and may even violate the Scrum Value of respect. This means that active listening is even more difficult over video.

Another part of active listening is waiting to speak. This is my particular problem. I tend to complete the other person’s sentence in order to move the conversation along. I think I’m being helpful, but I’m probably coming across as rude. This is especially true for people who don’t know me and is very apparent to me when I have a conversation with another individual like myself!

Fortunately, we have techniques that can be used to overcome this particular interpersonal dysfunction. My favorite is to take a stack of sticky notes with me and write down the things that come to mind while the other person is talking. Soon it will be my turn to talk, and I can go back through my notes. See what I did? I solved the feedback and interruption problems with a single solution.

Remember the HARD mnemonic. HARD stands for Honest, Appropriate, Respectful, and Direct. It is a reminder of how you should always communicate with people, especially those who don’t know you. Active listening plus HARD communication is a recipe for successful collaboration.

Fabrikam Fiber Case Study

During a recent Sprint Retrospective, Scott (the Scrum Master) brought up his observations made during the Sprint. He witnessed a few Developers having difficulty conversing respectfully with one another (as well as with stakeholders) during a few meetings. As a team, they decided to improve their communication abilities, specifically their active listening skills. Scott did some searching online and found several websites dedicated to the subject. During the next few Sprints, Scott coached the team as they experimented with some of the techniques that they learned.

Collaborate Productively

Collaboration means working with people. This typically means dividing the work between two or more individuals and working together. Both the process of dividing the work and the actual working together with others require concentration and focus. Getting into this productive state, otherwise known as flow or the zone, can take time. Getting out of that state prematurely, as caused by any kind of interruption, can be considered waste. The irony is that collaboration requires interruption, and you will need to get used to it, tame it, and control it in order to collaborate effectively.

We are taught at a young age that it is disrespectful to interrupt others. If your team is working in an open-space team room, it’s easy to see when fellow Developers are in the zone—deep in thought. Your instinct should be not to interrupt them. When you’re working by yourself, however, it may be harder to know when you are in the zone. Stopping to take a mental assessment may actually kick you out of the zone. Professional Scrum Developers know how to minimize wasteful interruptions in order to maximize productivity. Numerous books, blog posts, and whitepapers have been written about being more productive.

Here are a few of my favorite tips:

• ■   Silence your cell phone   Turn it to vibrate, turn it off, or leave it in your car or backpack.

• ■   Exit Microsoft Teams/Slack   Unless the Developers have established a working agreement, close your collaboration app or set its status to busy.

• ■   Don’t check your email   Email can be a great productivity tool, but it can waste a lot of your time as well. If you can’t or don’t want to turn it off, then be sure to disable all notifications. Having an icon appear in the system tray, seeing the mouse pointer change, or hearing an audible alert when a new email arrives can have the same conditioning effect as one of Pavlov’s dogs hearing a bell ring. Try to check email only three times a day: at the start of your day, at lunch, and before leaving.

• ■   Limit Internet searches   Developers can spend their whole day on the internet if they are not careful. Establish a scope and timebox for any research.

• ■   Avoid formal meetings   As I mentioned in the previous section, one reason that Scrum is successful is that it defines the important meetings in order to minimize the need for unimportant ones. A Developer’s productivity drops when they are away from their tools. Feel free to attend valuable ad hoc meetings over coffee or at another’s desk, but send the Scrum Master to the formal meetings in the team’s stead.

• ■   Stop shaving the yak   Yak shaving is when you perform a task that leads you to another related/semi-related task, and so on, and so on. At any point you can explain or justify what you are doing, but you are also far away from your original goal. Yes, Developers can have complex development environments. These can include multiple versions of software, one or more integrated development environments (IDEs), virtual machines, databases, frameworks, cloud accounts, software development kits (SDKs), testing tools, installers, and so forth. Do yourself a favor: get it working, script it, snapshot it, and forget about it. Endless tweaking tends to have a diminished return on value. Solve today’s problem today and tomorrow’s problem tomorrow.

• ■   Use a Pomodoro technique   This is a time management practice that uses a timer to break down work into intervals (such as 25 minutes) separated by short breaks. There are many great Pomodoro/focus-keeping apps in your phone’s app store.

• ■   Just get started   Some planning is required before starting a task, but overplanning can crush productivity.

• ■   Use active listening   As I mentioned earlier, when your colleague is talking, you should listen to what they are saying and expect the same courtesy when you are talking. Practice this at the Daily Scrum.

• ■   Realize that life happens   We’re all human and have a life outside of our work. When issues emerge, be open and honest about them, and take the necessary time to get your head right. Be appropriately transparent with the rest of your team.

Fabrikam Fiber Case Study

The Scrum Team is always looking to do better. This is evident during their Sprint Retrospectives, where collaboration practices are almost always discussed as improvement is sought. Everyone knows that the best way to improve productivity is to improve how they interact with one another and stakeholders.

Be T-shaped

A Scrum Team must be cross-functional. This means that, for any given PBI, the Developers must be able to do all of the work without relying on people who are not on the team. If the Sprint plan is represented with tasks, then it means that each task, for each PBI in the Sprint, can be accomplished by at least one Developer on the team. For example, if one of the tasks requires Microsoft Power BI integration, that means a Developer must know Power BI. It doesn’t mean that all Developers must know Power BI.

That said, I believe that Professional Scrum Developers should be open to learning and even mastering new skills. This is the notion behind being T-shaped, a concept used to describe the abilities of an individual Developer. The vertical line on the letter T represents the depth of a particular specialty (C#, TypeScript, Selenium, UX design, etc.). The horizontal line represents the knowledge base and the ability to be a generalist and collaborate across various skill sets (analysis, design, testing, etc.). You can see a sample T-shaped diagram in Figure 8-1.

FIGURE 8-1 An example of being T-shaped.

Most Developers have probably already mastered more than one skill. Whether or not they claim those other skills—and use them—is the real question. For example, a coder may not write or run Selenium tests because “it’s not their job”—even though they are quite skilled at it from previous experience. Remember the “job” of a Professional Scrum Developer is to deliver value in the form of working product—not just writing code, writing tests, designing UI/UX, and so forth.

Developers living the Scrum value of openness aren’t ashamed to say that they don’t have a particular skill. They are also not allergic to doing something different and learning a new skill in the process. Pairing new Developers with Developers who understand this Scrum Value will help build this new openness muscle. Over time, T-shaped individuals who master another skill become Pi-shaped (π) and even comb-shaped—adding increasingly more vertical, specialization “teeth” to the comb over time.

Achieve Continuous Feedback

Professional Scrum Teams love feedback loops, and the shorter and faster, the better. For example, as soon as a coder types a few lines of substantive code, they press F5 to get feedback from the compiler. As soon as they’ve got a method refactored, they like to get feedback from their unit tests. As soon as they have finished with a task, they like to push their code to Azure DevOps to get feedback from the continuous integration (CI) pipeline. As soon as they have a functional user interface, they like to get feedback from the Product Owner or stakeholders. Quick and continuous feedback like this is healthy for the product, as well as for the team.

Automated feedback provided by unit tests, integration tests, code coverage, code analysis, and acceptance tests is encouraged. Developers can call upon Azure DevOps to provide this feedback at any time, day or night. The results tell the team that they are building the feature correctly. Professional Scrum Developers take advantage of these automated tools to ensure that they are well informed about the progress and quality of their work.

Smell As I’ve mentioned before, it’s a smell if the Developers don’t ask for feedback from the Product Owner or stakeholders during the Sprint. Passing unit, integration, and acceptance tests only ensures that the quality of the design and functionality of the PBI have been met. The Developers should still want to make sure that the people requesting the capability are happy with its design, function, and usability. In other words, the Sprint Review should not be the first time that the Product Owner sees new functionality being demonstrated. Don’t surprise the Product Owner!

Product Owner feedback is just as important as other types of feedback. An engaged Product Owner who knows the product and the wants of its users can quickly give the Developers positive or negative feedback on a PBI being developed. Getting in-person guidance on the usability of a PBI early in its development is very valuable. If the Developers build the wrong thing, it’s essentially the same as if they’d introduced a bug into the product. This, of course, would depend on the team’s definition of a “bug.” Much like the advice for fixing bugs, it’s cheaper to build the right feature earlier than to have to rework it later.

Note The Product Owner feedback loop should be as short and fast as possible as well. This is another argument for collocating the Product Owner with the Developers.

I’m often asked if the Developers can reach out directly to a stakeholder, such as a user or customer, who requested the feature in order to collaborate and gather feedback. Yes! I consider it a quality of a self-managing Scrum Team when the Developers reach out to stakeholders directly. At the end of the day, the Scrum Team is trying to create the best possible product for those stakeholders. The Developers need to know the context for features and have conversations about domain knowledge. Since the Product Owner is not omnipotent, it’s ideal for Developers to collaborate and co-create solutions directly with stakeholders. This approach alleviates the need for long, rambling requirements documents (which are incorrect and stale anyway). It also enables the Developers to confirm—in real time—that the stakeholders fully understand the PBI in question.

It’s probably preferable to involve the Product Owner, or at least make them aware that these conversations are going on. Professional Scrum Product Owners are open to this concept and know, especially at scale, that this will result in less waste and a better product. Keep the Product Owner informed of any potential scope creep or new PBIs. As always, any issues with direct conversations such as these can be discussed at the Sprint Retrospective.

I see Product Owner feedback as falling into four broad categories in Scrum. I have listed them along with some suggested practices and artifacts that can support each, in Table 8-1.

TABLE 8-1 Types of Product Owner feedback.

Type of feedback	When is it given?	How do you do it?	What is updated?
Can you give us more details about this PBI?	Product Backlog refinement, Sprint Planning, any time during development	Collaborate with the Product Owner or stakeholders at a whiteboard.	PBI work item, code, tests, tasks, whiteboard, notes
Do you like this? Is this the behavior you were expecting?	Any time during development	Pair with the Product Owner or stakeholders and inspect the PBI.	Code, tests, tasks, whiteboard, notes
What else do you want this PBI to do or not do?	Any time during development	Pair with the Product Owner or stakeholders and inspect the PBI.	Code, tests, tasks, whiteboard, notes
As a corollary to this PBI, what else do you want the product to do, not do, or do differently?	Sprint Review, Product Backlog refinement, any time during development	Collaborate with the Product Owner or stakeholders to update the Product Backlog.	Product Backlog

The rest of this chapter will discuss effective collaboration practices and tools as they pertain to software development. These are considered complementary practices, which means they are all optional but have been proven useful by other Scrum Teams—especially those using Azure DevOps. Remember that in Scrum, how the Developers work, including the practices they follow and the tools they use, is entirely up to the Developers.

Collaborative Development Practices

Even the simplest software product requires a team with many talents. Beyond having the standard capabilities of design, code, test, and deploy, many types and levels of talent can exist 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 coders with similar résumés and depth of experience. The way in which they analyze and solve problems can vary radically. If presented with a challenge, each may provide an approach that is fit for purpose according to the acceptance criteria, but they can be very different.

A Professional Scrum Team understands this reality and will even use it to its advantage. These types of teams recognize that everyone has a different way of solving problems, and as long as those solutions fit within the parameters and constraints of the product and the team’s practices, they should be embraced. Long, drawn-out discussions and arguments over approaches and coding styles tend to generate little value, and they typically only lower productivity, not to mention morale. If two solutions emerge during discussions, and both are fit for purpose, the Developers should select the least-complex one and move on. The Developers should disagree and commit—and honor the commitment. Over time, every Developer will be able to contribute their design ideas.

In this section, I will explore several contemporary practices that boost the Scrum Team’s effectiveness during collaboration.

Note A self-managing Scrum Team should pick and choose from these practices (as well as others not listed in this book) and try them for a Sprint or two or three. 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, which I take to mean collective code accountability. With this mindset, individual Developers do not own individual modules, files, classes, or methods. All of those things are owned collectively—by the entire team. In other words, 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. That coder is the expert on that component, as well as its steward and gatekeeper for all changes. Strong code ownership like this can 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 approach would allow Dave to code the feature himself. Rest assured, Azure Repos will track who made what changes to which files and enable a merge (or a rollback) to occur if any problems emerged. Another potential problem with strong code ownership surfaces when refactoring. Modern refactoring tools, like those in Visual Studio, can do this safely, but if the changes to those files cross ownership boundaries, the eventual merge operation will block productivity and may introduce instability.

Adopting a collective code ownership mentality can take time. This is especially true if the Developers are used to having strong code ownership. Pairing, mobbing, and shared learning are ways to break up the turf and the politics. Just as it takes time for the Product Owner and organization to trust the Developers’ ability to self-manage, it also takes time for the individual Developers to trust one another.

Note Professional Scrum Developers collectively own more than the code. They also collectively own the Sprint Backlog, the Definition of Done, the Increment, all sizing, all designs, all failing tests, all failing builds, all failures, and all successes!

Tracking Ownership in Azure DevOps

The biggest advantage with collective code ownership is the boost in the social dynamics of the 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 Developers own 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, Azure Repos can help. For any folder or file, you can review the complete history of changes, including metadata like who, when, what, and (hopefully) why via a meaningful comment and linked work item(s). You see an example of this in Figure 8-2. Azure Repos uses the information stored in each Git commit to generate a full history.

FIGURE 8-2 Rich history information is generated from Git commits.

In addition, you can compare the changes between two versions of a file. The diff view shows lines removed from the older commit and lines added in the new one. You can see an example of comparing two versions (commits) of a code file in Figure 8-3. The UI shows removed text in red and added text in green.

FIGURE 8-3 Azure Repos lets you compare any two versions of a file for differences.

You can also annotate (or Git Blame) a file to learn who made which changes to which lines of code, when those changes were made, and (hopefully) why. This is done by prefixing each block of code with the most recent Git commit that touched it. Clicking the commit ID will show additional metadata, including the commit message and possibly an associated work item. Figure 8-4 shows the Annotate feature in action.

FIGURE 8-4 Annotate (also known as Blame) shows who touched each line of code and when.

Fabrikam Fiber Case Study

Because each Developer is an Azure DevOps Project Administrator, everyone has full control over every aspect of the Azure DevOps project. This includes the ability to view, edit, and even delete files from version control. Should the need arise to see who made a change, the Developers know how to view history, compare, and annotate as needed. Mostly they will use the Annotate feature to praise another Developer for good work, rather than blame them.

Commenting in Code

With collective code ownership comes a certain amount of responsibility. Other Developers will need to understand the code and any changes made. If a Developer or a pair of Developers are working on a rather complex part of the code, they might want to add some comments. This can be, for example, a block of comments that gives another Developer enough information to understand the code. The comments can also be regularly sprinkled throughout longer methods. 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 have to tell the reader how the code works. The code should tell them that. Better yet, the unit tests should tell them that. You should prefer unit tests over comments. The best comment is a set of valuable, meaningfully named unit tests with high coverage. Regardless, if the code isn’t clear, then you should refactor the code rather than add descriptive comments. You shouldn’t add comments for the sake of “training” a future Developer. If/when a new Developer joins the Scrum Team, pairing, mobbing, or referring to unit tests are more preferable ways to learn. Also, don’t forget to include meaningful comments and associate with a work item when committing changes in Git. Comments in code are not a replacement for comments when performing Git operations, and vice versa. You need to do both.

When commenting in code, only comment about what the code or unit tests can’t say for themselves. If the code is well formed and follows modern 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 and unit tests are telling you, or another Developer, what’s going on.

Tip Fellow Professional Scrum Trainer Phil Japikse suggests adding comments to highlight technical debt that the Developers have deliberately generated. You can think of it as pinning a credit card receipt directly to the code that caused the debt.

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 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.

Smell It’s a smell when I see a file with the author’s name at the top. I understand a Developer wanting to claim credit for their 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 Developers started practicing collective code ownership. If that’s the case, someone should remove it. Azure Repos and Git track this metadata through commits, 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, bring this up at a Sprint Retrospective and consider meeting with the decision makers to ensure that the value delivered by this practice outweighs the waste that it seems to generate.

Fabrikam Fiber Case Study

The Developers use modern frameworks, principles, and practices as they design and code. As a result, there’s not a lot of need for comments. Only when they are coding some complex methods do they add comments—mostly so they can quickly make sense of the logic. The Developers also know that when committing changes, they will provide a meaningful comment as well as associate the commit to the relevant Task work item (which links back to a forecasted PBI). Together, these two pieces of metadata provide more than enough context to clarify later why the changes were made.

Associating Commits to Work Items

I’m going to make some assumptions here. I’ll assume a Developer or a pair of Developers is working on a forecasted PBI in the Sprint Backlog. I’ll assume the Sprint plan in the Sprint Backlog is represented as Task work items or Test Case work items. In this situation, the Developers should associate each Git commit with the work item they are working on. Why should they do this? As previously mentioned, by linking work items to other work items or artifacts, the Developers can track related work, dependencies, and changes made over time. By associating work items to Git commits, the Developers bridge work planning with work execution to enable bidirectional, end-to-end traceability. I’ll explain.

If a Scrum Team uses the planning tools in Azure Boards in the way I’ve outlined in earlier chapters, they will automatically achieve the linking of Epic, Feature, PBI, and Task work items. If the Developers choose to use tests for their Sprint plan and follow my advice when using Azure Test Plans as I outlined in Chapter 7, “Planning with Tests,” their PBIs will be automatically linked to Test Case work items. On the engineering side, commits are associated with builds and builds with releases. This is done automatically by Azure Repos and Azure Pipelines. In other words, the end-to-end traceability from ideas to plans to work to build to release is performed automatically…almost. There is one critical step that must be performed manually. This step, as depicted by the lightning bolt in Figure 8-5, is the association of each Git commit to the relevant Task or Test Case work item. This manual association will typically be done outside of the browser, in a tool like Visual Studio, Visual Studio Code, or some other IDE.

FIGURE 8-5 Azure DevOps provides bidirectional, end-to-end traceability from planning to release.

To associate a Git commit, simply include the work item ID in the commit comment. For example, if you are working on a Task work item with an ID of 42, then your commit comment might read “Added email validation #42” or “#42 Added email validation.” When you push the commit to Azure Repos, Azure DevOps creates a Commit type link between the commit and work item #42. This link is visible in the work item form as well as in the commit details. You may need to enable the automatic creation of work item links in project settings since this option may have been disabled.

Note Visual Studio Team Explorer also allows you to associate work items to commits through drag and drop from a query. This is nice because you don’t have to memorize work item IDs. You can also associate a commit to a work item—after the fact—in Azure Boards by editing the work item and adding a Commit type link. This is nice if a Developer forgot to do it in Team Explorer.

Smell It’s a smell when I don’t see commits associated with a work item. It could be that the Developers decided that traceability is not worth the extra steps required. In my experience, more often the Developers didn’t know about this capability and that traceability like this was even possible.

Pairing, Swarming, and Mobbing

Of the hundreds of teams I’ve worked with, most were practicing Scrum—in some form or another. Others were considering it. Regardless, they all wanted to become more agile and enjoy those benefits. When asked if they were “working as a team,” they always answered in the affirmative. They would go on to describe that each team member was busy doing something and the team usually got something done. Oh, and they would stand up every day too and discuss what each person was planning on doing that day. Great, but were they working as a team?

There are many ways to work as a team. Some ways are highly collaborative. Some maximize learning. Some minimize cycle time. Unfortunately, some emphasize individual specializations and output. To the untrained eye, all of these ways of working can look like a harmonious team at work. However, some ways of working actually maximize the risk of not delivering—which is especially true because today’s complexity requires combining skills and even cross-learning of skills to succeed.

Over the years, I started identifying and classifying the various styles of teamwork and assessing their impact on the team. I’ve classified these into four dysfunctional categories and three collaborative categories, as you can see in Figure 8-6.

FIGURE 8-6 There are many ways a Scrum Team can work as a team—or not work as a team.

Four ways are dysfunctional in terms of the ability to collectively deliver and to transcend being just a group of individual generalists:

• ■   Hoarding   After Sprint Planning, a Developer claims ownership of multiple PBIs and will do all the work on those items in isolation. Intra-team dependencies (such as knowledge) and external impediments get the Developer to cherry-pick among the selected items, ending the Sprint with some items open and few Done.

• ■   Hogging   After Sprint Planning, a Developer takes ownership of a single PBI to do all possible work before moving on to do the same with the next PBI, and so on. Dependencies and impediments are similar to hoarding, but the single-piece focus slightly increases transparency and reduces the risk of not getting the item Done.

• ■   Specializing   A Developer works those tasks pertaining to their specialty on different PBIs and “maximizes” their specialization across all items. Dependencies are high but remain hidden until toward the end of the Sprint, when late integration greatly increases risk.

• ■   Generalizing   A Developer works a few different types of tasks. Not having all the skills required, the person will still start work on a new PBI when blocked. Dependencies may not be as high as specializing, but integration still occurs late, increasing risk.

Teams that start working in any of following three ways enter the “circle of team collaboration goodness,” where mutual learning happens as an opportunity for professional development to become more T-shaped, pi-shaped, or comb-shaped. Collaborating in these ways also reduces dependencies and risk. Three ways of working fall into this category:

• ■   Swarming   All Developers (alone or in pairs) will work on a single PBI, working multiple tasks in parallel until the PBI is Done.

• ■   Pairing   Two Developers collaborate closely on a single task, potentially changing the pair composition in search of the required expertise. Pairs may be part of a larger swarm on a single PBI.

• ■   Mobbing   All Developers work on a single task, of a single PBI, until that PBI is Done. As in swarming, there is no jumping or moving on before the PBI is Done. Mobbing is sometimes referred to as ensemble programming. To learn more about this practice, visit https://mobprogramming.org.

The practices of swarming, pairing, and mobbing are often confused with one another. Let me try to simplify things. Swarming is when all Developers work on a single PBI—alone or in pairs, working separate tasks. Pairing is when two or more Developers use a single keyboard to work on a specific task. Mobbing is when all Developers use a single keyboard to work on a single task. You can see an example of each in Figure 8-7.

FIGURE 8-7 Swarming, pairing, and mobbing are all collaborative ways of working.

A benefit of pairing and mobbing is that the driver can focus on the tactical (coding) activities, while the observer(s) are thinking about the broader, strategic solution to the problem, as well as helping with training and coaching. You also get a code review for free. This form of extreme collaboration leads to better and simpler designs and fewer bugs, in shorter periods of time. Pairs and mobs working in close proximity like this are also less prone to get sidetracked from the task at hand. Most important is the extreme learning that takes place!

During pairing or mobbing, knowledge is passed back and forth. Developers can learn new practices and techniques from one another. Pairing a newly hired Developer, or a Developer with a different or weaker skill set, with a Developer who is more experienced will help improve the overall effectiveness and productivity of the team. Figure 8-8 shows the possible outcomes of pairing weaker and stronger Developers together.

FIGURE 8-8 Here are possible outcomes when pairing Developers.

Some teams scale this idea using an approach called “promiscuous pairing.” In this approach, each Developer cycles through all the other Developers, rather than pairing with only one Developer. Promiscuous pairing ensures that knowledge of the product and its inner workings spreads throughout the whole team and thus reduces risk if a key Developer leaves. Mobbing does this as well.

Tip Mobbing maximizes learning across all Developers, and it also reduces the risk of not meeting the Sprint Goal and not completing the forecast. In fact, both swarming and mobbing assume that all Developers are working on the same PBI. As such, they are both fantastic practices to help reduce the risk of having undone work at the end of the Sprint.

Interruptions

From time to time throughout the Sprint (or the day in some environments), a Developer will experience an interruption. In a perfect world, this never happens, but in the real world, it does. Switching context to handle the interruption can be time consuming and wasteful. Professional Scrum Developers work to marginalize this reality by reducing the number of interruptions and by making them less painful.

For example, let’s say that you and your colleague are deep in thought, implementing a complex scenario within a PBI, and the Product Owner comes to you with an urgent request. It becomes obvious that your attention is required elsewhere. Since the Product Owner deems it critical to the product and its stakeholders, you should drop what you’re doing and attend to it. Forget your forecast. It’s about saving money, customers, and reputation at this point.

Smell Although the Product Owner has the authority to interrupt the Developers, it’s a smell when I see it happening on a regular basis. Perhaps the Product Owner should spend more time with the product and the stakeholders to identify these higher-risk areas. Perhaps the Developers need to improve the Definition of Done. Perhaps the Developers need to build more slack time into their Sprint (such as forecasting fewer PBIs). Perhaps the Developers need to slow down, generate less technical debt, and get more things Done.

Assuming a Developer has their code open and is making changes when the interruption occurs, the reaction might be to finish what they are doing or create a branch. Both of these are valid options. Depending on the urgency and disdain for branching, another valid option might be to stash the current code changes. Using the git stash command allows you to keep the current changes to your code but not commit them because they are not at a point where you are comfortable doing so.

This command takes the current staged and unstaged changes and saves the work, then returns your workspace to the state of the last commit. This process is similar to shelving in other version control systems. After changes are stashed, you can context switch to your heart’s content and attend to any interruption. If you are interrupted again, you can use git stash again. Later, you can reapply your stashed changes, as I’m doing from Visual Studio in Figure 8-9. A stash is local to your Git repository. In other words, stashes are not pushed or synced with Azure Repos.

FIGURE 8-9 Manage stashed changes from Visual Studio Team Explorer.

Smell It’s a smell if I see more than one stash listed. Maybe you are the kind of Developer who spends more time helping, mentoring, and supporting others and thus are often interrupted. This could explain the various pieces of suspended work. Maybe your environment is so chaotic that even the interruptions get interrupted! Maybe you are just the kind of Developer who gets sidetracked easily, leaving a bunch of half-eaten sandwiches sitting around your house—which is a different kind of smell.

Code Reviews

Code reviews help assure code quality by having other Developers 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 technical debt, is readable, meets the Developers’ agreed-upon coding standards, and meets the Definition of Done. Additionally, code reviews are learning opportunities for all involved.

Professional Scrum Developers recognize that the candid feedback (colloquially known as criticism) given during a code review is targeted at the code and not the coder. For new Developers, or at least those new to code reviews, there can be a tendency to take this feedback as an insult, even to become defensive. Everyone should be mindful of the Scrum Values of respect and openness during code reviews. Over time, all Developers will have an opportunity to review the work product—and an opportunity to prove that they are human and make mistakes too. Everyone can improve. Code reviews are just another type of shared learning activity, where anyone can learn from anyone.

Tip Code reviews can also catch and enforce coding style and standardization issues. Be careful not to spend too much time with these kinds of topics during a code review, since they can become a rathole. A rathole is any discussion that detours the original purpose of the conversation. Don’t get me wrong—discussions about coding styles and standards are very important, but any debate or decisions about changing existing standards or establishing new ones should be deferred until the Sprint Retrospective. Professional Scrum Developers know that matters of style are not absolute. Developers should be allowed to self-manage and use whatever style they determine is fit for purpose. After a team has been working together for a while, their coding standards will begin to emerge—and hopefully merge. These standards may even become part of the Definition of Done.

Also, it may be beneficial to ask people outside the team to review the code and artifacts. These could be people from other teams in the organization or peers who the team respects. It’s useful to get the opinion of someone not working directly in the code, especially where new technologies are concerned.

When reviewing someone else’s code, you should avoid appearing as a “senior” Developer. Although you may be formerly known as “senior” or “lead,” there are no titles in Scrum. All Developers are equal and should focus on sharing and learning. Choose tone and words carefully as you identify issues and improvements in someone else’s work. Developers new to Scrum may also be new to the value of openness. Don’t aggravate the situation by 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. Professional Scrum Developers actually look forward to code reviews. This is because those Developers know that the code is owned collectively. Problems and criticisms aren’t directed at a single Developer; rather, they are learning opportunities for all Developers. Everyone “develops” something, and having a reviewer with a different approach and perspective should be seen as a benefit, demonstrating the Scrum Value of openness.

Smell It’s a smell when I see Developers performing code reviews in addition to pairing or mobbing. Since you can think of pairing and mobbing as a form of code review—one that happens in real time—I don’t like to see added waste in the process by including another stage or gate in the process. It smells like someone outside of the team is imposing code reviews and/or doesn’t understand that pairing and mobbing provide the same outcome. That said, if the Developers find value in having an informal code review for the sake of learning, then far be it from me to suggest otherwise.

It’s also a smell when I see a collocated team using tools to facilitate code reviews. They should be able to practice these reviews in person. Excuses are usually to the effect of “we’re busy.” It’s obvious that they want to use the asynchronous behavior that the tool provides. I understand that there’s a cost to interruptions, and that tools like Microsoft Teams and Slack are good for quick questions. Code reviews are not quick interruptions. They require a full stop, a context shift, focus, and participation in order for the review to provide value. As I’ve mentioned several times in this chapter, conversations that take place face to face are more efficient, reduce ambiguity and misunderstanding, and provide more value than anything facilitated by a tool.

Professional Scrum Developers build solutions that are fit for purpose while avoiding gold plating. Gold plating is any design or work 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 Idaho, and the Developer includes additional logic to handle the surrounding states, that’s gold plating. The Developers 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, Developers should solve today’s problem today and tomorrow’s problem tomorrow—in the next Sprint. Code reviews can be a good way to unearth gold plating.

Fabrikam Fiber Case Study

The organization has no policies for code reviews. They leave everything up to the team to decide. Sometimes 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 “reviews” usually become an impromptu pairing session. In addition, the Developers like to invade the conference room and use a big screen. Each Developer in turn shows off their work. With a full room, this approach encourages discussion on design and style.

Branching

Branching is the duplication of a folder or file in a repository so that Developers can make modifications to the branch while keeping the source of that branch stable. The originating branch is typically referred to as the parent branch, and child branches are those that have a parent. A branch without a parent is referred to as the trunk or main.

Note As of this writing, the top-level, default branch in Git is named master. Git’s maintainers will be adding a flag that will let its name be changed. In the next major version, Git will probably start using the term main instead of master. GitHub and Azure Repos will follow suit.

Working in branches enables Developers to develop parts of the product in parallel. Branches support the ability to have multiple releases—for different configurations (such as CPU architecture, operating system, or other customizations). Branches also enable Developers to isolate changes without destabilizing the code base, like when they fix bugs, add new features, or integrate versions. These divergent changes are typically merged (integrated) back into the parent branch at a later point in time.

With legacy version control systems, like Team Foundation Version Control (TFVC), working within a branch was optional. The Developers would be able to work in folders, directly on files until they wanted to explicitly create a branch. With Git, you are always working within a branch. In fact, it’s impossible to not be in a branch.

Developers should limit the number of branches in use. Unfortunately, the software development community has become “branch crazy” with tools, practices, and patterns encouraging branching. Creating and working in development branches has become mainstream. These would be the branches used by the Developers as they develop individual PBIs. GitFlow and GitHub Flow are both popular branching strategies that define strict branching models. Although there are nuanced differences, both are feature-branch focused and recommend creating a new branch whenever the Developers (or a single Developer) begin working on a new PBI. This strategy sounds good on the surface, but it can lead to dysfunctional team behavior such as hoarding and hogging, which I mentioned earlier. This can lead to delays in getting to Done!

Even with Developers regularly pushing to branches, the integration between the different branches or between the branch and main is delayed. Until the code is in a single shared location such as main, the Developers won’t know if something will break during the merge, how difficult the merge will be, if the work will be duplicated, or if the work is incompatible in some way. Automated build and testing will take Developers only so far when working in development branches. Multiple development branches create distance between the Developers, which can cause a decrease in collaboration, a delay in integration, an increase in waste to diagnose and fix a broken build, and an increase in the risk of not achieving the Sprint Goal.

Trunk-Based Development

Enter trunk-based development (https://trunkbaseddevelopment.com), an approach to branching that is increasingly gaining more popularity in the community—especially since it has been used at Google by tens of thousands of developers doing concurrent development. Trunk-based development is an anti-branching model that brings Developers together by having them clone, check out, and work directly in main or trunk. The Developers will update, pull, and sync from main or trunk many times a day. They are now integrating their commits with their teammates’ commits on an hour-by-hour basis, if not more often.

Similarly, when a Developer (or pair) completes a small piece of work (for example, a task or refactoring) they will commit and push it back to main or trunk. This will cause the team to gravitate to more collaborative ways of working, such as swarming or mobbing. In order to not break the build, any code changes will be pulled, merged, built, and tested in their local repository. Any problems are resolved locally before pushing to main or trunk. Depending on how long it takes to pull, build, test, and resolve issues, this cycle may have to be repeated.

Note Many branching strategies, including trunk-based development, have the rule that anything in the main/trunk branch should always be deployable. Although I understand the desire for this, Azure Pipelines and Azure Artifacts offer cleaner alternatives for ensuring that the latest, stable binaries and artifacts are deployable. In other words, if Developers want to deploy (or redeploy) the latest binaries, rather than pull from main or trunk, rebuild, and deploy, they could just pull the latest stable artifacts from Azure Artifacts or push the latest stable build or release in Azure Pipelines. With Azure DevOps, the need to keep the main/trunk branch stable is no longer a requirement to release on demand.

Fabrikam Fiber Case Study

Individual Developers have become comfortable working in feature branches during development. Creating a separate branch for each PBI has made it easier for them to work on two or more PBIs at a time. Knowing that this way of working is risky—for many reasons—they plan to move to trunk-based development. As a corollary, they will also increase their swarming on a single PBI at a time.

Continuous Integration

Professional Scrum Developers—especially those practicing trunk-based development—have learned how to work smarter, not harder. One way that they do this is by continuously integrating their code changes with other Developers and by running automated tests to verify that those integrations don’t break anything. Although these same automated tests can (and should) be run locally—for example, in Visual Studio—Azure Pipelines can probably run them faster and asynchronously, enabling the Developers to work on something else while the build executes. Another benefit is that the tests can be run in a controlled environment that can quickly make transparent any configuration management problems.

A better way to avoid painful, manual merge operations is to do smaller, less-painful merges throughout the day. This is the basis for continuous integration (CI). CI is more than just ensuring that the integrated code builds without error; it also mandates tests being run. In other words, upon a push to Azure Repos a build pipeline gets triggered. Applicable code is compiled, binaries are generated, automated tests are run, and feedback is returned to the Developers quickly.

Tip Another way to minimize the pain of manually merging code is to actively listen to the other Developers during the Daily Scrum. Remember that the purpose of the Daily Scrum is to synchronize and create a plan for the next 24 hours. This means that each Developer verbally shares their planned work with others. If one Developer hears another Developer mention a task that will be in the same part of the codebase that they were planning on working on, they should consider pairing up and working on their overlapping tasks together. Doing so should alleviate the need to manually merge code changes, as well as increase knowledge and productivity in general.

CI is about reducing risk. When a Developer defers integration until late in the day, the week, or the Sprint, the risk of failure (features not working, side effects, bugs, etc.) increases. By integrating code changes with others regularly throughout the day, the Developers will identify these problems early and be able to fix them sooner because the offending code is fresh in everyone’s mind. The practice of CI is a must for a high-performance Professional Scrum Team.

As previously mentioned, any branching strategy—especially trunk-based development—should strive to keep the code in main or trunk pristine—and releasable. One way of doing that is to implement a CI pipeline. The CI build should run as quickly as possible, returning the feedback quickly and clearly, especially if main or trunk is broken. I like using the CatLight extension, which puts build notifications right in my tray. You can see how CatLight informs me of a failed build in Figure 8-10. Learn more about this extension at https://catlight.io. Remember, Professional Scrum Developers collectively own all things, including working in a way that keeps the build from breaking, but also in repairing a broken build.

FIGURE 8-10 CatLight notifies you when a build fails.

Refactoring, restructuring classes and methods, and changing internal interfaces can be messy work. There may be times that you want to push your not-yet-finished code so that another Developer can begin working with a part of it. You may also want to see how many errors, warnings, and failed tests occur when your changes are integrated with others. Generally speaking, this is fine. This is feedback. This is learning. But you should keep the integrity of the main/trunk code in mind as you do so. If possible, try to adopt a “merge down, copy up” (called “pull, push” in Git) behavior where you pull changes, resolve any conflicts locally, build and test locally, and then push the merged and verified code back to Azure Repos. This strategy minimizes the chances that you will break the build.

Fabrikam Fiber Case Study

The Developers have long been fans of continuous integration and have created several CI pipelines to watch over various parts of their repository. As the Developers move toward trunk-based development, they will explore how to make their CI pipelines faster. A dedicated, self-hosted pipeline with fast hardware will be a good start. Another experiment they plan to try is to enable Test Impact Analysis in the pipeline to speed up testing by only running those tests that were impacted since the last build. For more information, refer to https://aka.ms/test-impact-analysis.

Pull Requests

To review, branches are used to isolate work until such time when those changes are to be merged into another branch such as main. A pull request is a mechanism that tells other Developers about changes that have been pushed to Azure Repos with the intent to merge them into another branch. The intention is that the pull request becomes the collaborative process that lets the Developers discuss these potential changes and then agree to merge them once everyone approves. This is fine for dislocated teams, such as those collaborating on open source projects, but it’s wasted on Professional Scrum Teams, where they collaborate, discuss, and agree in real time.

Note I’m not explicitly anti-pull request, but I am anti-branch. This is because branching, by definition, promotes isolation and not collaboration. I believe that trunk-based development is the approach to take. So, since pull requests require branching, then I guess I’m anti-pull request too. Besides, pairing and mobbing are better alternatives to code reviews (via pull requests) anyway.

If Developers want to self-manage and experiment with pull requests as a mechanism for code reviews, then who am I to suggest otherwise? I would just caution those Developers on preferring a tool over interacting directly with individuals. For example, a dislocated Developer may want someone else to look at their code before integration, and if the Developers have deemed other review practices as less effective, then creating a short-lived branch for the sake of a pull request might be useful. If, on the other hand, it becomes an established policy that every change must go through a pull request, then it becomes a delay that dissuades collective code ownership behaviors.

Chapter Retrospective

Here are the key concepts I covered in this chapter:

• ■   Collaboration is key   Software development is a team sport. The Scrum Team members need to communicate with one another, as well as stakeholders, effectively.

• ■   Collocated teams are more productive   Scrum Team members working in close proximity are more productive and generate more business value than dislocated teams—those who are geographically, temporally, or culturally distributed. Large, open-space team rooms can be particularly effective.

• ■   Meet effectively   Scrum has all the built-in events (meetings) that a team needs. Limit attendance to other meetings, or send the Scrum Master instead—who is supposed to be protecting the team’s focus.

• ■   Listen actively   Use active listening communication techniques that enable better, more effective dialogue. These techniques support the Scrum Values of respect and openness.

• ■   Limit interruptions   Turn off or otherwise neutralize cell phones, email clients, and other communication tools. Limit research, internet searches, nonessential meetings, and yak shaving.

• ■   Strive to be T-shaped   Team members who are T-shaped have a deep expertise as well as a wide knowledge base. T-shaped Professional Scrum Developers are open to learning and doing new things, even if they are out of their comfort zone.

• ■   Developers collectively own the code   The Developers own every aspect of the code. Everyone can clone, pull, and push code for any aspect of the product. Fear not, Azure Repos will track all changes being made.

• ■   Comment code only if it adds value   Only comment when you need to and in accordance with the Developers’ working or social agreement. When commenting, be sure to adequately explain your actions to others. When possible, let the unit tests do the commenting.

• ■   Associate commits to work items   When performing a Git commit, be sure to associate it with the relevant Task or Test Case work item. This manual step will ensure bidirectional, end-to-end traceability from ideas, to plans, to work, to builds, to release.

• ■   Consider practicing swarming   All Developers (alone or in pairs) will work on a single PBI, doing whatever is required, until the PBI is Done.

• ■   Consider practicing pairing   Two Developers collaborate closely on the same task.

• ■   Consider practicing mobbing   All Developers work on a single task, of a single PBI, until that PBI is Done. Like swarming, there is no jumping or moving on before the PBI is Done.

• ■   Practice code reviews only if they add value   Practice these in person, or consider pairing or mobbing as an alternative. Developers should be open to giving and receiving criticism. Avoid using tools to facilitate a code review.

• ■   Consider practicing trunk-based development   Simply put, don’t work in branches; instead, work directly on main or trunk.

• ■   Integrate continuously   Merging is painful, so do it more often and it will hurt less. Stay in touch with your builds so that you will be notified of failed builds as early as possible. Get them healthy again as soon as possible. A failed build is everyone’s concern.