Lessons for Hyper-Agile product development

andy@assembla.com — Sun, 07 Jan 2007 21:15:00 +0000

Recently we were called upon to build and launch a new Web product with a hard deadline in a seasonal business. By the time we started our work, only three months remained until the planned launch date. It was a big system. Our mission was to build a new and greatly enhanced version of a product which had taken 15 months to build in its last iteration. So, we had a benchmark.

In this case, we ran more than four times faster than a similar project implemented last year with older tools and development methods. We also came in on-time and under budget, and we ended up implementing features faster than we could figure out how to use them.

How did this happen? Want to try this at home? I will share our lessons below. Good luck.

Donâ€™t do things that take time to arrange
Donâ€™t get dragged down by old code
Establish the data schema
Pile on with new team members
Use a ticket list / work queue
Build something now, even though we know we will have to rebuild
Donâ€™t split the codebase into components
Daily releases instead of stabilization periods
Make a usage dashboard
Web services are your friend
Hire users as product managers
Donâ€™t create obstacles: Users provide the data
Documentation on a wiki
Find the one thing people will use

Here is the expanded version, for people who actually do this for a living.

Donâ€™t do things that take time to arrange

We get big time savings by not moving people around. Travel takes time to arrange, and it takes time to do. People should be working, not moving, and they should start now. I donâ€™t do interviews. I found that even arranging a phone interview takes five to seven days â€“ a big chunk of a 70 day project. Instead, I let people start work and I evaluate their work later. I also donâ€™t set up conference calls for the product team. In my observation, time spent on the phone is a good indicator of communication problems, and is best avoided by improved management and communication.

Donâ€™t get dragged down by old code.

I believe in doing a lot of research and trying to adapt existing open source code, as an alternative to diving into new development. We spent a week of our precious schedule taking a in-depth look at open source alternatives. We considered a system with a friendly academic license and $4M worth of development behind it. What we found was big, complicated enterprise software with lots of heavy baggage. We talked to people who were adding to Sakai, and found that they were typically taking 8 months to do things that I thought should take a month. We discarded the existing product for the same reason. We moved on to a more agile architecture and never looked back. I had to change my thinking because, in the new world, it often is faster to build from scratch.

Rails is simpler than java for this type of application, and the build was much faster as a result.

Establish the data schema

It is easy to add to a data schema, but difficult to change it. I sometimes visit old clients and find that the people, products, and code that I knew are long forgotten, but the data schema remains. Data schema is the one piece of up-front design that we do before diving into the build.

Pile on with new team members

It is possible to bring in a lot of new team members and let people pick their own tasks. Using this technique, we were able to triple our output in three weeks. This approach is the exact opposite of the “Mythical Man Month” recommendation, which holds that adding new team members imposes a cost of learning time and management time which will delay a project that is on a short time schedule. In my experience, adding team members DOES delay a project, if you need to guide them and manage them. The pile-on method works if the new developers are good and can find their own way. We are helped by our â€œinspired by open sourceâ€? methods, which were developed to serve large teams with loose central management, and the fact that some of the new developers are very good. We can weed out the rest a few weeks later.

An obvious related lesson is to work with good people. I am not even going to put it in the list of lessons from this project because it is far from a new lesson. A good developer seems to be about 5 times as productive as an average developer. In this project, there were several cases where a team member spent 2 weeks working on something, did not finish it, and then found it replaced by something our best guy finished in 2 days. Given the potential gains, most project managers donâ€™t invest enough in recruiting and retention.

Use a ticket list / work queue

We put all of our tasks, bugs, and new requests into a list of “tickets”, often called a work queue. We use Trac. In fact, we use Assembla.com. We sort the tickets by priority and milestone, so the tasks from the next milestone are on top of the list (queue). Itâ€™s easy to figure out what to do. Just look at the list of tickets and pick something near the top. You can try to adopt a more rigorous agile methodology, but you will find that it is hard to improve on this simple and effective technique.

Build something now, even though we know we will have to rebuild

We started building copies of the old product, and copies of features that we saw in other products, before we even had a coherent visual design or plan for the new product. Then we ripped out a lot of the guts and rebuilt it. This was still faster than waiting around for a coherent design and product plan. Why? In this new environment, development is faster than product management. From a product management point of view, it is faster to ask for changes than to figure out what the product should do from scratch. It takes forever to build something that is unknown, but if you know what you want, builds are fast. So, the two steps (copy and redesign/refactor), with clear instructions for each, are faster than one build from a blank sheet.

Donâ€™t split the codebase into components

In this application we needed several types of servers that were different â€“a permissioned application, a public portal, and a central user registration server. We lumped them together in one repository and one application with configurable â€œrolesâ€? that turn features on or off. This made the code a bit more complicated. However, it made other aspects of managing the app â€“ setting up developers, testing, staging, deployment â€“ a lot simpler.

Daily releases instead of stabilization periods

In a normal Web 2.0 style release, you just run beta releases of increasing quality, until you are ready to do a bigger announcement. In this case, I didnâ€™t think we had time for such gradual stabilization. I initially recommended that we do a code freeze with a week of testing and stabilization. The resulting product might not be perfect, but at least it wouldnâ€™t crash. We started with a daily release process and no code freeze, and it worked well enough that we didnâ€™t need to a code freeze and stabilization period. Itâ€™s not bug free, but we fix the bugs as fast as people notice them. I now have abundant evidence, from several projects, one of them a big enterprise ASP, that users will tolerate a product which comes directly from developers, every day, with minimal testing, if the time to release a bug fix is less than 24 hours.

Make a usage dashboard

Program a custom dashboard that shows registration and usage statistics. Everyone on the team will use it every day as soon as the beta period starts.

Web services are your friend

Arranging integration with external systems can absorb a lot of calendar time. We were able to use SOAP services (easily offered or called in Rails) to make it go faster than I expected.

Hire users as product managers

Product management â€“ figuring out what the product should do â€“ became the bottleneck early on and remains the bottleneck. Using the above techniques, the developers pull requests off the ticket stack and implement them as fast as we can make the requests. Our strategy to deal with this is to hire users as part-time product managers, and let them each work with a mockup team to redesign the visual parts of the app. With the distributed team system, itâ€™s easy to integrate part-timers like this.

Donâ€™t create obstacles: Users provide the data

We took out the centrally controlled categories and allowing users to just type their own tags for the content that they entered and shared. I think we would still be waiting if we had to build our own categories. We got a surprise when we released with a comprehensive list of US data, and we had immediate requests from dozens of countries. I now think that users should be able to post additions to any part of the database if they need to. Why block them? Sometimes the additions can be released directly, and sometimes they may need to be approved by an editor.

Documentation on a wiki

If your application changes every day, you need to put the documentation on a wiki. If you set up the documentation wiki early in the development process, you can start linking to it from inside the app, just like embedded help pages.

Find the one thing people will use

If you can find the one feature that people will use and adopt, it makes the whole system simpler. So, release early and often and watch your dashboard. Find that thing.

Assembla Blog: Lessons for Hyper-Agile product development