Archive for the ‘Scrum/Agile Roles’ Category

Nine Questions to Assess Team Structure

Tuesday, March 9th, 2010

It is perhaps a myth, but an enduring one, that people and their pets resemble one another. The same has been said of products and the teams that build them. If it is true that a product reflects the structure of the team that built it, then an important decision for any Scrum project is how to organize individuals into teams. This paper presents a set of guidelines to consider in designing an appropriate team structure. Each guideline is presented in the form of a question to be asked of a current or proposed team. The questions are intended to be asked iteratively. Ask each question of a current or proposed team, changing the structure as appropriate based on the answer. As the structure changes, re-ask the questions until you can answer “yes” to each.

  1. Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members? People don’t enjoy being on a team where they are not able to make use of their strengths or are constantly required to do things they are bad at. Good team members are willing to do whatever is necessary for the success of the project, but that doesn’t relieve us from the goal of trying to find a team structure that accentuates the strengths of as many team members as possible.
  2. Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)? A well-conceived team structure for an organization that is not attempting to do too many concurrent projects will reduce multitasking to a tolerable level. If more than 20% of all team members belong to more than one team, consider an alternative team design or deferring some projects.
  3. Does the structure maximize the amount of time that teams will remain together?
    If other factors are equal, you should favor a design that allows team membership to persist over a longer period. It takes time for individuals to learn to work well together. Amortize the cost of that learning over a longer period by trying to leave teams together as long as possible.
  4. Are component teams used only in limited and easily justifiable cases? Most teams should be created around the end-to-end delivery of working features. In some cases, it is acceptable to have a component team developing reusable user interface components, providing access to a database, or similar functionality. But these should be exceptions.
  5. Will you be able to feed most teams with two pizzas? Given the compelling productivity and quality advantages of small teams, the majority of teams in a good design should have five to nine members.
  6. Does the structure minimize the number of communication paths between teams? A poor team structure design will result in a seemingly infinite number of communication paths between teams. Teams will find themselves unable to complete any work without coordinating first with too many other teams. Some inter-team coordination will always be required. But, if a team that wants to add a new field on a form is required to coordinate that effort with three other teams, as I’ve seen, then the communication overhead is too high.
  7. Does the structure encourage teams to communicate who wouldn’t otherwise do so? Some teams will just naturally communicate with each other. An effective team design encourages communication among teams or individuals who should communicate but may not do so on their own accord. In fact, one valid reason to put someone on two teams is that doing so will increase the communication between those teams. If lack of communication between two teams is a concern, splitting a person’s time between those two teams is easily justified.
  8. Does the design support a clear understanding of accountability? A well-designed team structure will reinforce the concept of a shared, all-teams accountability for the overall success of the project while providing each team with clear indicators of their unique accountabilities.
  9. Did team members have input into the design of the team? During the early stages of your transition to Scrum, this may not be possible. Individuals may not yet have enough experience delivering working, tested, ready-to-use products by the end of each sprint. Similarly, some individuals may be initially too resistant to Scrum to contribute to team structure discussions in constructive ways. In these cases, it is acceptable for managers outside the team to design an initial team structure.

    10. An effective team structure is one of the most critical factors in the success of any agile endeavor. Poorly structured teams will lead to inefficient teamwork, excessive integration challenges, multitasking, low morale and other problems. By using these nine questions to carefully consider how teams are organized you can avoid these problems.

Posted in Scrum/Agile Roles | 5 Comments »

Distributed Teams: Build Trust through Early Progress

Monday, February 22nd, 2010

Critical to creating a coherent team is building trust among team members. This is much more difficult on a distributed team. Unable to rely on repeated, frequent face-to-face communication, distributed teams need to take other measures to build trust. Traveling ambassadors, starting meetings with casual conversations, occasional in-person meetings of the full team, working agreements, and similar activities all help. What also helps is early pressure for the team to produce working software by the end of each sprint, even the earliest ones.

Unfortunately, many projects schedule too much time for teambuilding exercises and discussions too early in the project. This is a common and dangerous mistake, as shown by research from Professor Lynda Gratton and her coauthors, as published in the MIT Sloan Management Review.

