Professional Scrum Development with Microsoft Visual Studio 2012: Effective Collaboration

There’s a buzz—a kind of energy that you can feel—when a high-performance Scrum Development Team works in harmony to solve a problem. Each developer gets totally absorbed in his or her task. Each member of the Development Team does his or her part integrating the design, the coding, and the testing. Scenarios and features are completed and verified. Product Backlog items (PBIs) are moved to the done column. Everyone loses track of time. They are experiencing flow. Everyone feels happy and satisfied.

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 each other or everyone’s strengths and weaknesses. This leads to the storming stage, where each developer competes for their idea’s consideration while working together to resolve their differences. This necessary 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 phase. Here, the entity of the team begins to emerge. The members converge on a single goal and come up with a mutual plan. Compromise and consensus decision making occurs in this phase. High-performance Scrum Development Teams have reached the fourth and final phase, known as performing. These teams not only function as a unit, but they also find ways to get the job done smoothly and efficiently. They are able to self-organize and self-manage effectively. In my opinion, very few teams reach this phase, but every one that does has mastered the art of collaboration.

In this chapter, we will look at some practices and tools that enable more effective collaboration. By learning and adopting these practices, a team will increase its ability to reach the performing phase of Bruce Tuckman’s model.

Individuals and interactions over processes and tools

The Agile Manifesto clearly states that while there is value in process and tools, there is more value in interacting with individuals. This is to say that Agile software development recognizes the importance of people and the value that they bring when working together. After all, it’s people who build software, not the process or the tool. 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 Velocity may suffer, but they will produce value. They will also inspect and adapt their processes, while looking for methods of improvement. 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, and learn from each other. In other words, they must collaborate. Even a team of expert craftsmen (rock stars in their own right) is doomed to fail if they don’t collaborate with each other. If the striker on a soccer team has his best game ever—scoring four goals—but the other team scores five goals, it is still a loss. The other team, with even mediocre players, probably collaborated better.

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. These are software developers. They are some of the smartest problem solvers you’ll ever meet. Besides, Scrum is easy to understand. Chapter 1 pretty much covered it. No, what these people are talking about is the discipline of practicing Scrum correctly within an organization that allowed them to do so, every single day. That’s why they gave up.

I agree with the Agile Manifesto. This is evident throughout this book as I point out the value of interacting and collaborating with individuals. I have discussed process and tools as well, but have been most vigilant in pointing out that not all application lifecycle management (ALM) tools and automation frameworks are healthy for a team. Most are. Some, however, can lead to one or more dysfunctional behaviors. For example, social networks, televisions with digital video recorders (DVRs), and video games 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 once asked to build a web-based work item approval system on top of Team Foundation Server (TFS). The client designed it so that email alerts would be sent when a work item changed to a certain state. 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 on vacation or 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 two people to meet face to face and have a discussion. This was a learning opportunity for me and something I keep in mind whenever I see a shiny new feature in Microsoft 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, and stay focused on these topics.

• 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 time-box for the meeting. Be prepared to explain the concept.

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

• Employ active listening techniques.

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

Listen actively

Software developers tend to have a short attention span and be impatient with anybody who is not as smart as them 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 curing it. For me, active listening was that cure.

Active listening is a communication technique where the listener is required to feed back what is heard to the speaker. This can be as simple as nodding the head, writing a note on a piece of paper, or restating or paraphrasing what was said. This demonstrates your 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 and clicking through emails or otherwise getting distracted by anything else is not active listening and may even be considered disrespectful. Even “lightweight” devices such as tablets, slates, and smartphones can fall into this category.

Another part of active listening is waiting to speak. This is my particular problem. I tend to complete other people’s sentences in order to move the conversation along to a more interesting topic. In my mind, I think I’m being helpful, but I know that I’m probably coming across as being rude. This is especially true for people who don’t know me and is especially apparent to me when I have a conversation with another ADHD individual. Fortunately, there are 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.

I’ll re-mention HARD at this point. HARD is a mnemonic for Honest, Appropriate, Respectful, and Direct. It is a reminder of how you should always communicate with people, especially those that don’t know you. Actively listening plus HARD communication is a recipe for successful collaboration.

