When I visited Chicago last, John Bracken and Brian Fitzpatrick aka Fitz from Google organized a very interesting meeting with people from The MacArthur Foundation, Google and various communities including some folks involved in government.

During the meeting, I talked a lot about my thoughts on innovation in the context of newer software development practices and frameworks like agile development and Ruby on Rails. As Reid Hoffman often says, if you're not embarrassed by your the first release of your product, you've released too late." The release early, release often ethos of linux combined with the amount of actual "real work" you can do in one week with Ruby on Rails and other languages and frameworks totally changes the game for early stage consumer Internet investing.

Generally speaking, it's probably cheaper and faster and more effective to make a prototype than to make presentation deck. It's also probably easier to test something on real users than to do lots of marketing and guessing. My recommendation to just about anyone with an idea is to just build the thing, iterate until you have some user traction, then pitch angel investors based on that traction. This is very much in line with the old IETF motto of "rough consensus, running code."

In agile development, you concentrate on doing short iterations with input from your users constantly feeding back into the next iterations.

The "opposite" of agile development is a long process of deciding what to do, anticipating the problems, writing an RFP, work with a contractor until the project is completed, debug it, and then maintain the thing.

The problem is, in the real world, things change and by the time you're done, you're often pretty far off the mark and usually the first version isn't right anyway - so you end up making something 2 years late and a hundred features off target. With agile development, you test, evolve and stay in tune with your users and let them guide you. You can also test and refactor more easily because each "story" or feature is smaller, tested and easy to isolate and remove/change. (Or should be.)

