Handling the people side of Agile software development

Articles about process, metrics, iterations and techniques are great, but Agile software development is more than that: Agile development involves a culture shift. That's something that isn't talked about enough and has significant impact on testing practices.

In this tip, let's look at why "going Agile" might not be as easy as it sounds, what some of the prerequisites are, and what you can do about it. First, I'd like to thank this tip's peer reviewers: Lanette Creamer, Markus Gaertner, Catherine Powell, Marisa Seal and Patrick Wilson Welsh.

The Agile problem

A week ago, I sat back, looking at my articles on Agile testing . Boy, was I proud. I'd covered how to compress testing to fit in an iteration, how to make smart use of automation and how to distinguish Agile testing from "excellent" traditional testing. Then, slowly, I came to an awareness that something was wrong. I had published three articles on Agile Software Development without talking about people.

Let's take another look at the Agile Manifesto , the document that defines Agile Software Development: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan


That is, while there is value in the items on the right, we value the items on the left more.

Yes, that's right. Three articles about process. Three articles about tools. Yes, the process and tools were designed to enable changing the plan, but it certainly wasn't explicit and there certainly wasn't much about engaging with the customer. While all of those things are good, the tools and process are supposed to serve and enable the team, not be it's master. Tools and process are the means, not the end. So let's talk about the hard stuff, the people side of Agile development, and why it matters.

Developing ideas, not manufacturing

Ever since Henry Ford made his first million, the American people have been in love with the assembly line. "Standardize the process, decrease variation and crank out widgets," goes the thinking in a stable, predictable and repeatable format. In fact, even before Henry Ford, old Frederick W. Taylor suggested that we separate the worker and the work, to make sure the process is done the same, every day, defined by a class of process engineers.

If we are truly developing the same thing day in and day out, there may be some benefit in standardizing the work. But intellectual property is different every time. Instead of separating the worker from the work, we need to engage the worker in the work to think actively about the work itself and continuously attempt to improve. To paraphrase author and poet Richard Bach, we must own our process, or else we shall ever be its victim.

Cross functional project teams

Consider the typical cubicle-bound "testing" team. The team is organized by specialty, not project and rolls from project to project, reporting to a single test manager. In what sense are they a team? The 'team' members work on different projects, compete directly with each other for raises, and never work together. Can you imagine a sports league with "teams" of pitchers, first basemen, shortstops, and so on, that are "loaned" to build temporary project teams to play games? That's preposterous. Agile software teams emphasize a project team. They may do this in a number of ways, from having a reorganization, to working in Amazon's Two Pizza Team structure, to just having a war room and focusing on the project team.

A cross-functional team should have all the capabilities it needs to get the work done. No waiting for a DBA to create a table, no waiting for an architect to approve the design. The bottleneck on the team will be the team members themselves.

Self organizing, Self directed work teams

If the bottleneck is a team member, then how about shifting the load off that team member? That might mean a business analyst tests, or a tester learns the build system or helps out with some queries. The point is the business gives the team a problem, and the team itself figures out the best way to solve it. Of course, the business can add requirements for what documentation to produce, or what audit steps to put in place, and the team can report right back on the cost of those new requirements.

This means that instead of 'appointed' leaders making decisions in a command and control fashion, leadership is emergent and consensus driven. Yes, I once had a manager tell me he could never get Bill and Bob to agree but you would be amazed what locking people in a room will do to help them decide.

So far, we're talking about changing the model, from prescribing what people are to do and making decisions for them, to one of enabling the team to decide for itself when to work, where to work, how to work, and if the customer is embedded in the team what to work on.

But how do you treat people?

That "individuals and interactions" bit in the manifesto is also the major value; if I had to reword it, it would be treat people as humans. Humans are inconsistent; we laugh, cry, and show emotion. We have good days and bad days, and we are not all the same. We also have temperament, something I have very aware of as a left handed person. Some people just plain prefer to do work differently. Some are chatty, more effective when they know the person they are working with well; Others connect through the actual doing of the work. Some take pride in following a process; others value a successful outcome. Some like constant feedback; others might just turn around and say "stop encouraging me and let me finish."

Traditional documentation and process driven software development has clear desire to remove the unpredictability from the process. What it fails to notice is that humans are unpredictable; thus traditional development robs the process of its humanity. As hard as it is to measure, this basic humanism is a large part of what it means to be Agile. Many of the teams talking about "going agile" would be well off to look carefully at how they treat people, and ask "would I want to be treated this way?"