Collocate

I think we can all agree that communication and collaboration provides 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 text that is exchanged. 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, the Scrum Team, and certainly the Development Team, should be continuously “meeting.” These are not traditional meetings, where someone speaks and everyone else listens. These are short, collaborative, time-boxed meetings with the specific purpose of solving a problem. In fact, I wouldn’t even call them a meeting, but more of a conversation. 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 Development Team is in the zone, developing and generating business value.

When forming a new Development Team, collocation should be a requirement. This is not just a nice-to-have feature. It’s required if you want a high-quality product and process. By collocation, I’m not talking about being in the same time zone, city, or building. While these options are better than some I’ve seen, I want the team in the same room or in adjacent rooms. The Product Owner should be nearby too, but not necessarily in the same room. This way, the face-to-face communication can occur on demand.

Professional Scrum developers know the value of collocation, and they strive for it. That said, there may be cultural, political, or financial reasons for not collocating the Development Team. 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 on that, taking into account the decreased quality of the product and the process. 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.

Most organizations consider their custom software as 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 the 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.

Set up a team room

Having the entire Development Team work in a shared, common room can be a good thing. Whiteboards containing plans and design notes are visible to everyone. Artifacts such as the Sprint Backlog and burndown chart can be updated easily and seen by everyone. During critical design points, the team room can become a war room of sorts as the developers move from strategic planning to tactical planning. Communication becomes more open and happens in real time. Developers tend to focus their productivity toward 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 a war room 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-organize to come up with solutions for these requirements. I’ve seen developers put on headphones, adjourn themselves to quiet rooms, or work away from the office for a short time as needed. Ideally, the managers and the organization trust their developers to the point where they can accommodate their needs. If they don’t, then that is a big impediment to self-organization. Generating business value in the form of working software is a way for the Development Team to 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 just human. Their idiosyncrasies map directly to their ability to collaborate and work effectively as a team. The Velocity at which the Development Team is able to create business value is a function of the Development Team’s productivity. Perhaps for these people, being in close proximity to, but not in the same shared room with, the rest of the team is good enough at first. A strong Scrum Master, as well as open and honest Sprint Retrospectives, can be used to improve this.

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

Meet effectively

High-performance Scrum Development Teams know to avoid meetings, if possible. To be clear, I’m not talking about the built-in Scrum events, such as the Sprint Planning meeting, the Daily Scrum meeting, the Sprint Review meeting, or the Sprint Retrospective meeting. I’m also not talking about the regular Product Backlog grooming sessions, nor those impromptu but important meetings requested by the Development Team in order to clarify requirements, gather feedback, or seek the Product Owner’s acceptance. I hope, in fact, that I’ve made it clear that these meetings are important and they should be attended by all of the involved parties face to face, if possible. I am talking about all the other meetings that an organization might require its technical staff to attend. You know the ones that I’m talking about They are mandatory, read-only (they don’t ask for your feedback), and provide zero business value to the software product being developed or the development process itself. Unfortunately, some of these meetings cannot be avoided. They are a fact of 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 it’s not, you may have to query the meeting organizer or sponsor. I know many developers who 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 Development Team at meetings like this is one of his or her duties and allows the Development Team to what they do best.

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 the other built-in meetings.

• Keep the meeting as short as possible.

• Establish a time-box to enforce it.

• Outline the agenda and expected outcome in the invitation.

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

• At the beginning of the meeting, explain the time-box and its concept.

When someone who is versed in Scrum sets up and runs a meeting, he or she will end up sharing good behaviors and practices, such as transparency, active listening, and time-boxing. This is a good way to get others in the organization more educated on Scrum and some of its attributes and practices. If appropriate, email any retrospective notes to the attendees, including action items. These behaviors may even infect the organization as other business units and teams will want “to get some of that Scrum.”

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 can require intense concentration. Getting into this productive state, otherwise known as the 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 and master it.

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 a fellow developer is deep in thought or in the zone. 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. High-performance Scrum developers know how to minimize interruptions in order to maximize productivity. There have been numerous books, blog posts, and white papers written about being more productive.