It was very interesting to me that the government folks perked up when we got into this discussion. I remembered a comment by someone at an conference (sorry, I can't remember who said this). The idea was that in big software and in government policy, it was easier to add features (lobby for things to be added into a law) than to remove features. Everyone has their favorite feature that needs to be added. There was very little incentive to remove features and complexity once it was in the law or the code. You end up with things like Windows, some modern cell phones and many of our government policies, turning into bloatware that's huge, too compliated for normal people to understand which doesn't really even do well what it was originally intended to do. I think that keeping units small, proper test suites (accountability at the object level), and agile development can help mitigate some of the causes of bloatware that loses touch with why it exists in the first place and ends up sucking almost all management energy into process.

Also, the idea of floating government policy and iterating rather than taking ALL of the inputs before starting some humongous project also probably makes sense if you have the right kind of structure and discipline. I think there are a lot of things that agile developers have figured out that make sense to look at when thinking about policy and other work.

1 - Extreme programming. Work in pairs on the same screen so that you're checking each other and you're learning each other's productivity and other tricks. Swap partners every iteration. This is a very good knowledge sharing technique.

2 - Test suites. Assume everything will fail. Test what happens when what you have built fails and how it affects the other objects around it. Make sure you will always know when something fails and why. Build system to be robust against human, network, financial, computer failure of the object and build backup systems. Test suites also help you figure out what breaks when you make changes to the system and helps you later when you want to change, remove or refactor stuff.

3 - Small. Keep the teams small, break big problems into small problems. Break the small problems into "stories" or short tasks that a very small group of people can do.

4 - No proposals, specs, RFP's. Use a tracking system like Pivotal Tracker for tracking the tasks, but don't do huge project sheets or try to decide everything before you get started. It's more important for each of the small groups to share their local context and that each small part works correctly and doesn't screw up the stuff around it.

It may seem counter-intuitive, but I think that having a lot of small groups focused on being robust and agile and relatively independent makes it easier for the higher level decisions to be made and retain focus on the mission. Micromanaging is huge and inefficient. Each small group provides inputs to the system and feedback from the "users". Unbundled and small groups makes the whole system much more flexible and "agile" and changes can be made quickly without breaking things and allows focus on context instead of structure.

A lot of my thinking in this area has come from watching Jay Dvivedi and his team at Shinsei Bank and also working a a little with the Pivotal Labs folks. Having written this rambling blog post, I'd still like to say that I'm still rather new to the whole world of agile development, but I think there are a large number of practices that are being developed that can be applied to many other fields including but not limited to government policy development.

15 Comments

As you mentioned, these new languages and new ways of working make it very easy for new startups to "sketch out" a product as they go. I am of the bias that the ones who are succeeding, are the ones who have an open door to their customers and are reacting to the feedback they receive. Since the cost of building a product is now so cheap, I'm wondering how many will invest more money and resources into improving their ability to listen.

You should talk with my friend David Spann, one of the founders of the Agile movement on integrating Agile practices into other aspects of business/life. If you find yourself in the Intermountain West in the next little while, I'm sure he'd be more than happy to talk with you.

It sounds interesting to take the process of agile development as a blueprint for innovation in other areas. Do you think it would work not only to develop policies but f.e. to develop some new products? Think of pharmacy where you have to do many iterations.
Regards
Michael

Ito-san

Interesting post. Funny enough, this same topic has been discussed numerous times, always by influential individuals such as yourself. You have broken it down into 3 very interesting steps:
1. Build the damn prototype (http://bit.ly/uQVUH)
2. Get people to make noise about your prototype (http://bit.ly/uAwT6)
3. Pitch

If I may compare the 3 steps, Step #2 has got to be the most difficult. Building the prototype, in whatever Agile language is not tough at all. Pitching, IMHO, is also not difficult since VCs worth pitching to would understand and "Get It" immediately without too much talking.

However, getting people to (a) Use the prototype (b) Give the right feedback for further improvements (c) Make the right noise to get more people to use the prototype is not something everyone can achieve. As my mate Jeff Paine says - you got to be "plugged-in".

Coming from Singapore and sitting in Dubai in a day-job, regardless of how innovative or interesting my prototypes are, won't matter. There's no one here to listen. And without being part of the matrix, and with no conduit in place, we'll always be stuck in Step #2.

Cheers
Felix

I love the idea of exporting agile methods from software engineering to other knowledge-intense areas, especially to government. Many of the political challenges we face today (e.g. global warming) are simply "too big to spec".

Admitting we cannot solve the whole problem in any way and then giving priority to quick iterations that tackle individual "citizen stories" might be the only effective way to go about this.

Another benefit of agile frameworks is that they usually include a "customer" role: stakeholders are embedded in the team. Such roles might be a way to allow for input from special interests while maintaining a very transparent process.

I must also mention a project I launched (in the prototype, I'm-ashamed-of-the-current-version way) yesterday: adhocracy.cc

Its a non-profit platform for tiny direct democracies in which 'laws' are essentially wiki pages with voting attached to them, thus allowing for continuous improvement of the regulation. I hope that this tool will prove to be valuable to distributed groups (e.g. Wikipedia-style peer production projects) or local citizen groups. Embedding an agile process in the platform is one of my design goals.

Cheers,

Friedrich

I love the idea of developing agile. I have been practicing scrums for our day to day work in my team at microsoft and I see a great load of difference from a typical waterfall model.

Personally I feel it fits pretty well for the web based products.

there's a parallel to the lack of entrepreneurship here in japan. making a mistake is such a big issue that people don't want to take the risk.

日本語で同じ内容を書いて欲しいですね。保守的な日本の「stakeholder」は「改善」を言いながらも早すぎるの公開は許せない。起業家と投資家の口論でもある。

/dc

Brak the big problems into small ones is a very smart move.

Hi Joi, you might like to read about OpenAgile. We have developed this approach to expand Agile to non-software development environments. The primer is located at www.openagile.com. We welcome your feedback.

Ruchit ,

Actually Agile is specifically designed for Software Development (thus it has to fit it). The thing is building a software has a lot of unknowns and undergoes a lot of changes and constant feedback from the client.

Indeed, the agile development is about social change of the architecht, developer, and indivisual relationship. Kent Beck(Father of eXtreme Programming, early Agile development) has been working with Ward Cunningham (Father of WikiWikiWeb) in the pattern language project since 1980s. In his XP book second edition, Kent Beck described how the patter language project challenged the traditional architecture process and succeeded especially in the field of software developemt.
http://www.informit.com/store/product.aspx?isbn=0321278658
Additionally, Douglas Schuler in CPSR Seattle also tried the pattern language approach about the social change independently.
http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=11601

I have heard a number of experience designers & user researchers bemoan the Agile model for not embracing the design process. Their sense is that design is an after-thought or a necessary evil in the rapid development model that Agile embodies.

Sensational generality: is Agile contributing to the decline of usability and intelligent design process, or does the Agile model truly embrace designers as critical components to successful execution?

@Ruchit Garg

yeah I agree with. It's good idea.

Awesome tips. This inspired me to start writing tests for my otherwise testless application

Great anaolgy between software and government. As someone who works at an agile shop that really hit the mark for me.

@chris - we have had some great success with designers embracing our agility and some that have even taken steps to be more agile themselves. Its not a black and white issue for some people - I think there are things to be learned in both directions.

Leave a comment

About this Archive

This page is an archive of recent entries in the Business and the Economy category.

Books is the previous category.

Computer and Network Risks is the next category.

Find recent content on the main index.

Monthly Archives