Saturday, February 13, 2010

4 Challenges and 5 Guiding values of Agile Software Development

Everyday Scripting with Ruby: For Teams, Testers, and YouAt Agile 2009, Brian Marick shared challenges and guiding values in agile software development. Brian1st covered 4 challenges that we face when starting with agile development:

1. Courage: ScrumMaster should have the courage to create an open workspace even if it is against company policy. There job is to move immovable objects for the good of the team. ScrumMaster, business analyst, programmers (learn new languages), testers (learn automation) all need courage.

2. Working software: Open workspace appears to the outsider as noisy, messy, undisciplined, uncontrolled, and unprofessional. They will have the urge to restore order. As ScrumMaster, you have to resist that and the best way is to deliver frequently working software that is better than what was delivered last week.

3. Naiveté: Pair programming, test driven design work. Do not prejudge before trying it out. Have an eagerness to believe in the ability of the absurd. Much of agile is deeply counter intuitive.

4. Slicewise Design: Always taught to 1st build infrastructure and then drop features on top of it. Problem is that infrastructure comes too late. By that time, client has become inpatient about not seeing working software. 2nd new feature come up that do not fit in the infrastructure. Instead build a feature and try to delight the client. If not delight then work on the little changes to satisfy the client and then move on to add another feature. As you go along, you will end up incrementally (refactoring) building the infrastructure with the features on top of it.

Next Brian covers 5 guiding values of agile software development:

1. Reactive: Agile teams value fast feedback, and visibility, but also value being reactive. We have always been taught to be proactive. When coding and later we discover a better way to doing things, we can back up and go in a better direction. However, using version control, we need to know when to take a snapshot to enable us to back up to the right spot. Another approach is to have smooth programming process where we can code forward towards a better path instead of backing. We need to become good at reacting to new knowledge that we did not proactively deal with. Each time we do that we improve our skills and increase our opportunity to learn.

2. Ease: Image hammering with a hammer that has a loose head. You will constantly be concentrating to make sure the head does not fall off instead of simple hammering away. Typical software has short cuts and workarounds. Agile teams clean up awkward code to make it easier for the next person. It is uncompensated near term work for a teammate’s medium or long term advantage.

3. Solidarity: We will all fail or succeed together. Foster solidarity with the platinum rule instead of the golden rule of do unto others as you would have them do unto you. The platinum rule says do unto others as they would have you do unto them.

4. Decency: React to irritation or difficulty by treating fellow with decency. Don’t be afraid to lose an argument. In agile it is not a threat to be wrong. You can always adjust back in the right direction.

5. Joy: “This is the greatest project I have ever worked on” is the reaction we should have when working on an agile project instead of “We suck less now”. You should have the courage to bend your work in a joyful direction.

Brian concludes that you should drive the environment instead of having the environment drive or limit you. You should seek to gradually add ease into your work and make it fun.

This presentation is available on InfoQ at