Agile Fact or Fiction: Team Structure and Human Factors

Agility is a subjective thing. For example, if you design your software before coding it, does that mean you’re not agile? You’ll find that everyone has a slightly different interpretation of agility, so for fun, we’ve provided a set of agile statements—some common viewpoints of what agility is or isn’t—and asked each of our co-authors to provide his viewpoint on whether each statement is fact or fiction.

There are two schools of management thought:

• Theory X: The average human being dislikes all work and will avoid it if possible. People must be coerced, offered inducements, and threatened with punishment to do work, and they need to be directed in all their activities.

• Theory Y: Work is as natural and as much fun as play. People have the capacity for self-management, and true motivation arises from intrinsic needs such as self-esteem, achievement, and learning. People, if allowed, will accept responsibility, and can be creative and team spirited.

Agility, in theory at least, promotes theory Y. But naturally, there’s more to it than that…

Being Agile Means Placing a Strong Emphasis on Human Factors

• Mark:   Human factors are vitally important in any multiperson, team-oriented endeavor. And anyone who says otherwise should immediately be shot, or at least sent on a management training course. Team communication is vital—no doubt about that—and all those things that Alistair Cockburn emphasizes in Agile Software Development are definitely worthy of serious note. I do think, however, that Alistair’s book could just as easily be targeted at, say, civil engineers instead of software engineers. And by this I mean that I don’t think there is anything particularly unique about the human-factors issues in software development as opposed to many other disciplines. The only potential caveat here is that software development often attracts more introverted personalities—and I’m not sure how much this is the case in other scientific or engineering disciplines.

• Matt:   Human factors such as placement of office furniture and being nice to your fellow programmer are important, but I don’t believe that they are a direct contributor to the core goal of agility, which is to reliably give the customer what he wants as quickly as possible. So, this idea is important but isn’t really to do with agility (even though human factors are central to much of the agile discussion that goes on “out there”).

• Doug:   Certainly a strong emphasis on human factors is a good thing. So if you define agility as “whatever is good,” then it would be a fact. But if you define agility as the ability to respond to changing requirements, then a strong emphasis on human factors is really somewhat orthogonal. So, I’ll say fiction.

Being Agile Means There Are No Role Divisions (Architect, Senior Developer) Within the Development Team—Everyone Is Equal

• Doug:   Fiction. Even if you take the titles away, people will still adopt roles. On the other hand, the divisions don’t need to be strict, and it’s certainly possible for one person to take on multiple roles.

• Mark:   This is a difficult one. I don’t think people should be obsessed with job titles (garbage collection executives notwithstanding), but I do think different people have different skills. In most cases, there would be little point in assigning a recent college graduate to the role of system architect, for instance, during an early design phase. But I don’t like overly hierarchical structures and am attracted to the idea of emergent roles. I’m a bit on the fence on this one.

• Matt:   Agile methods discourage specialization to an extent, but this tends to be specialization in terms of different areas of the product: Bob will work on module A; Sally will work on module B. So it’s a good thing that this is discouraged, and everyone gets greater exposure to different areas of the product. But specialization in terms of roles is a different matter. Even on agile projects, you’ll still find that one person is an architect, another person is a sysadmin, someone else specializes in SQL and DBA activities, and so on.

Being Agile Means the Team Must “Collectively Own” the Code Base (with No Room for Specialization)

• Mark:   Fiction—on balance. Having one person be the only one who can work on a particular area of code is never really a good idea; it makes the project vulnerable to that person leaving. On the other hand, there is a cost (in terms of lost development time) associated with everyone knowing everything—and different levels of skill and knowledge may make this impractical. The only advice I can give here is that you should distribute knowledge as much as possible across the team, given the constraints facing the project. Always try to have at least two people involved in any area of specialization, rotating these people in and out when possible.

• Doug:   Fiction. Different people have different experiences and expertise. It’s silly not to take advantage of this. The “everybody knows everything about everything” philosophy doesn’t work. A friend of mine once poetically expressed this in an e-mail: “So, it’s okay if a proctologist does brain surgery, then?”^[6.]

• Matt:   Fiction. A general “atmosphere” of collective ownership isn’t such a bad thing. Specialization, where one person “owns” and is responsible for a single part of the system, has some major drawbacks, not least of which is what happens when that person gets run over by a bus. A slightly less dramatic drawback is where one person ends up on the critical path because she’s the only one who knows how her part of the system works. In other words, specialization can (and frequently does) create bottlenecks in the project plan.

  But specialization also has its advantages. The main one (from what I’ve seen in almost every project I’ve worked on) is that people who are given responsibility for a subsystem take greater pride in their work. Specialization also prevents the annoying situation where a junior coder leaps in and “fixes” some code for you and forgets to tell you, resulting in a system that gets released with surprise bugs in it. So, fostering a general atmosphere of collective ownership, where it’s mostly okay to make careful changes in other people’s code (as long as you tell them), but where individuals retain responsibility for specific subsystems, is the way to go. So rather than collective ownership, let’s call it “responsible ownership” and “collective responsibility.”

Being Agile Means Your Entire Team Must Program in Pairs for All Production Code

• Matt:   Fiction. If your team members all enjoy pair programming, then why not? But not all programmers do enjoy it. I was called by an employment agency recently, and (before I could tell her I’m happy in my job, naturally!) the agent described an “agile” role available, but she complained that she was having great difficulty finding programmers who are prepared to pair program. It just isn’t popular (at least not in the UK, it seems). So you need to keep in mind that mandating constant pair programming could seriously limit the field of software developers available to you. Any process that requires constant pair programming should be regarded with great caution.

