What’s it all about, Agile?
You can’t go anywhere these days without hearing about Agile software development. My colleagues at small start-ups and even enterprises like Yahoo! and PayPal are experimenting with it. Everyone’s doing it, but is it right for you?
Before we answer that question, let’s talk about Agile and where it came from. Agile was developed by 17 prominent members of the software development community as a response to “waterfall” methods that they considered heavyweight. The team established a four-point manifesto to guide a more lightweight, iterative and interactive process:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Sounds good, doesn’t it? Does anyone really want to work on heavy documentation, planning cycles, etc.? Even the most Bell-shaped heads that I worked with at AT&T would tell you over a beer that they’d be happy to chuck it all if they could. And, everyone I worked with at any self-respecting start-up holds these values. But, you can’t shape your development process based on values alone.
Luckily the Agile Alliance developed a set of 12 principles that guide Agile development (kind of a 12-step program for converted waterfall developers). Here are some of the key principles and their implications:
Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
This is dramatically different from life in a waterfall team where the focus seems to be more on documentation than software, and nothing gets released until it’s “done”. Some firms do this intentionally, to ensure quality and reliability. For example, developing features at VeriSign seemed to be more focused on gates and artifacts than software, at a minimum:
- Product managers write Product Requirements Documents (PRDs);
- Engineers respond with Functional Specifications (FSDs); and
- The team develops and reviews a requirements repository that links the two documents together
Not a lot of fun, but when you’re securing data or providing domain name services, you’re just as focused on the customer’s needs, which is why you can’t “fix it on the fly”.
Welcome changing requirements even late in development…
The Agile Alliance has a *small* difference of opinion here with people like Barry Boehm who proposed the cost of change curve in Software Engineering Economics.
Boehm posited an exponentially increasing cost as development progressed. I’ve experienced it first hand even at start-ups like PeopleClick. Not only do changes slow delivery, they can also be inherently risky. Like continuous iteration, this could work for your business, but is dependent on its model.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information… is face-to-face conversation.
Yup, yup and yup. No matter what your organization size or length of development cycle, you need people to work together. And, the best way to do that is to give them responsibility and let them work things out in person.
Simplicity… is essential.
Every successful businessperson should know this and recite it as a mantra. It’s not a new philosophy — Oliver Wendell Holmes (d. 1894) said: “I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.”
At Plaxo, we regularly challenge our pages, flows and features to be as simple as they can be while meeting our business objectives. By simplifying our requirements, we get to market faster and enjoy fewer defects. Recently, we considered a new feature that required four unique flows with countless branches. We re-thought it and found a way to create a single, unified flow with no more than two decision points. It was a great win for the customer and the team.
Where does it all net out? Agile and waterfall lie on opposite ends of a continuum. And, depending on your business, you’re likely to find yourself somewhere in between the two.
You’ll end up more toward the Agile end if you’re a start-up with few customers and a small, dynamic team. As the business grows or its products become more mission-critical, you move toward waterfall. The key is finding the right balance.
Next week I’ll cover the role of the Customer in product development
