Book Excerpt: Succeeding with Agile: Software Development Using Scrum

Scrum team members are used to seeing two new roles on their projects—the ScrumMaster and the product owner. But changes to a Scrum project’s team members go beyond the introduction of two new roles. For example, the self-organizing nature of a Scrum team eliminates the role of the technical team leader, individuals are asked to look beyond their specialty and help the team in any way possible, emphasis is shifted from writing about requirements to talking about them, and teams are required to produce something tangible by the end of each sprint. Because these changes alter the roles and relationships within the team and organization, they often contribute to some of the challenges organizations face when adopting Scrum.

 

This article will describe the primary adjustments individuals must make as they transition from traditional roles to Scrum. The focus will be on how these roles change, rather than on a thorough description of each role. I won’t, for example, describe everything a tester does as part of testing an application. I will instead focus on changes in how a tester works on a Scrum project. I will discuss the roles of analyst, project manager, architect, functional manager, programmer, database administrator, tester, and user experience designer.

While reading about these roles, keep in mind that any team member who is involved in developing a product or software system is first and foremost a developer. When I use a term like tester, I mean a developer with specific skills or an interest in testing. Similarly, analyst is used to refer to a developer who prefers to work on analysis tasks but who will work on any high-priority task needed by the team.

 

Analysts

With an intimate knowledge of the product and strong communication skills, some analysts will tend to shift into product owner roles. This is especially common on large projects that make use of a hierarchy of product owners. Someone with product manager on her business card, for example, may act as the chief product owner for the overall product, spending most of her time looking outward at users and the market. An individual with analyst on her business card, on the other hand, may act as product owner for the various teams, working with the chief product owner to translate her vision into product backlogs for her teams.

Many teams find that having an analyst on the team continues to be very beneficial, although the ways in which the analyst works will change. On traditionally managed projects, the analyst’s mission seemed to be to get as far ahead of the team as possible. On a Scrum project, just-in-time analysis becomes the goal. The analyst’s new aim is to stay as slightly ahead of the team as possible while still being able to provide useful information to the team about current and near-term features.

Analysts can be instrumental in achieving the goal of shifting the emphasis from writing about requirements to talking about them. Because analysts are not working as far ahead of the team as they may be used to, they need to become more comfortable sharing information with the team more informally, rather than through a large document. As much information as possible should be shared through verbal discussion, but analysts will still need to document some requirements especially when working on a distributed team. Often though, what the analyst writes will be less formal—more often a wiki than a document with a signature page.

On traditional projects, analysts often become intermediaries through whom other team members and the product owner communicate. On a Scrum project the analyst should become more a facilitator of team–product owner discussion than an intermediary. Team members and product owners need to talk. Rather than be the conduit for all conversation, the good agile analyst focuses on making sure those conversations are as productive as possible given the time constraints the team or product owner may be under. This may mean that the analyst steers the product owner and team toward talking about one user story rather than another because that is where there is more risk of going astray. Or it may mean that the analyst conveys a top-level understanding of a new feature to the team before bringing the team and product owner together to discuss the details.

On a traditional project, an analyst may say to the team, “I’ve talked to our key stakeholder, understand what he wants, and have written this document describing it in detail.” By contrast, on a Scrum project, the same analyst should say, “I’ve spoken to our product owner and have a feeling for what he’s after. I wrote these six user stories to give you a start, and I’ve got a bunch of additional questions to ask the product owner. But I want to make sure that I bring along a couple of you when we have those discussions.”

With all this talk of analysts looking ahead, it can be tempting to think that analysts work a sprint ahead of the team. They don’t. Gregory Topp, an analyst with Farm Credit Services of America, describes how using Scrum has allowed him to concentrate on the current sprint: “Before Scrum, I had to focus on requirements that were not going to be developed for several weeks, if not months. Now, I focus on the current sprint (two weeks for us), so more time can be spent on user story details, development, and testing.” An analyst’s first priority is to achieve the goals of the current sprint. An analyst on a Scrum team will assist in testing, will answer questions (or track down answers to questions) about features being developed, will participate fully in all regular sprint meetings, and so on.