Here are some of my favorite tips:

• Cell phone Turn it to vibrate, turn it off, or leave it at home.

• Exit Microsoft Outlook 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, after lunch, and before leaving.

• Exit IM/chat client Close the program, or at least set your status to busy. The exception to this is if the tool is used by the Development Team to share code or quick questions and feedback.

• Limit Internet searches Developers can spend their whole day on the Internet if they are not careful. Time-box the search and keep the scope to just researching the problem at hand.

• Just get started Some planning is required before starting a task, but overplanning becomes the antithesis of productivity.

• Avoid formal meetings One reason that Scrum is so successful is that it defines the important meetings to minimize the need for unimportant ones. A developer’s productivity drops when he or she is away from the keyboard. Feel free to attend the valuable ad hoc meetings over coffee or at another’s desk, but send the Scrum Master to the formal meetings in the Development Team’s stead.

• Use active listening When your colleague is talking, you should listen to what he or she is saying, and expect the same courtesy when you are talking.

• Stop fiddling Developers can have complex software environments. These can include multiple versions of software, one or more integrated development environments (IDEs), virtual desktops and servers, databases, frameworks, software development kits (SDKS), testing tools, installers, etc. 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.

• Life happens We’re all human and have a life outside of software development. When issues emerge, be open and honest about it, and take the necessary time to get your head right. Be appropriately transparent with the rest of your team.

Achieve continuous feedback

Developers love feedback loops—the faster the better. As soon as we type a few lines of substantive code, we hit F5 to see what the compiler thinks. As soon as we’ve got the method refactored, we run our unit tests to see them pass. As soon as we have a tangible user interface (UI), we have a colleague or the Product Owner look at it to tell us how he or she likes it. As soon as we are done with a task, we check in so that the continuous integration build or another developer can evaluate our work. Continuous feedback like this is healthy for the product, as well as the developer.

Automated feedback provided by builds, unit tests, code coverage, code analysis, and acceptance tests are awesome. Developers can call upon Visual Studio or TFS to provide this feedback at any time, day or night. The results tell the Development Team that they are building the feature correctly. High-performance Scrum Development Teams will take advantage of all of these features to ensure that they are well informed about the progress and quality of their work.

Product Owner feedback is just as important as other types of feedback. An engaged Product Owner who knows the product and the desires of its users can quickly give the Development Team positive or negative feedback on a feature being developed. Getting in-person guidance on the usability of a feature early in its development is very valuable. If the Development Team builds the wrong feature, it’s essentially the same as if they introduced a bug into the software product. The same advice goes for features as for bugs—it’s easier and cheaper to “fix” them earlier in their lifecycle.

I’m often asked if the Development Team can reach out directly to the stakeholder (user or customer) who requested the feature in order to gather feedback. Technically, the answer is no. The Product Owner is the one source of feedback to the Development Team. If she wants to establish her own feedback loop to the stakeholders, that’s her prerogative. That said, I feel that there are times and conditions where the Development Team can solicit feedback directly from a stakeholder if they decide that bypassing the Product Owner will provide them more value. The Product Owner should be informed and agree to this. During the next Sprint Retrospective meeting, this can be discussed to determine if it was a one-time thing or if there’s a deeper dysfunction to address (like an untrained or absent Product Owner).

I see Product Owner feedback as falling into three broad categories in Scrum, with practices and tools that can support each. These are listed in Table 8-1.

Table 8-1. Types of Product Owner feedback with the associated practice and tools.

Type of feedback	When is it given?	Practice	Visual Studio tool
Can you give us more details about this PBI?	Product Backlog grooming, Sprint Planning meeting during development	Collaborate with the Product Owner or stakeholder at a whiteboard	PBI work item, PowerPoint storyboarding
Do you like this? Is this the behavior you were expecting?	During development	Sit down with the Product Owner or stakeholder and go through the feature	Microsoft Feedback client
What else do you want, not want, or want developed differently?	Sprint Review meeting	Collaborate with the Product Owner and stakeholders to update the Product Backlog	Team Web Access, Microsoft Excel

The rest of this chapter will discuss some of the more effective collaboration practices and tools.