We are happy to announce the availability of Professional Scrum Development with Microsoft Visual Studio 2012 (ISBN 9780735657984), by Richard Hundhausen.
Discover how to turn requirements into working software increments—faster and more efficiently—using Visual Studio 2012 in combination with Scrum and Agile engineering practices. Designed for software development teams, this guide delivers pragmatic, role-based guidance for exploiting the capabilities of Application Lifecycle Management (ALM) tools in Visual Studio and Team Foundation Server. Team members will learn proven practices and techniques for implementing Scrum to manage an application’s life cycle, as well as seamlessly plan, manage, and track their Scrum projects.
Purchase your copy today here or here. To support an independent bookstore, order here.
In today’s post, please enjoy an excerpt from Chapter 8, 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.
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.
Tip Fellow Professional Scrum Developer Simon Reindl reminds us that to err is human, but to forgive is vital.
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:
In this section, I discuss some of the general—but important—collaboration practices that a Scrum Team can adopt.
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.
Tailspin Toys case study During a recent Sprint Retrospective meeting, Scott (the Scrum Master) brought up his observations made during the Sprint. He witnessed a few developers having difficulty conversing respectfully with each other (as well as with stakeholders) during a couple of 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 adopted more and more of the techniques that they learned.
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.
Tip Fellow Professional Scrum Developer Simon Reindl suggests bringing a geographically dispersed team together periodically. This is especially true at the beginning of a new project, so they know with whom they are working.
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.
Note Do I think that developers working remotely as part of a distributed 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. That said, an attribute of a professional Scrum developer is to inspect and adapt constantly, such as looking for ways to improve the process. Collocating a dislocated team is one of the biggest improvements that can be made, usually resulting in an increase of quality and Velocity. That team’s Product Owner should wake up in the morning and go to bed at night, thinking of ways to maximize the product’s value through the work of the Development Team, such as through collocation.
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.
Note I recently 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 programmers. 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 programmers 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 developers could fix it. The programmers 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 three to four days before testing could proceed. He asked me how TFS 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 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.
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.
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 developers working on a common software product. Both environments can generate noise, but the type of conversations found in an open-plan office will typically be more contrasting and thus, more distracting.
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.
Tailspin Toys case study The Development Team has been collocated since day one, with Paula (the Product Owner) in a nearby office. During the Sprint, they regularly meet and collaborate whenever and wherever it is required. Day to day, the developers sit near each other in a large, open-space room with a half-dozen whiteboards (approximately one for each PBI). Because the developers use laptops with wireless connections, there’s a minimum amount of cables in the room, and individuals can be more nomadic as they work. When one of the developers needs to concentrate or requires some personal space, he or she 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 an always-on Skype connection, including video. Scott (the Scrum Master) has done a good job of educating the organization. Although the stakeholders know where the team room is located, they know to avoid it during a Sprint—unless of course they’re invited by the Development Team. Scott still has to remind them from time to time.
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:
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.”
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 that there is partial agreement on, saying “yes, and …” comes across as being more constructive. 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 be more prone to ideas. More importantly, the person will be more open to collaborating on a shared solution, which should always be the goal to avoid discussions becoming polarized.
Tailspin Toys case study Paula (the Product Owner) and Scott (the Scrum Master) are good at running interference for the development team. For meetings that are not related to the development of the software product, Scott will try to attend as a proxy for the Development Team. Some meetings, such as the “all hands” meetings, cannot be avoided, and the developers do attend them.
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:
Tailspin Toys case study The Scrum Team is always looking to do better. This is evident during their Sprint Retrospective meetings where collaboration practices are almost always discussed as improvement is sought. Everyone knows that the best way to increase Velocity is to improve the individuals and interactions.
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.
Smell It’s a smell if the Development Team doesn’t ask for feedback from the Product Owner during the Sprint. Passing unit and acceptance tests only ensure that the quality of the feature or scenario has been met. The Development Team will want to make sure that the person requesting the feature (the Product Owner) is happy with its design, function, and usability. The Sprint Review meeting should not be the first time that the Product Owner sees a feature being demonstrated.
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.
Note The Product Owner feedback loop should be as short (fast) as possible as well. This is another argument for collocating him or her near the Development Team.
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.
The rest of this chapter will discuss some of the more effective collaboration practices and tools.