However, it is quite possible that these activities will not fully consume the analyst’s time. Time that is not needed to complete the work of the current sprint can be used to look ahead. However, being a part of the team on this sprint and spending some time looking ahead is not the same as working a sprint ahead of the team. Topp explains how jumping too far ahead actually put him behind: “I tried working ahead a sprint or two, defining user story details. I found that this caused the current sprint to suffer. I also found that many times the details of a user story changed by the time the team actually started working on the story.”

A common question is whether the effort analysts spend looking ahead should be included on the sprint backlog. My recommendation is to include on the sprint backlog any specific analysis tasks that can be identified during sprint planning. For example, suppose the team is working on an application that approves or rejects loan applications. If the product owner and team agree that the next sprint will include work on calculating the applicant’s credit score, then preliminary analysis tasks related to that should be identified, estimated, and included in the sprint backlog. On the other hand, if the next sprint’s work is unknown, no specific tasks related to the next sprint should be included on the sprint backlog.

Overall, many analysts enjoy the change to Scrum even though they relinquish the role of sole interpreter of customer desires. Two years after adopting Scrum, Topp commented on how his relationship with others on the team had changed.

Because we are all on the same team and all work on the same user stories at the same time, the team seems to have more unity. Before using Scrum, it seemed each function (analyst, programmer, tester, DBA) was done in a silo. There was more fingerpointing when in that mode. Now using Scrum, the team is all focused on a small set of stories. The finger-pointing has been eliminated with an “as a team” mindset.

Project Managers

On a project using a sequential development process, the project manager has the difficult job of ensuring that the product a customer wants is the one that is developed. To do this, the project manager must try to manage everything about the project, including scope, cost, quality, personnel, communication, risk, procurement, and more. Some of these responsibilities really belong to others. Scope control, for example, rightfully belongs with the customer. No one else is in the position to make the necessary trade-off decisions that will arise during product development, as priorities, team velocity, and market conditions shift. Prioritization is not a static, one-time, all-at-the-start activity that can be managed by a project manager. Yet time and again, sequential projects demand that project managers make educated guesses to deliver the right product.

On Scrum projects we acknowledge the untenable role of the project manager and eliminate it. Eliminating the role, though, does not mean we can do away with the work and responsibilities. As you might guess, since self-organizing teams are a core tenet of Scrum, a great deal of the responsibility previously shouldered by the project manager is transferred to the Scrum team. For example, without a project manager to assign tasks to individuals, team members assume the responsibility of selecting tasks themselves. Other responsibilities shift to the ScrumMaster or product owner.

Former project managers often assume one of the roles that have taken on some part of their past responsibilities—the project manager becomes either a ScrumMaster, product owner, or team member, depending on experience, skills, knowledge, and interests.

Some people became project managers because they considered it the next step in a desirable career path, yet they don’t enjoy project management. These individuals miss the technical challenge of working as a programmer, tester, database engineer, designer, analyst, architect, or so on. Many of these individuals will take advantage of the elimination of the project manager role to return to work they found more satisfying.

Other project managers have used their roles to become knowledgeable about the business and its customer. A project manager in this situation will leverage that knowledge into a role as a product owner. This can be an excellent fit, especially for the project manager who is having a hard time completely relinquishing the ability to tell the team what to do. As part of their role, product owners are allowed to tell the team a bit of the “what to do” as long as they stay largely away from telling them how to do it. This can satisfy a former project manager whose nature makes it hard to stop occasionally directing the team.

If a project manager can overcome the old habits of directing the team and making decisions for it, it is likely such a project manager can become a good ScrumMaster. This is the most common new role for project managers in organizations adopting Scrum. The new role will likely be difficult at first for the former project manager as she learns to bite her tongue and let the team learn how to work through their own issues and make decisions. Often, new ScrumMasters are put in the challenging position of coaching teams at something that they are not yet good at themselves—being agile. The best strategies for a ScrumMaster in this situation include the following:

