The 30 Day Blitz - Building Great Software One Step At a Time
A good friend of mine, and long time colleague, Michael Hugos, has a new book coming out about a concept called The 30 Day Blitz, as well as other ideas about agility as it is seen from non-technical folks. At processexchange.com, he has a podcast out that explains it in his own words. Mike Hugos writes about "small a" agile at CIO magazine, and has been doing projects as an independent consultant (with our help) for Fortune 500 companies.
Let me say, first off, that I am a little biased ;) - as I have worked with him on multiple projects and have personal experience of his ideas working spectacularly well in practice.
So, what is this idea, exactly? It is nothing revolutionary. Step 1 - get a motivated person in a room with people who have a problem that can be solved with software. Step 2 - see how much of that solution you can deliver in 30 days. Step 3 - deliver the solution (yes, there is a step 3). Repeat as needed.
The idea basically admits that which we don't ever want to - and that is, when you start a project, you don't really ever know where the destination will take you. There, I said it. 9 month project plan? Not worth the space on the hard disk it is saved to.
The 30 day blitz is about building credibility with your client. You become trusted when you have a history of success. 30-day plans allow you to build that history of success in short iterations. They help you avoid overplanning, overengineering. They focus you on the 80% of the solution that matters - the part that adds business value in the first place.
If this sounds a lot like big A agile, it is. Every tenet in the Agile Manifesto - "Individuals and Interactions over Processes and Tools", "Working Software over Comprehensive Documentation", "Customer Collaboration over Contract Negotiation", and "Responding to Change over Following a Plan" ... is met by what Mike is talking about with the 30 day blitz. The only difference is Mike bundles the same basic principles in more flexible packaging, so you don't have to buy a lot of the stuff that goes with Agile (TDD, XP, etc.) In essence, the 30-day is an elevator speech version of the Agile Manifesto that will actually sell to buyers - the kind of people who distrust anything called "Manifesto" (which, fairly or unfairly, makes people think "revolution", which becomes deemed "risky".)
The 30-day is a tactic. But it's a tactic that builds towards a strategy that gets you closer to your customers (be them internal IT users, external customers, or a combination). It isn't a silver bullet. It requires motivated developers, buyers who are willing to collaborate rather than direct, and a base level of mutual trust to work. It requires developers who are going to understand how to build a modular architecture, who are pragmatic enough to apply the YANGI (You Ain't Gonna Need It) principle a LOT of the time, and who are willing to have a sense of ownership over the end product.
Here is a thought experiment. Take a complex problem. Now, pretend someone just gave you some venture capital to build a solution (similar to what YCombinator does - small $5-$15k investment). Is there not an important part problem you can't solve in 30 days? In over 12 years in this business, I have yet to see such a situation ... and I have seen a good deal of software that is more interesting than simply pushing and pulling from databases.
Can you build an enterprise app this way? While some people define enterprise as anything that takes more than 6 months to build and has a budget of at least seven figures, my definition of enterprise is something that a large company can depend on in a critical area. And yes, Mike, myself, and other colleagues have delivered such applications.
I encourage you to listen to the podcast to find out more. Watch for "the 30-day blitz" to start to really take hold in the coming weeks and months!