Innovations on an Agile Team

Here are some of the innovations I've seen on our team: (Every time I think for 5 minutes I find 5 more - I apologize to all of you who have contributed more that I haven't listed)

Production Accounting Test Fixtures
Large FIT testing (3x)
In Memory testing
GUI Cruise tests
Distributed Cruise
Condor Tests
Opteron Tests
Java/Ruby-Watir Gui tests
Toplink prebuilt expressions
Separation of Master tests
Toplink mapping of Views
Automatic Db Validation
Pluggable Java Royalties calculations
Single GUI Dtos
Self calculating allocations
MyTestSuite automated generation
Date Effective Snapshot
MultiRow Importer for Excel
Value Objects
Monthly Measurements
Homes
Balancers
Initializers
Allocation Visitors
Xml Beans
Profiler
Database Façade
Form Helpers
Warning Handlers
Automatic Error Handling & Display
HSSQL for database tests
1 click Db generation
Test Profiling
GUI Profiling
5 ideas
Strategic Pairing
Team/Spoc Planning
Team Pods
Bug fix race chart
Burn up/down chart
Bug categorization chart
Refactoring Criteria
Macker

Be proud.

Colin Cassie

A big thanks to Colin Cassie - our soon to be ex-project manager. He's on his way to retirement now, after giving a great boost to our project. His patience and experience were greatly appreciated by all. The way in which he allowed all those under him to work has made the project as great as it is.

The biggest lessons I've learned from Cassie (we all call him Caesar) is 1) to let those who work for you do what they do best, and 2) to stop those you work for from interfering with those who work for you.

Thanks Colin.

Individual Training

How do you get people up to speed really quickly on a project? We have 26 developers on our project 8 of whom are absolutely new. How do we train them?

We offered our people (new and old) a range of training opportunities.

• A couple of courses on the business
• A bunch of courses on the app
• Browsing Code Alone
• Fixing bugs Alone
• Pairing with a Newbie on a story
• Pairing with a Senior on a Story
• Pairing with a Senior on a refactoring
• Pairing with Newbie on bugs
• Working in a larger group to implement a story with Senior direction.

Which one got chosen? Well everyone had a different answer. Each chose a different combination. The best choice for training is to let the trainee tell you what they need.

Interestingly they all accepted the courses designed to describe the business and the implementations. There were 6 of them (1-2 hours each, 2/day).

Thanks to Colin Cassie for encouraging this direction.

Stupid Ideas that help me.

This is funny. Having forgot my wifes birthday once, I might sign up. Oddly appealing.

Thanks Jeff.

Get it in production...

Mostly when you're implementing a software system, you're replacing existing software. Be it a COBOL application, a pen and paper process, something people do on a calculator, or in a spreadsheet. Software usually isn't doing something new. Just replacing the old. This helps you prioritize.

Your goal is to be in production. Yesterday. On the first day of the project you should be PANICKING that you aren't in production yet. You're losing money everyday. Software in development has a present value of exactly $0.

This means really hard decisions when prioritizing stories. Here's some rules:

1) If you're rewriting a system - your new system shouldn't be able to do as much as your old system before going into production.

Your old system has a bunch of unused features. Ditch those. If you only use a feature in a couple of places, consider a work-around.

2) Your new system doesn't need to do anything new. Unless you're about to be sued, there are no risks in putting in a system that does exactly the same thing. And if you're about to be sued it has nothing to do with the software.

You're rewriting because the technology is outdated: meaning hard to update and buggy. See if the new system solves that problem first, before slapping all sorts of new features in it.

3) If you have a work-around OUTSIDE the system, keep it outside the system. You will lose almost nothing adding it to the system afterwards, if it holds up production - you're losing money.

4) Now look at what you've asked for. Find a way to just replace a piece of the system at a time. If you can break it into 3 or six months bits, you'll be a lot better off. Don't screw yourself.

Continue to panic about getting into production. If you ever stop panicking, you are screwed.