• Stick as close as possible to doing Scrum by the book. Initially follow the advice of this or another Scrum book closely. Or engage an on-site trainer or coach and follow her advice to the letter. Only begin customizing the process after you have real, hands-on experience with it.
• Talk to other ScrumMasters as much as possible. If there are multiple ScrumMasters in your organization, form a community of practice with the other ScrumMasters and share good and bad experiences. Look to learn by extracting lessons from commonalities among these experiences. If you are the only one in your organization, find outside ScrumMasters with whom you can share stories and compare approaches.
• learn as much as you can as quickly as you can. Read books, articles, blogs, and websites. Look into local agile interest groups and attend their meetings. Try to attend one or more of the major agile or Scrum conferences.

Doris Ford, a software engineering manager with Motorola, was a classically trained project manager and a Project Management Professional (PMP). However, despite having a traditional background in project management, Doris’s approach has always been about supporting and enabling her teams. Because of that, she was able to easily move from project manager to ScrumMaster. She writes of how her job has changed with Scrum.

Over the years in managing agile development I have learned not to sweat the task details. As a traditional project manager, I always needed to stay on top of who was doing which tasks, what were their dependencies, and would they be done on time. I spent countless number of hours just asking these questions to get the answers in attempt to meet the cope/schedule/budget/ quality constraints and reporting upwards on the progress (sometimes using earned value). In an agile environment I had to learn to trust the team members that they would identify and do the tasks necessary to complete the scope for each sprint. It was hard letting go at first, but I quickly learned that the team could do this. I now spend the majority of my time supporting the team members by addressing impediments that they raise and keeping external noise from diverting their focus.

Why the Title Change?

If it’s possible for a project manager to become a team’s ScrumMaster or product owner, why do we need to change the person’s title? Let’s consider the term ScrumMaster. Years ago, when I first started running Scrum projects, the term ScrumMaster didn’t exist, and it never dawned on me to call the role anything but project manager. This worked well enough. But, I was hiring new individuals into these roles; I was clear with these new hires about my expectations for how they’d interact with the team. I avoided domineering, command-and-control-style individuals. Also, these new project managers reported to me, which allowed me a lot of influence over how they interacted with their teams. Calling them project managers worked fine.

As our company continued to succeed and grow, we began to acquire other companies. In those companies I would inherit project managers who sometimes did have very traditional mindsets about the role of the project manager. I was confronted with helping them shift that mindset to one more compatible with agile development. I found this much harder than just hiring project managers with a collaborative approach suitable to self-organizing teams.

Years later in a discussion with Ken Schwaber, he helped me understand why transitioning existing project managers had been more difficult than I had anticipated. Schwaber informed me that by allowing the project managers to retain their titles, I was allowing them to think that the changes were less allencompassing than they were. He invented the word ScrumMaster in 1997 in part because it would remind everyone that this was not just the project manager role with a few additional responsibilities removed or added. Schwaber told me that “the vocabulary of Scrum is a vocabulary of change. The words are often intentionally ugly—burndown, backlog, ScrumMaster—because they remind us that change is occurring.”

Although I recommend it, you do not necessarily need to banish the title project manager. If you or your organization is enamored of it, continue to use it. But be mindful of Ken Schwaber’s advice and my experience that using the old words will slow or prevent the adoption of the new approach. Retaining an old title discourages thinking in the new way. Further, if people are unwilling to relinquish something as insignificant as a job title, they will probably also be unwilling to make the far harder changes necessary to adopt Scrum.

Architects

Many architects have worked for years to deserve the august title architect. They are rightfully proud of their knowledge, experience, and ability to propose elegant solutions to technical and business challenges. I find that many of the concerns raised by architects faced with adopting Scrum can be put into these two categories:

• Will people still implement the architectures I tell them to?
• How can I ensure we build an architecturally sound product without an up-front architecture phase?