Guiding these diverse teams to success requires some counterintuitive management practices. In particular, team leaders should focus on tasks at the early stages, rather than on interpersonal relationships, and then switch to relationship building when the time is right. (Gratton, Voigt, and Erickson. “Bridging faultlines in diverse teams.” MIT Sloan Management Review, Summer 2007, 22–29.)

Though this research suggests that the early focus should be on tasks, I do not mean to suggest that product owners or ScrumMasters should be assigning tasks to developers. Rather, I mean that these leaders should emphasize the need for the team to make demonstrable progress even in the early sprints. The problem with an early emphasis on relationship building is that it encourages less-than-ideal subgroups to form. Any large group will inevitably split into subgroups. If these subgroups are allowed to form too early they will form around surface-level attributes—Americans, Swedes, C++ programmers, Java programmers, female database engineers, male programmers, and so on. As Gratton and her coauthors write, “Simply put, in a team’s early going, the more people interact with one another, the more likely they are to make snap judgments and to emphasize their differences” (26).

What we’d like to do is defer relationship building until team members have learned more significant things about each other, such as specific skills, competencies, approaches to work, and so on. This is done through early emphasis on progress rather than relationship building. The subgroups that form at that time will be based on the mutual need to work together to develop the product. To develop a particular user story from the product backlog, you and I need to work together. In doing so we learn each other’s skills and specific competencies. I come to know you not just as a Java programmer but as a Java programmer with a real passion and strength for automated unit testing. You find that I am not just a DBA, but one who is strong at optimizing SQL statements.

Teams with subgroups formed around compatible skills, attitudes, approaches to work, and so on are less likely to lead to a later breakdown in trust than subgroups formed on superficial attributes (such as American, Swede, programmer, tester, and so on). Think back to one or more troubled teams you were a member of. Odds are that conflict on those teams was of an us-versus-them nature based on superficial attributes: this office versus that office, programmer versus DBA, Linux fanatics versus Windows fanatics. When teams feel an immediate need to make progress, those types of subgroups do not have time to form.

After a team has worked together for a few sprints, shift the emphasis toward relationship building by incorporating more social activities and shared downtime into the sprints. A team needs to have a sufficient amount of shared experience before social activities and relationship building can be useful. But when that has been achieved, “instilling confidence in the team and creating opportunities to socialize at that point helps the development of new abilities and allows the team to grow” (29).

I want to be clear that I am not saying that no time for socialization should be included at the start of a project. Seeding visits and whole-team, in-person get-togethers at the start of a project for its initial release planning can be very useful. Three points are key here:

  • First, the project should start with intensity and a focus on early demonstrations of progress.
  • Second, the entire “budget” for socialization should not be spent in the first couple of sprints.
  • Third, early social activities should tie into the work of the project, such as bringing a team together for release planning.

Posted in Scaling Scrum/Agile, Scrum/Agile Roles | 10 Comments »

Removing Team Members

Tuesday, January 26th, 2010

People often ask me whether teams should have the right to vote members off the team. To help answer that question, let me share a story with you.

When I saw Derek walking toward me at the conference, I was thrilled. I had first met him a year earlier when I taught a class at his company. I had been back a handful of times, and I always enjoyed talking to him, but we hadn’t talked in three months. I thought this would be a good chance to catch up. As we said hello, I could tell something was really bothering him, so we sat down to talk. Derek told me that at his team’s sprint review the week before, the team had decided to ask him to resign as their ScrumMaster and to leave the team. He had done so and was looking around within his company to find another Scrum team to join. But the shock of being asked to leave had not yet worn off.

Although rare, Derek’s situation is not unheard of. The question of whether the team has the authority to remove someone from the team is a common topic. Commonly referred to as “voting someone off the island,” removing a team member is not an action to be considered lightly. Before such measures are taken, efforts should be made to address problems that lead some or all team members to feel that they might be better off without one of their members.

A team alone should not have the right to remove someone from the team. As I detail in Chapter 12 of Succeeding with Agile, self-organization does not occur in a vacuum. The right preconditions must be in place for self-organization to occur. Individuals then self-organize within boundaries established by the organization. This is referred to as the CDE model, which says that for self-organization to occur there must be a container that bounds the individuals, some differences among them, and transforming exchanges.

