Agile Development for Tiny Teams

Posted by: Dave Goerlich in Agile.

D-I is proud to be a tiny firm. We have always been a tiny firm, but we haven’t always been able to get big projects accomplished. While we do use subcontractors quite often, the firm is still just Josh and myself.

We believe that software should be high quality. It should be efficient, tested and intuitively designed. When it comes to features, enough is enough. We believe you should build what you need, and nothing else. We also believe that the process of developing the product is as important as the product itself.

Our skill sets are complimentary – I design the architecture that makes the application run, while Josh manages the design of the experience and interfaces.

Dave makes it work, Josh makes it usable and visually beautiful.

In the beginning, we used a traditional waterfall approach. We took on some fixed price projects, and they ended about as well as you would expect. At one point, we realized that scope-creep had lowered our rate to $1.26 an hour. No, that wasn’t with tips either.

Clearly, that’s not a business model to be proud of. So, we changed to trading hours for dollars. We kept our pipeline full of billable hours, and that’s where revenue came from. We booked clients back to back, which kept us busy, but repeat customers did not always get the attention they deserved. At the same time, we weren’t happy either.

Our Original Workflow

1. We spec’d the project to determine what it had to do;
2. We jointly architected a plan of attack;
3. I would code the business logic as fast as possible;
4. I would “toss it over the wall” to Josh to slap a UI on top of it;
5. We would get feedback from the customer;
6. We would make changes and complete the contract;

We wasted a lot of time re-working things, which caused deadlines to slip. By the time Josh got to work on the interfaces, I had to refresh my memory on how I had implemented things. Alas, more wasted time. It became evident that something had to change.

There was another problem. Our goal was to complete the project and get paid for it. However, in most cases the end of our process was just the beginning for our clients. The contract ended, but the project did not. Since we had to move on, our clients, with changes and cash in hand, were left on the sidelines.

Changing our Process

Our process had to change. Josh and I researched agile development processes, and were fixated on SCRUM. We even took a phone call with Jeff Sutherland, the creator of SCRUM, to discuss it. We gave it a fair shake, it just wasn’t a comfortable fit for us in the end.

Jon Stahl, the resident Agile expert here in Cleveland, gave us a preview of his Kanban presentation. Through my background in industrial management, I was quite familiar with Kanban in a manufacturing environment. I had never considered it as a software development process. After hearing Jon’s talk, and talking with him a bit afterward, I was solidly convinced that Kanban was our ticket to a leaner development process.

In a few future posts, I’ll describe our new development process as it’s currently implemented. Even though it’s working very well, we are always making improvements.