The answer to the first of these concerns depends entirely on the architect in question. Many architects may find that very little about their job changes. Solutions recommended by these architects are implemented because other developers respect them and know their advice is likely to be good. For example, if one of my coworkers has a reputation for having made sound architectural decisions in the past, and I observe her making good architectural decisions on this project, I will be inclined to go to her with architectural questions. I’ll do that even if we’re a self-organizing team and no one is forcing me to get a second opinion on my decisions.

The second concern is largely unfounded. The architectural needs of a product are used in conjunction with business objectives to drive the prioritization of the product backlog. This allows an architect the ability to focus attention and effort on architectural uncertainties within the application. On an architecturally complicated or risky product, the architect will need to work closely with the product owner to educate the product owner about the architectural implications of items on the product backlog. All product owners are aware that they need to listen to the marketplace, users, or customers for input into product decisions. Good product owners also know to solicit the opinion of the technical team about the priorities. Although the ultimate decision is the product owner’s, good product owners consider all viewpoints when prioritizing work.

Andrew Johnston of AgileArchitect.org has written, “In an agile development the architect has the main responsibility to consider change and complexity while the other developers focus on the next delivery.” Judicious sequencing of work into sprints can help a team gain key knowledge sooner, avoid or discover risks with sufficient time to react, and minimize the total cost of development.

The Non-Coding Architect

Non-coding architects are likely to see the biggest shift in what they do. These are the ones that Scott Ambler calls “ivory tower architects.” The mere presence of a non-coding architect is a well-known harbinger of trouble; Scrum projects are well rid of them. Some non-coding architects will look on Scrum as a chance to again do some of the programming they hopefully enjoyed earlier in their careers. These architects will be welcome contributors to Scrum teams. They will be respected for the depth of their knowledge and experience and their ability to roll up their sleeves and get into the code.

Beware of the architect who resists a revised role that requires hands-on contributions to projects. In many cases these non-coding architects took their careers in that direction as a way to get out of hands-on programming. One such architect, Tom, confounded me when I first met him. He talked a good game and sounded knowledgeable about all the right technologies. However, he was the first developer I had ever met who enjoyed meetings. He was always looking to schedule more meetings. As I got to know Tom better, I realized that his technical knowledge was very superficial—he wasn’t as good as I had thought. I soon realized why he liked the team to spend so much time in meetings: in an unnecessary meeting all attendees are equally productive and valuable. It’s when team members return to their desks and start doing real work that the often dramatic differences between developers start to show up. Tom’s preference for unnecessary meetings was a self-preservation technique—the more time the team spent in meetings, the longer it would take everyone to realize that Tom wasn’t very good.

To be a valued contributor, someone with a business card reading architect does not need to code full-time. In fact, it’s quite possible for a sprint or two to pass without an architect writing any production code. The distinction I want to draw is between architects who can still code and those whose coding skills are behind them. Software architect Johannes Brodwall says that “the biggest changes to my role as an architect have been that, formally, the architect no longer has the power to dictate technical solutions. Instead, an architect has to be an advisor and a facilitator. As an advisor, I better still be able to do the job I’m giving advice about.”

Functional Managers

Functional managers, such as development managers, QA directors, and so on, who are used to working in a matrixed manner will continue to work that way on Scrum projects. A typical functional manager will likely experience some diminution in power after the transition, but this will depend greatly on how the role was defined in the organization prior to transitioning.

Functional managers usually retain the job of assigning individuals to projects. They will be expected to continue to make these decisions based on the competing needs of all projects, project locations, developmental needs and career aspirations of individuals, and so on. In some organizations, functional managers are accustomed to going beyond assigning individuals to projects and have been involved in the assignment of tasks to individuals within their groups. They will no longer do this after transitioning to Scrum. Individual selection of work is a fundamental aspect of how the members of a team self-organize and must be left to the team.

The leadership Role of the Functional Manager

