The #1 thing I see is the feedback loop. The most successful apps, the ones that are downloaded the most, constantly have reviews that say “the developer listened to me and got back to me.” Even for the apps that have growing pains (adapting to new hardware, adapting to OS updates or adding new features) the customers are forgiving if they feel part of the process, part of the loop. Otherwise excellent apps are downgraded if the developer, for whatever reason, chooses not to respond to customers.

I am a prime example. I have worked with a small development shop with an app that worked on my original Droid, but died on my Droid X. I am pretty sure the developers couldn’t afford to get a Droid X, so they used me as their test lab. They were very responsive, very involved and I never felt abandoned. This feedback loop kept me from dumping their app and looking for an alternative.

The #2 thing that I see in the most successful apps is a continuous stream of releases. Bug fixes, corrections for different hardware, new features, even small tweaks are part of a steady stream of updates. And the best developers go out of their way to acknowledge that the changes are driven by their customers.

There are a number of other interesting attributes of successful apps that I could add, but these are the main factors that strike me as revolutionary in terms of software developed for the consumer market.

Whether by choice or by the desires of the market, the Android marketplace has adopted many of the practices found in the Agile movement. I would venture that with the proliferation of these devices, the way customers interact with, and the expectations they have from, software developers in markets of all sizes and shapes are going to fundamentally change. A new relationship is being forged between the customer and the developer. I think this new relationship will be a primary factor in deciding who wins and who loses going forward.

Here at RadBlue, we live Agile, breath, Agile and see its benefits daily.

Welcome to the new world.

But getting there is a serious challenge. We have five kids, one van and at least 17 hours on the road. So there is a great deal of planning that is done up-front. We plot out where to get gas, what rest stops to hit, what snacks to bring and where to find the first Chick-Fil-A once we cross into Tennessee. The goal is to have no surprises; to know exactly what we are doing.

And that is how we used to build software as well.

Not too long ago, we would sit down at the start of a project and write down everything we were going to do. We would plot out the bugs we were going to fix, the features we were going to add and how much time each step would take. We would spend weeks or months creating documents and charts filled with details. The final schedule would be meticulous in detail and brimming with confidence.

And then the van would crash into a ditch just outside of Indianapolis.

I’ll get into the hows and whys of that particular phenomenon in another blog, but first, I wanted to touch on how we do scheduling at RadBlue.

At the start of each development cycle, we have a short list of issues that we want to tackle. All of these issues relate to our goal of making our products better for our customers.

Then, we get in the car and start driving.

Going into a development cycle, we know that the journey is never going to be a straight shot. In fact, we know we aren’t going to get to the original destination. Our customers are great at voicing their opinions – on both the current products and on sneak previews of the work in-progress. And all of that input helps steer the car.

Our development process is a fluid one. We are constantly revising the schedule and feature set based on the latest information. Sometimes the input changes our direction by a few degrees. And sometimes the input completely changes our direction. Sometimes we head toward Disneyland, but end up at Disney World.

For a small, agile company like us, this is the best possible way to respond to the needs of our customers. It allows us to focus on what is needed and deliver it in a timely manner.

It’s probably the worst possible way to pilot a family to the ocean. But it’s a great way to build software.