Why use agile methods? You've already heard enough about how agile allows software development organizations to do more with less. In this column, Michele Sliger offers a completely different reason—one that's often overlooked but nevertheless critical.
You should consider adopting agile because it is the ethical option. This is not to say that non-agile methods are unethical, nor is it to say that all agile teams are working ethically. Instead this ethical choice is about embracing a method that is value-driven—both in the promise of providing value to the customers and in the promise of the ways we choose to work together to provide that value.
The Merriam-Webster definition of ethics is "the discipline dealing with what is good and bad, and with moral duty and obligation." If we examine our moral obligation as software developers, our first task is to provide value to our customers. That is why we were hired, and that is what the customers are paying for. We have a responsibility to deliver. Agile approaches provide a framework that enables frequent delivery of precisely what the customer needs with as little waste as possible.
While we are obligated as professionals to provide a valued product to our customers, it should not be at the expense of those doing the work (or those supporting the people doing the work). Our second obligation is to treat the team humanely. If we do not create and maintain an environment that allows the team to do challenging and fulfilling work at a sustainable pace, then we are failing to treat these knowledge workers with respect. This also affects our first duty in that an overworked, demoralized team may not be able to give its best effort at creating a valued and quality product. Review the Agile Manifesto and its twelve principles to see the set of values that drive behavior in a positive and sustainable fashion.
In addition to the Agile Manifesto, two of the most popular agile approaches, Extreme Programming (XP) and Scrum, advocate specific values. (Again, this is not to say that other software development approaches do not have values—just that XP and Scrum explicitly spell them out.) Ken Schwaber identified the following five Scrum values in his book Agile Software Development with Scrum: commitment, focus, openness, respect, and courage. Kent Beck identified these five XP values in his book Extreme Programming Explained: communication, simplicity, feedback, courage, and respect. While many trainers focus on the practices to get new agile teams up and running, it is the values that will keep the team truly agile long after the trainers and coaches leave.
Commitment: It's not enough to be assigned to a team and agree to try this new agile thing, and it's not enough simply to be dedicated. One must also be committed to doing whatever is necessary to meet the goals outlined and to take the authority to do so to heart. It means "to carry into action deliberately" (Merriam-Webster) or, as Yoda says, "Do, or do not. There is no try."
Focus: Don't get sidetracked. Remember what you committed to do, and focus your energies on fulfilling that promise. Distractions are not limited to the obvious things like email and unrelated meetings. They may also be things like creating documentation because "we've always done it that way" instead of creating documentation because it truly provides the customer with something of value.
Openness: Openness is about keeping the project status highly visible to everyone all the time. Anyone who is interested should be able to look at a wall, a wiki page, or a dashboard in an agile project management tool and see how many features have been completed, what's currently being worked on, and the goals of the iteration and release.Communication: People on the team must talk to each other. This gets harder to do the more geographically separated the team is, but with tools like Skype, teams can talk to one another easily and cheaply. The point is that team members must not rely on email and documentation alone. Verbal communication is required to clarify ideas, solve complex problems, answer questions quickly, and help team members coordinate work efforts.
Simplicity: Beck says the XP coach should ask the team, "What is the simplest thing that could possibly work?" Then they should do that thing. Because agile approaches develop code in increments each iteration, the thought is that it is better to develop something simple that may have to be expanded later if needed, rather than spend a large amount of time now developing a solution that's more complicated and may, in fact, not be necessary.
Feedback: As stated earlier, our number one obligation is to provide value to the customer. In order to do that, we must obtain frequent feedback from the customer or customer representative in order to make sure that the product we are building is meeting their expectations. And if it is not, we have the information we need now in order to make corrections. Beck extends this meaning of feedback to include feedback from the system itself in the form of unit, functional, and performance tests run frequently in each iteration.
Courage: In order to accept the authority and accountability for the delivery of the product, the team members all need courage. From the courage to make decisions to the courage to say no, this is a foundational value that gives rise to all the others.
Respect: Each team member must begin by agreeing that everyone deserves to be treated with respect. Many teams clarify this with working agreements that outline ways in which they choose to work together. And, as a result of working together to adhere to all the other values outlined here, team members grow to respect one another beyond their shared humanity to the ways each valued colleague contributes to the whole.
Adhering to a set of values that drive positive, collaborative behaviors and result in frequent software delivery helps us to work in an ethical manner. This is what agile is all about! Yes, agile also allows companies to decrease their time to market, increase quality, and eliminate waste in the process to provide a greater ROI to the organization. And you'll find plenty of articles about these benefits as well. But the realization of these benefits is not based just on the adoption of a set of practices; the value system must also be adopted if the approach is to work properly. So, as you consider adopting agile, also think about whether or not your organization's values match those of agile—and what you may want to do if they don't.