• Doug:   Fiction. Constant mandatory pair programming is problematic for reasons we explored at length in Extreme Programming Refactored: The Case Against XP, although voluntary pair programming as appropriate is certainly fine. However, pair programming makes a poor substitute for doing a good job at design.

• Mark:   Fiction. Some pairing up during both design and development is a good idea, but it is not mandatory by any means for a project to be agile.

Being Agile Means There Is No Need for Testers—the Developers Can Test the System Themselves

• Doug:   Fiction. It’s a great thing to have programmers unit testing and regression testing their code, but this is an entirely different activity and involves a different mind-set from having independent QA folks who are actively trying to break the code.

• Matt:   Programmers are paid to create, whereas QA testers are paid to destroy. If a programmer finds a bug, that’s a minus point, but if a tester finds a bug, she gets a gold star. So if programmers are doing their own QA, there’s a serious conflict of interest.

• Mark:   Fiction, on any sizeable project at least. While it’s important that all developers take responsibility for testing their own software to some degree, my experience is that they won’t find all the bugs. The last thing I want when running a project is to leave it to the customer to find all the bugs, so on any sizeable project I’d recommend some degree of nondeveloper testing.

Being Agile Means You Can Get Top Results with Mediocre Developers

• Doug:   Fiction. Of course most teams will contain some developers of average or mediocre skill. So your odds of success will generally be in proportion to the average skill level across your team. I don’t think “agile or not” really changes this equation very much.

• Matt:   A common maxim among managers in the know is, “The best methodology is simply to hire top developers and let them get on with it.” This is absolutely true. Why wouldn’t you want to hire the top people in any field? Ranging from top-notch prospect down to the basement, most clueless developer, would you want a developer who is, say, 10% clueless? 50%? Someone who doesn’t know what he’s doing inevitably creates more work: bad designs that need to be refactored, bugs, misleading code, and so on. Or he may take several weeks to do something that a real programmer could do in a day. Applying any methodology, agile or otherwise, doesn’t change this basic fact.

• Mark:   Fiction. If you’re responsible for a project, probably the single most important decision you will make is selecting the right people for the project, in terms of raw ability, knowledge of the relevant technologies, general project experience and, most important, willingness to work effectively as part of a team.

Being Agile Means You Can Work Only with Top Developers

• Doug:   Fiction. Although the higher your percentage of top developers, agile or not, the greater your chances of success.

• Mark:   Fiction, in that you can adopt agile practices regardless of the ability of your team, the only caveat being that the team members must be willing to adopt the practices. But you can’t get away from the fact that the better the people on the team—in terms of the criteria mentioned in the last question—the better the results you will get.

• Matt:   Fiction. You could probably get away with not hiring clued-up developers; the economics might just work out in your favor. But by definition, the top developers will do a better job.

Being Agile Means There Is Never a Role for Analysts

• Mark:   Fiction, as I’ve already said, although with the caveat that I prefer developer analysts.

• Doug:   Fiction. I’ll refer the reader to the discussions in our example project for details.

• Matt:   Fiction. Pretty much any project will benefit from having someone skilled in the art of extracting the correct requirements from the customer and end users. Programmers (me included, I suspect) will code something that we think is cool, believing that we’re giving the customer what he wants, but an analyst will make sure that what we’re creating exactly addresses the customer’s business requirements.

Being Agile Means You Must Work in a Single Office with a Good Seating Arrangement and Lots of Whiteboards

• Mark:   Fact, in the sense that working across multiple sites will definitely decrease your agility, and that a good seating arrangement (so the team members can talk to each other without leaving their desks) and lots of whiteboards for discussions or for important information will significantly improve your agility.

• Doug:   Fiction—not to say that these are necessarily bad things. Personally, I still think there’s a place for private offices where you can get quiet time to sit and think. But to build seating arrangements into your software process is pretty risky business. Many projects get done with distributed teams in multiple locations (again, see the example in this book). This practice, in conjunction with an overreliance on oral communication and a full-time on-site customer, to the exclusion of written requirements and UML models that can be e-mailed around (for example), can contribute to a process that’s fragile rather than agile. If it works out that you can set up your project in a single location and all of your team members like working in a shared space, that’s great. But it’s a risky thing to bet your project’s success on how the furniture is arranged.

• Matt:   Fiction. Working within a single office is good if your team is small enough. But your process shouldn’t stipulate this. Some people like to work from home, and there’s no reason they shouldn’t. Many programmers simply prefer peace and solitude in which to program. If they’re forced to work in a noisy cattle-pen environment, they’ll likely disappear behind headphones so they can get some work done. Personally, I think that the office arrangement has no bearing on the goals of agility; it just helps or hinders productivity, an important but separate issue.

  Having lots of whiteboard space is a good thing, but I have found that if one group leaps up and starts discussing a design issue, sketching away wildly at the whiteboard like it’s a Rolf Harris convention, that can be quite disruptive to other programmers in the same room. So it pays to have a separate room for team design workshops and to encourage the habit of darting out there often to draw on the whiteboard and talk away.

  Of course, this raises the question, when are the decisions communicated back to the rest of the team? The answer is partly in the question: the decisions are communicated back to the team (e.g., at the following morning’s team update meeting), not the hour of discussion and/or unproductive argument that led up to each decision.

^[6.]Chuck Suscheck, private e-mail to Doug Rosenberg, January 2004.