MARTYHAUGHT

At the end of the first day of Aloha on Rails, Jon Larkowski ran a panel ‘Is agile too slow?’. Obie Fernandez, Tammer Saleh, Pat Maddox and Blake Mizerany comprised the panel. I was very curious to see what would come out of this panel. They went through several questions but the main point of the panel was exploring if there were any contexts in which agile processes might not be a good fit. Unfortunately, they only disagreed slightly and I could think of a few cases where I wouldn’t choose to use all the agile processes. Since no one brought up these cases, I figured a follow-up blog post with one example is required.

Before I get into an example where agile is too much, let me say that of what I know I think Hashrocket’s process is great. I know they care a lot and have deliberated on their process and continue to do so. Out of the four, Hashrocket appears to have the most robust agile process and they ‘stick to their guns’ in not wanting to compromise. I would liken Hashrocket’s process to the ‘cadillac’ of agile consulting practices.

So in what context would a full on agile process be too much? I can think of one that I recently encountered with one of my clients. The situation was this client was a boot-strapping startup. They paid a recent college grad to create their product and he got it 95% done. The problem was a few things weren’t finished and the visual aspect of the site was weak. I was asked to redesign the look to be fresh, clean and modern; essentially to appeal to a younger audience. I was also asked to get it deployed, make some minor enhancements and fix a couple bugs. He was on a shoe-string budget and the amount of effort came to 3 weeks of part-time work. The ultimate business goal was to make the app demo ready; a minimum viable product (MVP). He just needed to pitch the app to potential advertisers in the system to start getting traction.

After looking over the app, I had never seen code with such a high wtfpm (WTFs per minute). There were zero tests, strangely structured object model, many Rails conventions utterly violated and so on. The app worked though with the exception of a couple minor bugs.

This is a context where a full agile process would not be appropriate. What this client really needed was a ‘moped’, not a ‘cadillac’. Yes, it needed the tests to be written. Yes, many parts of the codebase needed to be refactored. Matter of fact, a full rewrite might actually be the cheapest course of action that delivers the best long term value. The client wanted all of this however, he could not afford it today. He could only afford to get the app into a high quality demo state.

To insist that a pair of programmers should be assigned, spend a week’s worth of time story carding and write a full test suite would have given this client nothing today. He would not be able to demo his product and thus he’d get zero business value in the short term. His business need was a high quality demo so that he can build a future for his business.

So what’s the downside of not doing full on agile in his situation? The app will be difficult to maintain. There will likely be more bugs and no way to catch regression issues as changes are made. However, those two issues already exist so there’s no change to what he has now. The code quality will remain very low but if it works there’s no loss of business value as it stands today. It turns out that doing these things now would provide zero business value, but it would provide great value for when he moves forward building on his application. However, that is in the future and that is a future this client would never see if he doesn’t get his demo up and running.

What is better for his business is to get to his MVP with as little of effort. Then inform the client of the future cost (technical debt) of not addressing the issues that exist. Once his demo gets traction then he’ll have a budget to start addressing his needs and provide a better quality codebase for the future. That is what he needs today and I would be doing this client a great disservice if I didn’t provide these things and just these things.

What I do know is that there are situations where a business cannot afford a full on agile process. It may also be the case that their needs also don’t justify the process even if they had the money. The cost-benefit ratio for their situation simply does not warrant it. In the future this will make sense but today it does not. Context is king and in this case we have to look at a lighter weight process to help the client.

While I can understand that many consultants would not want this sort of project, they exist. Who knows, his application may become the next eBay. We simply do not know. As a consultant I care more about meeting the client’s needs than insisting on a process that might not be appropriate. Knowing when to use the tools in your toolkit is more important than always insisting on the same 5 tools for every job. Perhaps you can do 95% of jobs with those 5 tools but if you only need one tool, then it’s just fine to use only that.

blog comments powered by Disqus