Software Sweatshop

Thanks for messing me up Rich... no really, as if I don't have enough problems already... I've got like 8 parking tickets to deal with (written by a vindictive little bicycle cop at that!) But I digress...

So agile development has always been interesting to me but extreme programming never fit my fancy. I knew nothing about it, but the word "extreme" made it sound impractical and unattainable, until I attended a talk by Rich Sheridan of Menlo Innovations (check out Agile Explained) here in Chicago a week ago. It was really good.

In fact it was so good that I sent him this email a few days ago:

Rich,

After your presentation last week I went to another agile (scrum)seminar and spoke to other people about agile (mostly scrum).

I have to say, none of it sounded as cool as the stuff you spoke about. User stories sounds much cooler than "backlogs", one week iterations sounds much better than 30 day sprints, and pair programming is probably one of the coolest programming concepts I've ever heard of. In all, XP sounds more fun, easier to use, and more intuitive.

Scrum seems more popular when working with distributed/offshore resources, so my team will probably end up using scrum, but by planting the seeds of XP, you really messed me up in the head!

Best,

Raza

to which he replied:

Its one of the free services I happily provide! If you really want to get messed up, though, I'll have the charge you for that!

Good luck!

All in a day's work I guess...

We're switching our offshore development team to an agile methodology and I'm now taking this thing really seriously. We'll probably do scrum and adopt principles of XP like pair programming (for more read here) Anyways, if you're starting to work with an offshore development company, you should insist that they follow an agile development method if you want working software.

Here are my notes from Rich's talk:

 

• Most development teams have critical info tied up in one guy. You have to keep him very happy, or else you're in big trouble. The lesson to be learned is that lone geniuses and primadonnas leave you very vulnerable.

• At his old company, they did an agile experiment. They decided to put all the programmers in one room and let them actually talk to each other, it worked great. They knew they were on to something...

• One day, their client (IBM) walked through and liked their setup... said it was the most amazing thing they'd ever seen

• Rich was influenced by Edison (hence the name Menlo Innovations) who said you oculd have minor inventions every 2 weeks and a major one every 6 months. Verrry inteeeresting... (if you're interested in innovation, check out Triz Innovation... he said there are 40 principles of innovation which can be applied to ANY situation to solve problems... amazing stuff)

• Collaboration needs to happen because when one guy does the same role, the conversation only happens in his own head and he starts making rogue and dangerous decisions himself

• Traditional project management is like a neutron bomb, it'll only kill the people... managing risk logs, work breakdown structures, burndown charts, etc. looks pretty, but it hides real problems

• So they discovered a proces where there were no meetings, but tons of communication, lots of communication but little email, a 40 hour work week with no weekends and defying Brooks law that throwing more developers at a problem slows it down. No cubes, offices, rooms, or doors, but developers were happier.

• Pairing is the most powerful tool they've ever had. Skills don't matter as much as collaboration and asking questions. Goal for new hires is to get their partner hired. Airlines pair pilots... Lorie Williams at the University of North Carolina did an experiment and found that the paired team produced 15% less lines of code with much better quality

• Because of agile development, they have no customer support emergencies.

• Experts don't work on what they're experts in, they just sit nearby and chime in. This is incredibly effective

• Estimating project work is extremely accurate. Each user story has an actual and estimated time. They keep track over the course of many projects to get an idea of how accurate their estimates are. Over time they can give pretty reliable estimates on software projects

• Clients have to take an "agile explained" class and agree to meet once a week. Committment is the main factor. This process won't work for projects where people are complacent and not invested in the process. (

• Testing is not a task, it's an ongoing activity and is build into an estimate

• Developers are NEVER be punished for missing an estimate... ever.

After the talk I asked Rich how to apply agile development principles to distributed or offshore development teams. A few years ago they had two interns from Ireland. After they went back to Ireland they continued to work for Menlo as consultants. Funny thing is that even though they were half a world away, they were paired with programmers at Menlo headquarters in Ann Arbor, Michigan. How cool is that?

A lot of this stuff is just common sense. Seems to me that no matter which flavor of agile development you choose, you'll have a lot better project outcomes.