Functional managers have always been leaders. Broad leadership trends over the years have affected individual style. While I was growing up, for example, my father managed Sears stores. This was back in the era when Sears was the world’s largest retailer. My father’s management style was very much top-down. He would establish goals, quotas, and other measurements; communicate them to store employees; and then measure each employee against those targets. This was also an era when prevailing wisdom was that a good manager could manage anything. My father should presumably have been able to take his experience managing a retail store and manage a bank or manufacturing operation with equal skill. My father was operating in the bottom-left quadrant of Figure 8.1, which is from The Toyota Way by Jeffrey Liker.

 

 

Different types of functional managers as determined by type of expertise and management style. Adapted from The Toyota Way, Jeffrey Liker, copyright The McGraw-Hill Companies, Inc.

A different type of manager, or perhaps one working in a different era than my father, might have applied her general management skills in a bottom-up manner. This manager would be in the top left of Figure 8.1. In the bottom right of that figure we see a manager with a deep understanding of the work and a topdown style. This manager—who is quite common on software projects—tells his team both what to do and how to do it.

In an organization using Scrum, functional managers should operate in the top-right quadrant, where they combine a deep understanding of the work with a bottom-up style. A functional manager is responsible for providing guidance and coaching to members of the group. ScrumMasters and product owners also provide guidance and coaching, but their views are limited to a single project or product. A functional manager will have a broader perspective, including the ability to establish cross-project standards and set expectations for quality, maintainability, reusability, and many of the other -ilities or nonfunctional requirements.

Functional managers also retain responsibility for developing the people in their groups. Securing the budget and time to send them to conferences, challenging them with appropriate projects, and encouraging them to join or form communities of practice are all part of the functional manager’s role.

Personnel Responsibilities

In most organizations, functional managers will retain responsibility for writing periodic reviews of the personnel in their departments. Although the functional manager has hopefully always incorporated input from each employee’s coworkers and customers into the review, the need to do so is greater in a Scrum environment because the employee will likely be working less closely with the functional manager on a day-to-day basis.

In many organizations, functional managers also retain responsibility for making hiring and firing decisions. Neither the ScrumMaster nor the product owner has this level of authority over individuals on the product development teams.

After the organization adopts Scrum, most functional managers find themselves with more time available than they had before. This time is most often used to stay in closer touch with their direct reports, to know more about each project the group’s employees are working on (by attending various sprint reviews and so on), and to pay more attention to cross-project standards and future directions.

Programmers

What do programmers do on a Scrum team? They program. They test. They analyze. They design. They do anything necessary to help the team complete the work committed to for a sprint. Although it is OK to have specialists on a Scrum team, specialists need to be willing to work outside their specialty whenever needed for the greater good of the team. There are exceptions. A game development project may, for example, benefit from specialists in artificial intelligence programming. Because of the highly specialized nature of their product, these specialists may do nothing outside their specialty. The majority of programmers on a Scrum team, however, should be willing to contribute in any number of ways to optimize the throughput of the overall team. This means they will test when necessary, sometimes program in a nonpreferred language, and so on.

One of the most striking changes for programmers on a Scrum team is that they can no longer sit in their cubicles and wait to be told exactly what to program. They need to become active participants in understanding product requirements. Surprisingly, there are many people who simply want to be told what to work on. I’ve heard this expressed as “if they tell me what to work on and I do it, then I can’t be fired.” Programmers on a Scrum team—like all others on the team—are expected to share in the responsibility for the overall success of the product. When this responsibility is fully felt, it is easier to do the things that go beyond one’s normal job description.

Programmers will also be expected to talk to customers and users. The amount of this can be adjusted up or down based on the programmer, the organization, the strengths of other team members, and the nature of the project. Programmers do not need to develop the personalities of gregarious, glad-handing salespeople. But they do need to be comfortable occasionally talking to a user or customer, even if it’s just over the phone.

Similarly, programmers can expect to spend more time interacting with their coworkers. A programmer may not be allowed to come in at 11 and clamp headphones on until quietly leaving at 7. Instead, programmers may be expected to sit in a group space, engage in discussions, help others with problems, and participate in pair programming.