CargoCult 'Agile'

So if a team adopted the artifacts of Agile development but missed the point, would that look like? It would certainly start out with a loud voice, declaring for the team that "We are going Agile." It would put people in boxes. It would tell them what the process should be on a meta-level. It would ask them to contribute as specialists, and it would still tell them what to work on, where to do it, when to do it, and how to do it.

There are many fake forms of Agile, but the one I'm writing about would continue to focus on process and tools at the expense of the individual. It might throw the word "iteration" around a lot, but it will still insist on a firm promise for a very long feature list to be completed in exactly nine months.

Dealing with fake Agile practices

Let's say just for argument's sake, that you know of an organization that wants to use Agile Practices without changing its fundamental culture. Well, I suppose that's possible . You might even see some modest improvements in team velocity and project success. But the deep stuff of Agile development doesn't come from adopting a process it comes in setting the team free to adopt the process it wants.

Once you recognize that you're dealing with an impostor, that command and control thinking still remains entrenched in your organization, there are several things you can do. You can try to push, inches at a time, in the direction of cross-functional teams and team autonomy. You can invite the friendly DBA, the available architect, and anyone else who "isn't on the team" to the daily standup. You can find the project manager who "gets it" and request to work for them. Likewise, you can look for the troubled project, the desperate project, the one where the project manager might actually be willing to implement the team's crazy plan to get the thing done by December 1st.

If your company is just starting to talk about "agiling up" it's software process, my advice is to forget about time-boxed iterations and test driven development. Oh yes, those are good things, and they can enable agile software development, but let's be very clear if the team isn't self-directed, cross-functional, respecting people, it's not Agile software development. It's ... something else.

Hold on to those ideals. Communicate about them clearly. Fight for them, leave no room for misunderstanding, and you might just make your little part of the software development world a better place.

I think that is noble, and worth fighting for.

About the author: Matt Heusser is a technical staff member of SocialText, which he joined in 2008 after 11 years of developing, testing and/or managing software projects. He teaches information systems courses at Calvin College and is the original lead organizer of the Great Lakes Software Excellence Conference, now in it's fourth year. He writes about the dynamics of testing and development on his blog,Creative Chaos.

Use cases for software requirements tutorial: Strengths, flaws, formats

The use case process is a popular requirements documentation format that can aid communication and also can facilitate testing as a by-product benefit. While extremely valuable, use cases do have weaknesses which often are not recognized and thus can lead to risky over-reliance.

Let's get on the same page about what a use case is. defined as "how an actor interacts with the system," a use case usually relates the actor to the user, but the actor could also be another system or a piece of hardware.

A use case is titled in terms of its goal, such as "Place an Order." Some business or temporal event trigger invokes the use case. For example, a business event might be that a customer is looking through items the seller has for sale and decides to purchase one. A temporal event might be that the customer has agreed to renew their order automatically on a given date each year.

The heart of the use case describes the interaction step-by-step from the perspective of the actor: the actor does this, and the system does that in response. Such concrete behavioral descriptions make it easier for the user and developer to have a common understanding of how the system will operate. Consequently, use cases can enable the developer to develop a system that works just the way the user expects!

What a delightful change this can be from the typically too common disappointing situation in which the developer designs dynamically -- i.e., guesses, usually without being aware of guessing -- how the system should function, only to discover afterward that it's not what the user wants. Because of use cases' success in reducing such discrepancies, they have become probably the most widely-used method of documenting requirements.

Narrative and one-column formats

The simplest use case format is a narrative, where each sentence is a separate user behavior or system response. For example, a narrative format use case for placing an order from the perspective of the customer placing the order might be:
Identify the customer in the database by Customer ID. System displays customer's identification information. For each item to be ordered, select the item from a menu of items for sale. For each item to be ordered, system displays the item's ID, description, and unit price. For each item to be ordered, indicate the quantity of the item ordered. For each item to be ordered, system calculates the extended price equals quantity times unit price. Indicate the order is complete. For the entire order, system calculates the total amount due equals sum of extended prices for all items ordered. Pay the total amount due.

