Lean Software Development and Process Improvement

One of the many interesting ideas to come from lean is a focus on minimizing WIP (Work In Progress). In the context of website development, WIP is projects that have been started but have not yet been deployed. This makes sense as if your main resource is billable hours, any billable hours spent on a project that is not yet completed increase your working capital requirements assuming that - like us - as a business, you get paid for completed, working software - you don't just get paid each month simply for spending hours. (If you do get paid for time on incomplete projects WIP is still a problem, but it's your clients problem - not yours!)

So, if you do get paid on a project basis, the question is, how can you minimize WIP? . . .

Starting Small
We're big advocates of small, targeted projects. You never really know if a web application is going to be successful until you deploy it and see what the users do with it. Because of this, rather than a huge, over-thought project, it often makes more sense to build a simple, stripped down system first and to put it live. From there, end user feedback can be used to prioritize the product backlog. We find time and time again that when we pull out features suggesting we could always add them in phase 2, it is seldom the originally envisioned features that end up being built in phase 2. It's almost always new requirements suggested by actual users of the live site.

Do you really need sophisticated reporting for a site that you don't know whether anyone is going to visit? At most, put the logging code in from day 1 and then add the reporting when it's needed. Sometimes, you can even skip the logging code if it is more important to get the site live than to get every single piece of usage data from day 1. Similarly, often a client will want real time integration of leads with a CRM system or of orders with their accounting system when we're building a new site where we have absolutely no idea whether there will be any leads at all. Instead, I give them a ballpark price and suggest "let's build without this and just enter the data by hand. When it's worth $10k (or whatever it costs) to save the data entry, let me know and it'll be live in a couple of weeks". In this way we get the project live and working as quickly as possible and for the lowest cost, and then we only add more advanced features when we all know that it's worth the time and money.

I find the biggest challenge is that for business people they're used to things like brochures or print catalogs where you have one shot to get everything right so they're reluctant to build anything other than what they envision will be the complete application that will meet all of their needs for the next few years. We all know that they have no idea what they'll really need the app to do over the next couple of years, but unfortunately many business people still have the dangerous "illusion of knowledge" that they'll be able to predict accurately the future needs and direction of an application that doesn't yet exist. We simply do our best to downsell people and focus them on "if this site is better than the current one, let's launch and then add features while you have a new site making you money instead of waiting to get any business value until everything is complete". We also often use the idea of "phase 2" as a bucket to put all of the great ideas that various stakeholders often bring up a few days before launch that could potentially delay the project by weeks or months.

How do you help your clients to focus on launching "the simplest thing that could possibly work", and a phased approach to application development?

Getting Things Done
I'm a pretty big fan of David Allan's GTD approach to working efficiently. In my experience, one of the things that often drags out a web project is the cycle time on turning around relatively small requests like a tweak to the CSS or some recommendations on payment processors. One of the things I'm trying to do better now is to knock out smaller items at least on the same day they are received to try to keep the momentum going on projects.

Nagging and Measuring
One principle that is worth bearing in mind is that "if you don't measure something, you're going to have a hard time improving it"! One of the things we are not really good at right now (hence the interest in the tracking system) is the process of tracking how long a project took and why. I think it'd be great to be able for us, our partners and our end clients to see how long a project took, and specifically who (had )what companies and/or individuals) had taken up that time on the critical path items. Eventually I could see adding penalties into the contract where if any party delayed the project by more than a number of days, appropriate penalties would accrue - making it in all of our direct financial interests to get projects live on time. I think automated tools for reminding people on a regular basis of any tasks that they owed and whether they were slowing the project down (and by how many days to date) might be annoying, but would also be a really good ay of keeping a focus on getting the project delivered on time.

How do you go about getting projects delivered as quickly as possible and minimizing WIP?