These changes can be quite unsettling for the many programmers (including myself) who got into this field because we thought we could sit alone in our cubicles all day. Prior to my first programming job, I worked in a six-foot by four-foot totally enclosed dark room developing photos all day. I would pop out for regularly scheduled breaks and lunch; otherwise I was alone in the dark all day and loved it. Moving to the lighted world of cubicles was a big change. Moving from quiet cubicles to an energetic, talkative culture is an even bigger change. Programmers on a Scrum team will be expected to make this transition. Fortunately, though, the change isn’t that hard for most of us. We may like to be alone, but we find participating in structured conversations (as in the meetings and decision-making discussions on a Scrum project) much easier than unstructured conversations as at a cocktail party.

Beyond the communication and interaction changes, programmers will almost certainly experience changes in how they do their work. Technical practices such as pair programming, test-driven development, and a strong emphasis on automated unit testing will be new to them. The team may not choose to adopt all of these practices at first (or ever in some cases), but I suggest all be considered and tried.

Database Administrators

Data professionals, whether they go by the title of database administrators, database engineers, or something else, can be among the most resistant to adopting Scrum. Much of what the preceding section said about programmers will also be true about database administrators. Additionally, data professionals will be faced with learning how to do incrementally what has traditionally been viewed as a part of a project’s up-front work.

Standard advice in database design has been to do a complete analysis of the system’s needs, create a logical or conceptual database design, and then map the concepts to the constraints of a real-world database during physical database design. Success at this series of steps is predicated on a full and accurate analysis up front. The traditional data professional’s view was best summed up to me by a fellow traveler on a plane from Chicago to Sacramento. He was a vice president of database development for a relatively large healthcare company. His view on the world was “applications change; data is forever.”

This type of thinking leads to an intense focus on doing a complete analysis up front. This is nice in theory, but while we’re taking the time to do that complete analysis, the world is continuing to evolve. Users’ needs are changing. Competitors are releasing their products. Databases need to evolve to support the evolving applications built on them.

In many ways user experience design, architecture, and database design are all special cases of the same challenge: working incrementally on something that is thought about holistically. Much of a DBA’s day-to-day work will not change significantly, but how the DBA approaches and schedules that work will change dramatically and will be discussed in the “Work Together Throughout the Sprint” section of that chapter.

Testers

For years the common approach to testing has been based on Philip Crosby’s definition of quality: conformance to requirements. If quality is conformance to requirements, then those requirements better be written down. This has led many testers to an overzealous pursuit of a perfect requirements document against which they can confirm that the system conforms. However, as nice as conformance to requirements may be, conformance to users’ needs is even better. In using Scrum we acknowledge that it is impossible to perfectly predict all user needs.

Just as programmers can no longer say, “Hand me the perfect spec; then go away while I make the system do exactly what you requested,” testers cannot say, “Hand me the perfect requirements document and I’ll make sure the system does everything in it.” Each of these attitudes (and they’ve been prevalent ones in traditionally managed projects) leads to an abdication of responsibility. When statements like these are voiced, the programmer or tester who says them is relinquishing accountability for the ultimate success of the project. “Just tell me what to do and I’ll do it,” each is saying. Instead, each needs to be thinking about the product and asking questions about each feature and how it adds to (or detracts from) the overall product.

Because Scrum teams shift focus during requirements gathering from writing about requirements to talking about them, conversations with the product owner become the tester’s primary way of finding out how a new feature should behave. A tester is likely to talk with the product owner about how a feature should work, how quickly it should perform, what acceptance criteria must be passed, and so on. Testers are not limited to acquiring this information solely from the product owners. As appropriate, testers should also talk with users, customers, and other stakeholders.

As with programmers, working in such an interactive environment can be uncomfortable for testers who are transitioning to Scrum. Many testers, like their colleagues, entered software development with the expectation that they could sit in a cubicle with little human interaction on a daily basis. Not anymore. Testers on a Scrum team will need to become accustomed to more frequent and meaningful conversations with their coworkers and, in many cases, people outside the team.