Chapter 12 also makes the point that leaders within the organization exert influence on the self-organizing team by adjusting its containers, differences, and exchanges. For example, over time and through attrition a team might have become too homogeneous. An astute product owner, functional manager, or even ScrumMaster might counter that by adding two new team members with radically different backgrounds, skills, decision-making styles, or so on. Doesn’t it seem possible—likely even, in this example—that a team might have a knee-jerk reaction and vote the new, nonconforming individuals off the team, negating the work of the leader who deliberately added them? Ultimate authority for team composition, therefore, must reside with the leadership of the organization. Those leaders should listen, of course, when team members say they think they’d be more productive without a member. But, team members should not be allowed on their own to remove someone from the team.

Posted in Scrum/Agile Roles | 18 Comments »

The Role of Leaders on a Self-Organizing Team

Thursday, January 7th, 2010

Self-organization is a fundamental concept in agile software development. The Agile Manifesto includes the principle, “The best architectures, requirements, and designs emerge from self-organizing teams.” Yet a common misconception is that because of this reliance on self-organizing teams, there is little or no role for leaders of agile teams. Nothing could be further from the truth. In The Biology of Business, Philip Anderson refutes this mistaken assumption.

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.

Self-organizing teams are not free from management control. Management chooses for them what product to build or often chooses who will work on their project, but they are nonetheless self-organizing. Neither are they free from influence. Early references to Scrum were clear about this. In “The New New Product Development Game” from 1986, Takeuchi and Nonaka write that “subtle control is also consistent with the self-organizing character of project teams.”

A Scrum team’s job is to self-organize around the challenges, and within the boundaries and constraints, put in place by management. Management’s job is to come up with appropriate challenges and remove impediments to self-organization. That being said, the fewer constraints or controls put on a team, the better. If leaders overly constrain how a team solves the challenge given to it, self-organization will not occur. The team will shut down; because it has already been told so much about the challenge and how to solve it, it will wait to hear the rest. So how does an agile leader achieve the subtle balance between command and influence?

Suppose you are a ScrumMaster for a team. You’ve noticed that one team member, Jeff, is domineering and no one is willing to stand up to him. This team has self-organized—it has chosen to let Jeff make all key decisions. As the ScrumMaster for this team, though, you recognize that if Jeff continues to make all the decisions on his own it will impede the team’s efforts to improve. You consider having a private conversation with Jeff, but that is unlikely to change much. You contemplate stepping in and overruling some decisions he makes, but if you do it once the team will expect you to continue to do so, which won’t be good.

Then you begin thinking about subtle control and influence. Perhaps you decide to change the team’s dynamics by asking management to add someone new to the team, someone who is likely to stand up to Jeff. Or maybe you suggest to the enterprise architecture team that someone from its group attend key meetings—someone with the experience and background to challenge Jeff. No matter the specific problem, if you see that the team has self-organized in a way that impedes it, it is your responsibility to find a way to agitate, stir up, or otherwise disturb the status quo, so that the team adjusts, hopefully reorganizing in a more productive way.

There is more to leading a self-organizing team than buying pizza and getting out of the way. Leaders influence teams in subtle and indirect ways. It is impossible for a leader to accurately predict how a team will respond to a change, whether that change is a different team composition, new standards of performance, a vicarious selection system, or so on. Leaders do not have all the answers. What they do have is the ability to agitate teams (and the organization itself) toward becoming more agile.

For more details on how leaders can help teams and their organizations grow more agile, see Chapter 12 of Succeeding with Agile.

Posted in Scrum/Agile Roles | 19 Comments »

The Fallacy of “One Throat to Choke”

Thursday, December 10th, 2009

In speaking with some agile teams and consultants I occasionally hear two statements that I strongly disagree with. These statements are that “the product owner is the single wringable neck on the project” or that the “product owner is the one throat to choke.” These each mean the same thing, that the product owner is the person ultimately responsible for the success of the project.

This is wrong, however. On an agile project—as well as in many other cases—there is no single, wringable neck. To say there is a way of releasing the rest of the team from responsibility. And this is clearly wrong.
From a manager’s perspective it can be nice to always be able to point to one person and say, “That’s who I’ll blame if things go wrong.” But the “one throat to choke” argument is false. Historically, there may be one person who takes the blame for things when they go wrong, but that doesn’t mean that person was responsible for the failure.

