Sg2009wc:agilemethod

From She's Geeky Wiki

Title: Agile Methodologies

Session: 4-I Bay Area Jan 2009

Convener:Desi McAdam (DevChix, Hashrocket)

Notes Taker:Melanie Archer (Two Banjos At Once)

Attendees:

Notes:

Contents 1 What Does Agile Mean? 2 Overview Of Agile 3 Core Principles Of Agile 4 Factors To Consider 5 Elements Of Working With Agile 6 Tools To Use With Agile 7 Potential Glitches With Agile 8 When Not To Use Agile 9 Certification 10 Resources 11 Takeaway

What Does Agile Mean?

• "Like punk rock:" different meanings for different people

• "We do Agile...sorta."

• There are "claims" to doing Agile, but the process really isn't implemented

• "Quasi-Agile" on distributed teams. There's the problem of "faux Agile" leading to chaos

Please note: there are varieties of Agile. Some projects aren't really using any of these, but instead are resorting to bad habits.

Overview Of Agile

• It's a methodology, and not the opposite of process

• There are flavors of Agile:

• Extreme Programming (XP)

• Scrum

• combinations of these. Hashrocket follows this.

Core Principles Of Agile

• Doing things iteratively. Cut out lead-up steps: things will change later anyway, so don't spend too much time on prep.

• Making things easier for the developers
• Use pair programming (more characteristic of XP Agile). Desi: "very popular" approach among female programmers, probably because of the social factor

• Pair programming also keeps developers out of "ratholes:" the dev can't obsess over one place in the code

• Pair programming helps knowledge transfer and mentoring.

• Pair programming enforces discipline-- more productivity results because devs don't want to let their pairs down.

• Pair programming will increase developer hours. However, it will reduce the time/cost on other elements, since the code will be better (fewer bugs, better organized)

• Pair programming reduces quirkiness in the code: "When you're there by yourself, you're more likely to do something hacky."

• Pairs are less likely to be interrupted by "outside" people than solo developers.

• Conduct daily stand-up meetings (more characteristic of Scrum Agile). These are very short meetings conducted standing up. Everybody reports what she or he is working on.

• Sustainable work pace.

Requiring a twelve-hour day of your developers is actually detrimental to your code. "Your people have to be happy."

• No or little design up front.

Agile is still new; this principle is up for revision.

Require your customers to provide wireframes; don't let them design on the fly. Ask them what the first valuable element of the project is. Don't try to build a two-year-long project all at once. Require the project stakeholders to identify chunks of work, or "stories."

• Continuous integration. Don't leave orphan pieces to configure later.

• Always deliver usable software.

Don't deliver prototypes. Get real user feedback immediately.

Factors To Consider

• Scope

• Budget

• Time

Only two of these factors can be of fixed quantities at the same time. Cf. "fast, cheap, or good."

An example was the development of Spot.us. The client had 18 months of work wireframed, but he had to decide what to cut to fit into a one- or two-month development cycle.

Elements Of Working With Agile

• Story

This is a chunk of work described. It might be the same as the use case, or the business value.

• Points

Each Story receives Points. This is not the same as how long the Story will take to develop, but how difficult it is

• the Icebox

Stories which are not scheduled for the current dev cycle go in the Icebox.

• Velocity

How much the developers can get done in a dev cycle. Based on how much was completed the previous iteration. Velocity will start slowly on a project, then increase as devs get to know each other, then plateau.

• Short development cycles. Release at the end of one- or two-week cycles, or the one-month cycle typical of Scrum. Start a new dev cycle after each release.

Tools To Use With Agile

• Pivotal Tracker, http://pivotallabs.com/

Project management application. Forces stakeholders and developers to identify priorities.

Also:

• Rally, http://www.rallydev.com/

• Mingle, http://studios.thoughtworks.com/

Potential Glitches With Agile

• No room for formal quality assurance. Stakeholders can act as informal testers during development.

• Doesn't work as well with distributed teams. For instance, conducting stand-up meetings are a lot harder. Pair programming is feasible with VNC, iChat screen sharing, and Skype. However, there might not be enough communication among team members to really use Agile.

• Doesn't work as well if people don't write good Stories.

Good Stories follow the "Invest" formula: Independent; Negotiable; Value; Estimable; Small; Testable. For example, "negotiable" means the Story is defined loosely enough that aspects of its implementation can be changed-- "users select city," not "users select city from dropdown menu." Stakeholders should put acceptance criteria in Stories. If these criteria change, they should form the basis of a new Story.

Good Story writing is something of a "black art." Learning it can be helped with training games.

• Developers must have access to all parts of the system for continuous integration.

When Not To Use Agile

On a widely distributed team, such as on open source development, because the process requires buy-in from everybody. Stakeholders need to understand that the process can't accommodate a certain delivery date, for example.

Certification

Desi- skeptical of value. Participating in one-day workshop doesn't replace experience. A good way to bring Agile to your company is to bring in an Agile coach. These people are listed on the Agile Alliance Web site, http://www.agilealliance.org/

Resources

Books:

• XP Explained

• Art of Agile Development

• Getting Things Done

Web:

• Agile Alliance Web site

• blogger Liz Keogh, http://lizkeogh.com/

Takeaway

"Build half a project, not a half-assed project."