Along with giving up on the myth that a perfect specification can be written in advance, one of the biggest changes facing testers is learning how to work iteratively. Conceptually this shouldn’t be a hard thing to do. If we think of each sprint as its own project, then the testing for each project/sprint is done within that sprint. It’s not as simple though as proclaiming that the last week of each sprint shall be reserved for testing. This doesn’t work and instead creates miniature waterfalls inside each sprint. During the first few sprints, testers will face an immense challenge. During that time the programmers are also learning how to work iteratively and probably won’t be good at it either. The team will probably overcommit to what can be done in a sprint, and the programmers will probably not have any of the planned features fully coded until very near the end of the sprint. So they will attempt to hand code to testers on the eighteenth day of a 20-day sprint. After individuals in these roles learn how to work in an agile manner, these eleventh-hour handoffs will disappear.

An increased emphasis on test automation becomes a hallmark of Scrum teams. Even teams that have struggled for years to make progress in automating tests find that the short sprints of Scrum make test automation a necessity. Over time this reduces the reliance on manual testers, those who read a script, push a button, and note the results. These testers often find themselves being asked to learn one or more of the test automation tools used by the team. While some test automation tools rely on what might as well be called programming to create the tests, not all do. I have met only a handful of manual testers who have been unable to transition to making significant contributions to their teams’ test automation efforts. On the other hand, I’ve met many who are afraid of this change. Time, practice, training, and pairing (including with a programmer) should be sufficient to overcome the fears.

Lisa Crispin, coauthor with Janet Gregory of the book Agile Testing, recalls that when she shifted to working on an agile team, the first thing she noticed was that she needed to be proactive.

Don’t sit and wait for things to come to you. Be proactive! We testers can’t wait for testing tasks to come to us. We have to get up and get involved and figure out what to do. Collaborating with programmers is new to a lot of testers. (Although it wasn’t to me, I always elbowed my way in at the start of every project no matter what our process was.) Collaborating with customers is also new to a lot of testers. It’s way out of the comfort zone for a lot of people. Programmers are busy people and kind of scary, sometimes. When I was the only tester on a team of eight programmers, even though most of them were guys I had worked with for years at another company, it took a lot of courage to ask for help.

If I work too closely with others on the team, I will develop ‘programmer eyes,’ causing me to see everything from their perspective, rather than from the viewpoint of a tester.”

It’s hard to see how working more closely with programmers will cause testers to lose so much perspective that they can no longer test the software. Database professionals have worked closely with programmers for years without becoming so contaminated. For decades, testers have advocated doing both white-box testing (in which they can see the internals of the system) and black-box testing (in which they cannot). If working with a programmer can lead to developing “programmer eyes,” it seems logical to believe that a tester who has done white-box testing would similarly lose perspective and not be able to do black-box testing. Fortunately, this isn’t the case.

Though many of the changes brought by Scrum will be uncomfortable at first, most testers will enjoy their new ways of working after getting used to them. Jyri Partanen is a QA manager with Sulake, developers of Habbo, a virtual world averaging over eight million unique visitors each month. Partanen describes the transition required of testers.

Testing is a profession where old habits tend to last. In the case of transitioning to agile, sticking to the old ways of doing things may lead to a half-hearted implementation of the spirit of agile. Usually the distress the testing engineers have is related to job security and the changes the upcoming agile transition may bring to their day-to-day tasks. This is, however, an unnecessary concern. Based on my own experience and the experience of others who actually have completed the transition to agile with QA personnel, I can say with confidence that the change has been without a doubt a smart move. Testing engineers in agile teams have more influence in the development process and, what’s even more important, on the end product.

User experience Designers

User Experience Designers (UEDs) often have a legitimate concern with adopting Scrum. Although they are accustomed to working iteratively, they prefer to run their iterations in advance of the rest of the project. On a Scrum project, however, we don’t want to do all of the UED work before beginning other development activities.

My favorite descriptions of how agile designers work have come out of Autodesk in Toronto. Lynn Miller and Desirée Sy have written about the approach they have used to integrate design into an agile process. I have worked on dozens of projects on which the teams and designers embraced their advice.