Take the case of a sports team. At the start of a new season, who on a sports team do we say we’ll hold responsible for winning the championship? The coach? The owner? The star player? Teams that win championships find a way to win games, no matter the circumstances. If the game plan isn’t working, the coach and players adapt. If the star player is having a bad day, someone else steps up. The whole team feels responsible for winning somehow, some way. If the team loses, it may be tempting to blame one person or another, but the team knows that each one of them is accountable for the loss. It’s never just one person’s fault. In reality, there is no single, wringable neck.

Consider a nonsports analogy. If both parents were involved in raising a child (and assuming one of them isn’t abusive or obviously negligent), which parent is the one throat to choke if a child grows up to be a convicted felon? There is a reason we call it a parental unit. Raising a child is a team effort.

The only way to ever create an environment of shared ownership and responsibility is to let go of the notion of having one throat to choke. That doesn’t mean no one is responsible. That means that on a successful team, the team members must do their part, or even go beyond a perceived role, to ensure that the team reaches its goals.

For more on whole-team responsibility, see Succeeding with Agile.

Posted in Scrum/Agile Roles | 73 Comments »

The Benefits of Feature Teams

Monday, December 7th, 2009

When I first began to consult for a certain California-based game studio, its teams were organized around the specific elements and objects that would exist in the video game it was developing. There was a separate team for each character. There were weapons teams, a vehicle team, and so on. This led to problems, such as weapons too weak to kill the monsters, colors too dark to show secret passages, and obstacles that frustrated even the most patient player.

On more traditional, corporate projects, we see equivalent problems when teams organize around the layers of an application, including

  • Reduced communication across the layers
  • A feeling that design by contract is sufficient
  • Ending sprints without a potentially shippable product increment

If structuring teams around the layers of an architecture is the wrong approach, what’s better? Rather than organizing around components, each team on a project can ideally be responsible for end-to-end delivery of working (tested) features. There are many advantages to organizing multiteam projects into feature teams:

  • Feature teams are better able to evaluate the impact of design decisions. At the end of a sprint, a feature team will have built end-to-end functionality, traversing all levels of the technology stack of the application. This maximizes members’ learning about the product design decisions they made (Do users like the functionality as developed?) and about technical design decisions (How well did this implementation approach work for us?)
  • Feature teams reduce waste created by hand-offs. Handing work from one group or individual to another is wasteful. In the case of a component team, there is the risk that too much or too little functionality will have been developed, that the wrong functionality has been developed, that some of the functionality is no longer needed, and so on.
  • It ensures that the right people are talking. Because a feature team includes all skills needed to go from idea to running, tested feature, it ensures that the individuals with those skills communicate at least daily.
  • Component teams create risk to the schedule. The work of a component team is valuable only after it has been integrated into the product by a feature team. The effort to integrate the component team’s work must be estimated by the feature team, whether it will occur in the same sprint during which it is developed (as is best) or in a later sprint. Estimating this type of effort is difficult because it requires the feature team to estimate the integration work without knowing the quality of the component.
  • It keeps the focus on delivering features. It can be tempting for a team to fall back into its pre-Scrum habits. Organizing teams around the delivery of features, rather than around architectural elements or technologies, serves as a constant reminder of Scrum’s focus on delivering features in each sprint.

Of course, there will be occasions when creating a component team is still appropriate, for example when a new capability will be used by multiple teams or when the risk of multiple solutions being developed for the same problem is high. Overall, however, the vast majority of teams on a large project should be feature teams.

Additional advice on feature and component teams can be found in Chapter 10, “Team Structure,” of Succeeding with Agile.

Posted in Scrum/Agile Roles, Sprinting | 19 Comments »

Ssssh….Agile Is All About Micromanaging

Sunday, September 13th, 2009

Sometimes when I’m teaching a Certified ScrumMaster class, I let the attendees in on the deep, dark secret of agile: It’s all about micromanagement. Almost every principle and practice of agile is there to support micromangagement.

  • The daily scrum is about micro-managing the team’s daily work plans and making sure that everyone is doing what they say they’ll do.
  • Continuous integration is put in place so that the minute some developer screws up and breaks a build, it becomes known.
  • Pair programming is about making sure that programmers don’t lose focus, don’t goldplate, don’t work on only the fun stuff, and that they clean things up.

