Software Development the Agile WayBy Baselinemag | Posted 2008-01-30 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
Can a collaborative, flexible and focused method produce better software?
By Thomas Myer
By Thomas Myer
Imagine planning a trip to a
Kickoff day arrives, and you hit the road with lots of fanfare and excitement. Everything is peachy until you hit the
This whole scenario might sound crazy, but Agile experts use analogies just like it to explain what’s wrong with traditional, predictive waterfall methods of software development, in which real marketplace value is sacrificed for discreet planning and analysis about ultra specific deliverables—much of which is pure guesswork. The churn, stress and missed deadlines (not to mention budget overruns) make it difficult to attract and retain great talent.
Visualize software development as a continuum. On one end of the continuum are predictive methodologies, which strive to predict as much as possible about a project at the very start. On the other end are adaptive methodologies, including practices and tools that allow teams to adapt to change instead of predict it. That’s what Agile is all about.
“With Agile development, you flip the usual model by 90 degrees,” says Boris Portman, program chair of Agile Austin, an Austin, Texas-based education group that advocates the Agile development method. “Instead of the traditional phases, we think of requirement slices, each with their proper scope and priority.”
Several Agile methods exist, but each emphasizes requirements derived from the real world—some kind of time box that forces fast, iterative cycles, the flexibility to allow a team to adapt to market forces and face-to-face communication among those team members to share what they’ve done, what they still need to do and any obstacles that might impede future action.
If we were to plan our road trip along Agile lines, we’d come up with user stories to determine requirements, priorities and scope. “A user story usually follows the model: As a ‘blank,’ I would like to ‘blank’ so I can ‘blank,’” Portman says. This model creates a one-line requirement that is easy to understand and communicate to team members. As such, a user story for the
A project is usually composed of many user stories, but some projects may need only a few to get the ball rolling. These stories can be broken down into atomic tasks, each with its own priority, and then worked on by team members. For example, in our Vegas user story, the team gases up the car and makes sure everyone has money for the poker table. Then they hit the road, taking the biggest highway they can find. The group is also free to take advantage of unexpected opportunities. For example, a sharp-eyed member of the group might spot a billboard for a terrific casino with poker rooms at a nearby Native American reservation. It’s not Vegas, but the goal is to play poker and have fun, which makes alternate destinations more than acceptable.
That’s an example of focusing on value and the empowerment it can bring to teams. By shifting the focus to outcomes and letting the team self-organize, good things can happen that were never planned by the central committee.
“If an organization lacks the capability to design, plan and document everything up front, Agile can help get a project started by allowing those activities to occur over the life of the project,” says Rick Grashel, manager of software development at Initiate Systems, a Chicago-based maker of data management software.
While Agile has critics, many experts agree that enterprise software development efforts could greatly benefit from such common-sense software development approaches. Benefits include teams that know their objectives and hit targets consistently without having to pull weeks of overtime, and product owners with tangible results in a much shorter time frame.
That’s not to say pitfalls don’t exist. Critics charge that Agile lacks discipline, especially since little documentation is produced. Others say that the only good data on Agile’s usefulness centers around “project velocity,” but question whether there is a negative effect on quality or security to achieve that velocity. In practice, Agile’s common problems fall into three primary categories:
Upper management buy-in. Executives need to trust the self-organizing nature of the Agile process and shift their thinking to explain customer value instead of arbitrary metrics, such as deadlines and launch dates.
Software team discipline. Agile development isn’t a free pass. It also doesn’t mean “coding without documentation” or random assignments. You need stories (plans), tasks organized into a backlog (essentially a prioritized list of requirements tied to resources and deadlines) and daily, open participation among team members.
Plenty of communication. “Every single day, you need an open forum to hear about ideas and problems,” says Lance Ball, a software developer at New York city-based The Electric Sheep Company, which uses Agile to create add-on software for virtual worlds, such as Second Life.
What should executives and technical team members do if they want to explore Agile? Here are five steps.
1. Pick a small, meaningful project. It’s much better to tackle an entire project with Agile methodologies than to try to apply Agile approaches in a project governed by other processes.
2. Build a small team. Small teams communicate better than big teams, and Agile requires unfettered communication to succeed. “The perfect Agile team is seven to 10 developers,” says David Biggs, managing consultant of Catapult Systems, an Austin, Texas-based developer of Microsoft enterprise solutions.
3. Get customer buy-in. Let’s face it, we’ve all become used to long, drawn-out software releases with lots of delays and bugs. What Agile does is shift the playing field a bit—the releases are smaller (in other words, fewer features), but they come faster and impact the market more. “Agile’s all about adopting an iterative approach and getting your customers to buy into more frequent, much smaller releases,” says Colby Thames, president of
4. Build a solid backlog. Patrick Schramm, a certified Scrum Master who works at Austin-based Vignette, points out that the backlog of features is a record of all the objectives you want to meet. Without it, all you have is random development.
5. Change your attitude. Joel Greenberg, vice president of marketing innovations at The Electric Sheep Company, summarizes it best: “Agile works best for people and organizations willing to face reality.” You’re going to see daily problems, but you’ll also get to fix things daily.
By and large, most Agile methodologies are adaptive, but they work only within certain contexts. You must limit the size of the team, and you have to allow that team to self-organize and communicate daily. You also have to change your organization’s cultural
Thomas Myer is a consultant, developer and technical book author. His firm, Triple Dog Dare Media, builds open-source Web applications centered on content creation, management and distribution.