According to Miller and Sy, there should be two parallel tracks of work on the project: one for development and one for interaction design. Figure 8.2 depicts these two tracks and the interaction between them. The essential idea here is that UED work always precedes development work by at least one sprint. UEDs are given a headstart on the project through a combination of an initial sprint zero and a focus in sprint one on features with few or no user interface implications.

The approach shown here can work well but brings with it the risk that UEDs view themselves as a separate team. Lynn Miller sketched the first version of this diagram and agrees that it must not be interpreted to imply that there are separate teams.

Whenever I have taught this concept I have always stressed that the designers should not think of themselves as a separate team and that tight and frequent communication is essential to make the concept work. It has always been a failing of the diagram that it seems to suggest separation when that never was my intent.

 

 

It is essential that UEDs view themselves as part of the team. The idea of cross-functional teams is fundamental to Scrum; the team needs to include everyone necessary to go from idea to implementation. What would prevent a testing group from preparing its own version of Figure 8.2 showing parallel tracks of programming and testing sprints?

If I were to meet a UED in the hallway of your company and ask, “What do you do?” I might get a response like this: “I’m a user experience designer. I work one sprint in advance of the developers. My job is to make sure that when they start a sprint I can give them a design for what they’ll develop in that sprint.” This answer corresponds with Figure 8.2, but it’s not an answer I like. Instead I’d prefer to hear, “I’m a user experience designer. I’m on the development team, and my primary job is to make sure we finish whatever work we commit to for the sprint. But that doesn’t take up all my time, so I spend a good amount of it looking ahead at what we’re going to build in the next sprint or two. I then gather data, mock up designs, and do whatever I can so that when we start on a feature in a future sprint, we’re able to finish it in that sprint.”

Both of these fictitious quotes describe exactly the same work. In both cases the UEDs are working with the team during the sprint to resolve issues about that sprint, but they are also looking ahead. However, the two different answers present different mindsets about the work. First and foremost, I want UEDs to feel a part of the team and that their top priority is delivering whatever is committed for the current sprint. Beyond that, their job is to look ahead in exactly the same way everyone expects a product owner to be looking ahead at what competitors are doing, what users will want next, and so on.

I’m not alone in thinking that an agile mindset is critical for UEDs in making the transition to Scrum. Well-respected usability expert Jakob Nielsen concurs.

For user experience practitioners who support agile teams, the main change is in mindset. Having good, general user experience knowledge will help you understand how to change traditional design and evaluation methods to meet your agile team’s different focus. Ultimately, however, you must both believe in yourself and embrace agile development concepts if you want to succeed. If you’re prepared to change your practices and take on the responsibility, there are great opportunities to improve your effectiveness and your impact on the teams you support.

Three Common Themes

In this article we considered the changed roles of analysts, project managers, architects, functional managers, programmers, database administrators, testers, and user experience designers. In doing so, three major themes reasserted themselves:

• Work incrementally. Always strive to produce a potentially shippable product increment within the sprint.
• Work iteratively. Functionality can be revisited in subsequent sprints.
• Work beyond your specialty. To create something potentially shippable by the end of the sprint, individuals need to be willing to work outside their specialty occasionally.

As you go forward, you’ll find it helpful to keep these themes in mind as general heuristics about how individuals should work on a Scrum team.

About the Author

Mike Cohn is the founder of Mountain Goat Software (http://www.mountaingoatsoftware.com), where he teaches and coaches on Scrum and agile development. He is the author of Agile Estimating and Planning, User Stories Applied for Agile Software Development, and Succeeding with Agile: Software Development with Scrum. With more than 25 years of experience, Mike has previously been a technology executive in companies of various sizes, from startup to Fortune 40. A frequent magazine contributor and conference speaker, Mike is a founding member of the Scrum Alliance and the Agile Alliance. He can be reached through his website at http://www.mountaingoatsoftware.com.

 

POSTED BY Mike Cohn on Jan 12, 2010. FOR ORIGINAL ARTICLE, PLEASE VISIT: http://www.infoq.com/articles/cohn-chapter8