Ah, but who is it that is doing this micromanagement?

It’s the team.

Yes, agile is about micromanagment, but it’s about the team micromanaging themselves and for their own benefit.

Posted in Scrum/Agile Roles, Transitioning to Agile | 33 Comments »

A ScrumMaster Removing an Impediment at Apple

Friday, January 16th, 2009

As you probably know, Steve Jobs of Apple announced yesterday that he’s taking a six-month leave of absence. His health has gotten worse and hopefully he’s able to recover fully during this period.

As a Mac user, I’ve been paying a bit of extra attention today (and over the past few weeks) to what shakeups might be in store at Apple during Jobs’ absence. I read this today and want to share it as a great example of a ScrumMaster removing an impediment. It’s about Tim Cook, Apple’s current COO, who is likely to replace Jobs:

Tim Cook arrived at Apple (AAPL, Fortune 500) in 1998 from Compaq Computer. He was a 16-year computer-industry veteran – he’d worked for IBM (IBM, Fortune 500) for 12 of those years – with a mandate to clean up the atrocious state of Apple’s manufacturing, distribution, and supply apparatus. One day back then, he convened a meeting with his team, and the discussion turned to a particular problem in Asia.

“This is really bad,” Cook told the group. “Someone should be in China driving this.” Thirty minutes into that meeting Cook looked at Sabih Khan, a key operations executive, and abruptly asked, without a trace of emotion, “Why are you still here?”

Khan, who remains one of Cook’s top lieutenants to this day, immediately stood up, drove to San Francisco International Airport, and, without a change of clothes, booked a flight to China with no return date.

Khan sounds like a perfect ScrumMaster to me. He heard about the impediment and within thirty minutes was on a plane to resolve the problem.

Let’s hope, Steve Jobs’ doctors are able to remove all impediments in the way of his return to good health.

For the full article reference above, see http://money.cnn.com/2009/01/15/technology/cook_apple.fortune/index.htm

Posted in Scrum/Agile Roles | 5 Comments »

Do Products Owners Evolve As a Species?

Tuesday, January 1st, 2008

I recently read an article about how fire ants have evolved such that some ant colonies now have two queens. This has helped fire ants spread and more densely populate certain regions of the United States. If a queen who insists on being the sole monarch is born into a densely populated area, she is likely out of luck. But, a queen fire ant with the genetic adaptation that allows her to share the colony will thrive in a densely ant-populated area.

This got me to wondering whether product owners evolve. The answer is, yes, of course they do.

Just as the fire ants have evolved in ways that allow them to better survive in their environments, I learned recently that product owners do the same. I was speaking with someone who works at one of my clients that I hadn’t visited for a few months. He told me that his product owners have suddenly stopped emphasizing high quality work and bug fixes.

They remain nominally agile–they work in short iterations, have ScrumMasters, pair program, have thousands of automated tests, dabble in test-driven development, and so on. But, product owners no longer treat quality as important.

They now push teams teams to go faster, faster, faster even if that means leaving bugs and sloppy code behind. It took my friend at this client a bit of thinking to figure out what was going on. But what he discovered was frightening.

One of the product owners came completely clean and explained it to him: In their organization there are many projects that compete for resources. When a project is funded it is approved for a certain number of sprints with a certain team or teams. Once those sprints are over the project can request more funding, but it’s likely that another project has already been lined up behind this one.

Being a very customer-foucsed company, this organization has instituted a policy common to many organizations: “Customer-reported quality issues are to fixed immediately.”

Pause and reflect on that for a moment. Suppose you are  a product owner. Your project is approved for a fixed number of sprints. You’d have really preferred more time for your project, but you understand why you only got what you were given. But, if there are quality issues found after your product goes live they will be treated as high priority items and fixed immediately. So, as a sneaky, devious product owner the best way to get more time for your product is to cut quality, cram in half working features and then get them fixed “for free” after you’re out of sprints.

What my friend had found is that his product owners had evolved in adaptation to their environment, just as the fire ants had evolved in adaptation to theirs. His unfortunate situation won’t change until some other environmental factor comes along that changes the motivation and incentives of the product owners.

Posted in Scrum/Agile Roles | 11 Comments »