Tag Archives: Agile Software Development

Agile software development is an iterative, evolutionary practice based on a set of values that prize individuals and interactions, working software, customer collaboration, and responding to change.

The Day Oxygen Became Extreme

Posted on by

Extreme What? by Justin DonnellyAt the precipice of change, we are getting sentimental here at the Oh! Network.

As a developer joining Oxygen NY in 2001, I entered a code and fix culture under a facade of waterfall planning. I fought arbitrary dates, bloated specifications, and reality-challenged reporting. I acquired a survivalist’s skill for landing valuable projects and picking co-workers who helped carry them to completion.

As team lead, I made myself project manager. I used a risk-managed, iterative approach based on Steven McConnell’s Software Project Survival Guide and Earned Value Planning. We provided transparency, met dates and exceeding expectations.

Still, I had the awful, lonely feeling it was unsustainable. A tiny team, we were isolated from each other. We needed a collaborative practice. We needed to share knowledge, commit to a common way of working, and lift each other past our individual limitations.

I found the following e-mail thread capturing the moment we adopted Extreme Programming (XP). A bit of everyman’s history with a very small ‘h’…

From: Ken Judy
Sent: Tuesday, January 13, 2004 2:40 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: Agile Methodologies

Here are sites for different agile methodologies. Of the five of them, XP is the most exacting. The others are generally light frameworks for ways of developing or managing projects that support the agile manifesto http://agilemanifesto.org/.

XP: http://www.extremeprogramming.org/
Scrum: http://www.controlchaos.com/
Crystal: http://alistair.cockburn.us/crystal/crystal.html
Adaptive Software Development: http://www.jimhighsmith.com/
Feature Driven Dev: http://www.featuredrivendevelopment.com/

— Ken

From: Luke Melia
Sent: Wednesday, January 14, 2004 5:09 PM
To: Ken Judy; Kristofor Selden
Cc: Keith Frank
Subject: RE: teamwork

Hi Ken,

Kris and I spent some time today reviewing the agile process frameworks you sent around and met this afternoon to discuss our planning. We’re going to follow the XP rules and practices for the most part.

http://www.extremeprogramming.org/rules.html

We will likely invest somewhat more effort in up-front detailed requirements in order to support your work-package tracking efforts. In addition, some practices are irrelevant for a team consisting of a single pair of developers. We’ll ignore those and pay close attention to the practice “Fix XP when it breaks” in order to arrive at a set of practices that is effective for us. I’ve read the criticisms of XP that argue it is “all or nothing” but I feel that this approach will work for us.

We’re going to be pair programming and plan to work together 11am – 1pm and 2:30 – 5pm. This will allow us time at the beginning, middle & end of the day to respond to email, etc.

This is all going to start this Friday. On Friday, we’ll do a code review, go over the task breakdown for the SES project and plan for our first milestone, as you suggested. I’m also going to rearrange my desk to make it work better for two people to sit at.

Luke

From: Ken Judy
Sent: Wednesday, January 14, 2004 5:31 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: RE: teamwork

Sounds good. Our team is so small that a strong agile approach should work well as long as we manage risks. I’ll look into the “Tracker” role in the XP model to see how to adjust my tools to your approach.

— Ken

From: Ken Judy
Sent: Thursday, January 15, 2004 10:33 AM
To: Luke Melia; Kristofor Selden
Subject: RE: teamwork

Hi,

Please go ahead and block out 11:00am-1pm and 2:30-5pm in your calendars as “busy”. I’ll send out an e-mail to IS all so they know what’s up. Feel free to decline any meeting requests at your discretion and let me know of anything in your calendars you need me to cover for you on.

We will need to start the morning “standup” meetings so that we keep focus on the project and one of the things we’ll need to address is how to best use Michele as owner.

— Ken

Affect vs. Effect

Posted on by

I have to admit to some confusion over the verb forms of affect and effect. The free dictionary has this helpful note:

Affect and effect have no senses in common. As a verb affect is most commonly used in the sense of “to influence” (how smoking affects health). Effect means “to bring about or execute”: layoffs designed to effect savings. Thus the sentence These measures may affect savings could imply that the measures may reduce savings that have already been realized, whereas These measures may effect savings implies that the measures will cause new savings to come about.

So an agilist should effect positive change not affect it and affect impediments not effect them.

Worship the Plan: Part 2

Posted on by

This is what unrealistic planning does to execution.

Worship the Plan

Here’s the scenario:

Management adopts a project plan with unachievable goals given the time, features and resources.

The team begins in ignorance of “the plan”. Initial progress represents a sustainable pace.

Visible progress doesn’t match “the plan”. Management pressures the team. Short term, the red line gets steeper.

At this point, management revises the plan adjusting the start but retaining aggressive assumptions. “Now we know what we’re doing!”

Problem is, the productivity gain is not sustainable. The team is working extra hours and skipping necessary work to declare things done.

Problem is, the productivity gain is not real. Under stress the team works to increase the measure of value instead of value itself.

So productivity stalls. The team catches up on sleep, settles into the slog, and confronts thorny problems created by messy, incomplete and untested code.

Ultimately, the team produces less than had it maintained a sustainable pace.

Assuming the people and codebase aren’t hopeless, I added a period before the end where the team returns to sustainable pace. These are the tragic days when management gives up and before they cancel.

Another scenario – similar chart:

Management adopts a business plan with unachievable goals.

The product owner becomes risk averse or fool hearty, ignoring real opportunities that won’t hit impossible numbers.

The product drifts or lurches in bizarre directions and declines.

The Opposite of Agile

Posted on by

NYC settle a lawsuit to compensate poor families for food stamps they were denied by mistake beginning in 1999…

…as many as 34,000 families could have been affected, with the settlement ranging from $8 million to $71 million depending on how many people were involved. The city has said that it corrected the computer problem several years ago — NY Times

  • Make mistake effecting food for poor families.
  • Correct mistake approx. 5 years later.
  • Acknowledge mistake 8 years later.
  • Blame others but retain liability.

WNYC story