Because the narrative format inherently can be hard to understand, use cases most commonly are documented in a "one-column" format, where each step is an individual numbered line. While in practice the amount of verbiage may differ and thereby obscure the one-line-per-step essence, the same use case in a one-column format would be:
- Identify the customer in the database by Customer ID.
- System displays customer's identification information.
- For each item to be ordered, select the item from a menu of items for sale.
- For each item to be ordered, system displays the item's ID, description, and unit - price.
- For each item to be ordered, indicate the quantity of the item ordered.
- For each item to be ordered, system calculates the extended price equals quantity - - times unit price.
- Indicate the order is complete.
- For the entire order, system calculates the total amount due equals sum of extended - prices for all items ordered.
- Pay the total amount due.

Since these nine steps would be the normal way the use case is executed, they often are called the "happy path" or "main path." Note, even though these nine steps seem evident and straightforward, it's possible someone else could have described a somewhat different set of happy path steps for this use case. There's not a single one-and-only way to characterize the steps inherent in a situation. I don't think most use case writers realize how significantly the depiction of use case steps can vary from writer to writer.

While these days, use cases' step-by-step descriptions from the user's perspective are assumed to be intuitively desirable for developers, that wasn't always the case. I've used the technique since long before Ivar Jacobson gave it the clumsy "use case" name; and I've got to tell you that back then traditional programmers were not at all comfortable working with specifications from the user's perspective.

Differentiating between Functional and Nonfunctional Requirements

Many of the difficulties encountered in defining requirements relate to the functional-nonfunctional distinction. As so often happens, some of those difficulties are things of which people are aware, largely realizing after-the-fact that nonfunctional requirements were missed. However, perhaps more, and certainly the more insidious difficulties, involve other issues of which people may not be aware and often may be incurring intentionally due to mistaken understandings.

Functional Requirements

Most requirements definition focuses mainly on functional requirements, which are based upon the expected functioning of the product or system to be created. Functioning, typically is equated with product/system features for which you might have a menu or button choice, such as: identify a customer, select an item to order, and calculate the amount due.

All things considered, requirements definers probably are best at identifying functional requirements, although they often overlook and get wrong more of the functional requirements than they ordinarily recognize. On hindsight reflection, they frequently do realize that many of the problems which surface later, and thus are harder and more expensive to fix, are attributable to inadequately addressed nonfunctional requirements.

Nonfunctional Requirements

Nonfunctional requirements refer to a whole slew (I've identified more than 30) of attributes including performance levels, security, and the various "ilities," such as usability, reliability, and availability. Invariably, requirements definers get wrapped up in how the product/system is expected to function and lose sight of these added elements.

When such factors are not addressed adequately, seemingly proper product/system functioning in fact fails to function. For example, a system may identify customers in such a slow, insecure, and difficult to use manner that it can cause mistakes which make data unreliable, provoke frustration-based attempted work-arounds that can create further problems, and ultimately lead to abandonment.

That's the recognized way in which nonfunctional requirements impact product/system success. Other often unrecognized issues also need to be appreciated.

"Nonfunctional" is misleading

First, I would encourage calling them "quality factors" or "quality attributes" rather than "nonfunctional requirements," which I believe is misleading. "Nonfunctional" implies they exist in the abstract or can be pigeon-holed, which can only lead to nonsensical questions such as, "How much usability do you need?" You don't need a bunch of usability. Rather, these requirements are relevant only with respect to functionality. For example, usability requirements pertain to particular usage situations; and a given product or system can have many different usability requirements—for each of the respective usage situations.

Also I'll caution against calling them a common alternative term, "quality requirements," which implies erroneously that these factors by themselves are what is meant by "quality." Instead, quality first and foremost comes from suitable functionality. Speed, ease of use, and the like contribute to quality if and only if associated with useful functionality.

Templates and checklists are helpful for remembering to find out about these factors but should not dictate the manner in which they are stored. That is, you shouldn't just have a group of usability requirements, a group of security requirements, and so on. Rather, all the relevant quality factors modifying a particular requirement should be captured with it.

Both Are Really Design

A second, far less recognized but very important issue with functional and nonfunctional requirements is that they actually are forms of high-level design pertaining to a product or system which is expected to be created. A tip off is that frequently they are called "specifications" instead of or in addition to "requirements." "Specification" is design.

Problems occur when the bulk of requirements definition is focused on specifying the product's functional and nonfunctional requirements, which is usually what happens. The product/system will provide value if and only if it actually satisfies the REAL, business requirements.

When most of the attention is directed toward the product/system presumed solution, there's too little understanding of what the product/system must accomplish to provide value; and what seems like a suitable product/system often turns out not to provide the value it should.

The key is first to discover the REAL, business requirements deliverable whats that provide value when met and then design a product/system how to satisfy the whats.