NOW YOU'RE IN PRODUCTION. You know a lot more.

You can evaluate whether or not you were successful in replacing your old system. Was it easier to get into production? Was it less buggy? Make your decision about whether or not to proceed.

WHEN you do go into production as a customer: INSIST INSIST INSIST that you see all the automated tests that cover the bugs you discover in acceptance testing. At least you won't have to worry about these during your next acceptance test.

If it's not less buggy and harder to get into production - decide whether to improve it or ditch it. Thank god you didn't waste a pile of money implementing all those new features.

NOW YOU'RE READY TO ADD A NEW FEATURE.

Start implementing the rest of the features. Make sure your next release is no more than six months away. Create as many of them as you can handle.

1) Implement all the things you are missing and everyone is bitching about.

Wow Feedback. Get it into production. If it's more than 6 months get it into multiple releases.

2) Implement your workarounds that you are currently using. You'll be solving real problems. Multiple frequency x average length of task. The higher the number the higher the priority.

Easy equation for prioritization. Only six months of features. No more. Get it into production.

3) Implement the new cool stuff.

You are now free to prioritize anyway you like, remember though you'll have some more of #2's popping up.

I won't lie, I won't lie, I won't lie, I won't lie, I won't lie, I won't lie

One of the problems with Agile is the fact that :

Everyone likes a fixed-price, fixed-scope contract.

Unfortunately, as pointed out by anyone worth their salt in our field:

THIS IS NOT POSSIBLE on any project of significant size.

(Martin Fowler, Eric Evans, Kent Beck, Ron Jeffries, Mary and Tom Poppendieck etc...). You can try and wrap the package up anyway you like...list of features, fixed number of stories, written specifications. It will defy all attempts to put scope and features in the same box. Our field has not matured enough yet. It will probably be at least a hundred years, yet.

The huge downfall of Agile, is that it constantly tells the user, "no, we're not on the fixed priced/fixed scope schedule, we're behind". Our profession is full of people willing to say I can do X for Y dollars. Generally, they believe they are telling the truth. They aren't. On some projects the customer doesn't find out until the end. Predicting a software project scope and schedule is like trying to know the speed and location of an electron: physicists have proved it impossible.

I never want to lie to my customer. I want my customer as informed as I am. I tell them each and every month where I am. If they're disappointed, that is unfortunate, but at least they have the truth. The decisions they have to make EVERY ITERATION about scope and time ARE HARD. If you don't want to make those decisions, leave it to me and I'll make the best ones I can.

I promise you a couple of things people who say we can do it on schedule and on budget won't: I'll show you every iteration how much we got working and I won't lie to you, ever - even when it's painful.

Remember your needs

Sometimes, things change in our life. Along the way we discover we need to make accomodation for new events, crisis, or on going things in our life. We are never the same person and we need to change our habits to accomodate these things.

How do we deal with this? The same way we deal with everything else. Try something. It may not work, it may require modification, but you'll learn something and probably come up with another better idea.

Even more important, is to communicate. Joe lost his dog a few weeks ago. It was painful and difficult for him to deal with. He discussed it with us and we were able to accomodate his needs.

Funny, the proudest moments of a leader are when they can accomodate someones needs. It means that what they do is about the people as well as the work.

Trout Fishing in America in Calgary

Trout Fishing in America

If you have kids who are between the ages of 4 and 10, you'll love these guys. They are funny for adults and kids. Make sure you go to the Childrens concert on September 25th (NOT the adult one on the 24th).

Sunday 09/25 2005

You can get tickets at:

(403)288-2616 - http://www.calgaryarea.ca/bulletin/view_bbb.asp?MessageID=8464&Community=ss - All profits to be donated to the Alberta Children's Hospital.

You can find some of their music on the trout fishing in america radio. Click on

http://www.k-ampplayer.com/kampplayers/run_kamp.php?cID=1c2c82dd3c0a3ab

Look for the songs "18 wheels on a big rig" and "mine". Lots of fun. Lots of energy.

