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?"
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 timeboxed 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 selfdirected, crossfunctional, 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 informaton 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.
This was first published in December 2009