Letter to Culligan

To Whom It May Concern,

Just thought you should know we have cancelled our service contract with Culligan. We signed up for the service where for $49 we would get a water cooler rental free and 4 water bottles to start.

We were assured that we would use three bottles a month for 22.95. Okay, sounds reasonable, as I've never used water bottles before.

We used two. We received three.

We used two. We received three. Kids are wondering why we need so much water.

We called and asked for two. Okay we were told. We received three. Kids are now walking around water bottles in our house.

We called and asked for two. No, we were told the contract says three. Great, that helps. We received three. Kids are now tripping over water bottles.

We called and said stop delivering water please. Apparently, now, we need to pay rent ($15) on the water cooler because we have no water. Right, what's in all these bottles? Kids agree it is water.

In fear of being forced out of the house by the ever accumulating water bottles, we called on August 30th and cancelled service. Cooler was picked up along with (full) bottles. Kids were relieved that we chose them over the water.

Received a bill Sept 1st for September rental of water cooler. I am unlikely to pay it. My account number is ...

Please, please, please deal with it.

Your perplexed, water logged ex-customer,

Ted O'Grady

Pushing the limits

We're hitting the limits of patience, and really interruptability. Our tests despite the in memory stuff are now 10 minutes. (5400 tests). They do lots of stuff.

One of our guys is implementing Grid unit. Fortunately, developers spend lots of time thinking leaving lots of spare CPU cycles lying around. Combined with a dual cored - dual Opteron box we expect our test time to go sub 1 minute.

Long tests have many bad impacts:
1) Long queues to check in (large team)
2) Disruption in thought process
3) Disruption in momentum

Thanks to Vlad, Zach and Alex and all the others that have provided different seeds on the team to thinking about how to speed up the tests.

Working with India

Going to be working with an Indian team on our project. Should be interesting. Need to figure out all sorts of stuff. Need to email Jane, get the in the trenches view of things. She is doing it with thoughtworks. If there is anyone who can figure this sort of stuff out and make it work, it is Jane.

How do we measure progress?

One of the things waterfall projects have over XP projects is Gantt charts. In the middle of the project they give your customer confidence that you are proceeding according to schedule. they put off the pain until the end when the charts need to be extended by testing and such.

In XP we can only tell them what we did. Customers want a measure that tells them you did as much this month as you did last month and how much is left and how long it will take. Velocity measures yesterdays weather. On other projects we have capped the budget, and report what we think the last story will be.

On this project we want to cap the time, complete a specified number of stories (2400), and budget is less of an issue. We don't do design up front - we do incremental requirements (stories). The last couple of sprints, our velcoity has decreased. In our estimation the stories have gotten bigger (have more pieces to them). What can we use to be honest with ourselves? Have our stories gotten bigger? Or has our code become more complex and we've slowed down? How do we measure this so we don't lie to ourselves? How do we measure this so we can explain to the customer?

Where do I sort?

Sometimes there are questions about where sorting should occur.

1) Should I sort in the database?
2) Should I sort in the business layer?
3) Should I sort in the display layer?

The time you need to sort - is when you need a sorted collection. You cannot rely on someone else having given you a collection in the correct order, thsi tends to make thing hard to understand and refactor.

For example, if you sort in the database - how does your display layer have any knowledge of how things are sorted? How does it know the sort order won't change? The safest thing to do is sort at the point where it is obvious you need to sort. Sometimes that will be in the business logic, other times in teh database, and other times in the display layer.

But, you say, I might create a performance problem if I sort too often!

Wait until it's a problem - it probably won't matter.

We are connected

I live in Calgary, Alberta, Canada. It's a city of a million people. I purchase my domain hosting from directnic. I used to have no idea where they were located. They have provided excellent service, and I have never needed to actually talk to them.

Now I know they are located in New Orleans. I hope they and their families have escaped the carnage and thank them for their service. The best thing I can do to help is be a patient customer. I will be there when they're ready. We're all connected.