Agile and The Three Types of Software Companies

As Brandon once put it, it often seems like I get paid to say the obvious. I forget who clarified that idea when I was complaining about how repetitive business and software development books get, but I think the other side of that statement is: people need to be reminded of things they’ve forgotten.

Of course, there’s a world if difference between stating the obvious and then figuring out how the obvious helps you pay the bills. That’s the leap I like to think I help people with: tactics. While I spend a lot of time talking, the goal of all of it, to steal a title from an old presentation, is getting shit done.

Anyhow, enough context and navel-gazing.

Allow me to state the obvious:

Inventive, Maintenance, Quick Cash

Reading through Steve Yegge’s content-rich post on Agile and Google and the pile of comments, an old thought came back to me: there are (at least) three different types of software companies and us code-monkies have a bad habit of forgetting this. The result is that we loose context in discussions about software methodologies.

The 3 types are:

1. Inventive – these companies are coming up with brand new software, or brand new approaches to old problems. Startups are often inventive companies as is Google. Most enterprise software companies are not. These companies often have few “large” customers, often building up to that, or focusing on volume sales, hosted or packaged.
2. Maintenance – these companies have already come up with a pile of software which they continue to sell by creating upgrades or adding functionality to the “core platform.” More than likely, they innovate by acquiring inventive companies. Support and sales are huge to these companies, as is predictability. As you can imagine, most enterprise software companies are in this bucket, e.g., IBM, SAP, and BEA. But also successful inventive companies often mature to this as well, e.g., Microsoft, Amazon.
3. Quick Cash – these companies follow a “bursty” revenue pattern of seeing cash making opuptunties and writing software to it. There’s always plenty of technology arbitrage on the table wherein a company with the right software at the right time can get cash for it’s software. Maybe this is just a theory on my part as I can’t readily think of an example. I suspect many small shops operate this way, as do people writing financial and compliance, best-of-breed software.

Those are just buckets: companies of course cross lines all the time. I threw Amazon in there intentionally to prove this point: while they’ve been steadily milking their retail platform over the past decade, Amazon is getting into a whole new “SOA without all that SOA” business-model.

Also, of course, there are other models. Rather than ferret out all of them, the point I want to make is how understanding that software development operates in one of these three models drives the way you do that development.

Inventive Software Development

As Steve all but points out and many of his commentors point out, if you’re in the business of inventing new software, you want highly motivated teams of people who come up with great software, and you don’t release it until it’s baked just right.

The management tools are money (salary, stock, bonuses), work-place enhancements (free meals, back rubs, etc.), directed chaos, and pride. These are the classic ways that developers like to be motivated, and we like to tell as many people as possible. Joel has his own cottage industry on the side driving those point home.

As the developer-centric talk here implies, developers are the keystone in this type of company. If your development sucks, no amount of sales and management will make up for it. There’s nothing else to sell except what the developers come up with, so it better be good.

As a company, your thinking is that you’re taking a risk that you’ll come up with some software that customers will buy. It’s very difficult to plan what you’ll end up with because the result is often something your customers never realized they wanted, and would have never asked for: text ads, iPods, spreadsheets, the web, online banking, RSS, online photo sharing, AJAX, email, web-based email…the list goes on and on once you start thinking about it. I mean, to go even further back: who even knew we needed electricity? Whale-blubber works just fine, thank you very much.

Under such circumstances, a heavy process is absurd. As a team you can’t hammer out a bunch of work-items for The Unknown. All you can do is work on gut-level ideas until they become real enough to ask, “is this something people would use?” As Blink goes into great detail to illustrate with Aeron chairs and other examples, even once you have a working prototype, it’s often years before people realize they want to buy the new invention.

What you’re shooting for is The Cash Out: either getting acquired by another company, doing an IPO, or transitioning to a Maintenance company.

Everything that Steve said is spot on if you’re in this type of company. Because Google is currently trading at $403 a share, the part he didn’t get to was what to you do when the money runs out and you haven’t gotten to The Cash Out. That’s no knock on him, Google; in fact, good for them for figuring it out.

As several commenters pointed out, Google figured out a good model where they can use the Inventive part of their company to fuel the Maintenance part. What they’re Maintaining is their text ad platform. They use the Inventive part of their company to bring more eyeballs and mouse-clicks to the ads on *.google.com.

There are, of course other things going on there, but that’s the basic Google business model at the moment. Good for them!

Maintenance Software Development

At some point your software company “won,” and now you’re writing code to stay on top and add new features to encourage your current user base to upgrade, as well as (you hope) win new customers.

There are two words you hear often in this type of development: business and legacy. Oftentimes, you’re developing software to help run a business and you’re way, way past version 1.0. For the most part, all enterprise software is done under this type of development.

I don’t want to seem cynical when I say this — because I’m not — but most innovation in this type of software happens at the marketecture level: finding new stories to tell about the same old software. Those stories can result in new interfaces and ways to use the software (SOA!), but the core software, though it’s often re-written ever 2-3 years is essentially the same throughout. It’s not quite at the lipstick-on-a-pig level, but without your customers changing their own business model, there’s only so many ways you can re-mix their software. You can’t assume a sphere cow.

There are, however, consumer-based vendors here too: like Google (as mentioned above), Amazon, Intuit, and Microsoft.

In this model, it’s sales and product management that rule the roost. Because the problem is well understood by the customer — they have existing, running software — customers can start making demands and wish-lists. Then they can start attaching dollar amounts to those demands, and then the company can do prioritize those demands, and ask development to do them.

It goes without saying, then, that sales and product management are the keystones in these companies: their weakness get magnified through the rest of the company.

Inventive-minded developers hate this: they want to be the ones coming up with those wish-lists and then seeing them born in running code. On the other hand, there are many developers who love this setup: just tell me what to do so I can go home at a reasonable hour and live a normal life. There are also the rare clever coders who figure out that this setup is ripe for being your own personal Google: you can slack off on the customers wish-lists, doing your own fun stuff in your self-given 20% time, and no one notices as long as you get the wish-list done. It’s good work if you can get it and want it.

Figuring out way to game the system aside, Maintenance companies are the place where Agile methodologies have the potential to shine. Of course, the more middle-management you have between the planners and the do’ers (product management and development), the less successful Agile will be.

The other problematic vector with Agile is the practice Maintenance companies have of acquiring other companies to “buy innovation.” If you follow that practice, you need an iron-fisted architect who’ll not only layout a plan for how these newly acquired products will integrate with existing products, but actually have the authority to make it happen, no matter what the new or old guard says.

Of course, you can not integrate the product, but then you’re really just a holding company and need to tweak your marketing appropriately.

I mention all of this because development at Maintenance companies consists largely of getting “the old crap” to work with “the new crap.” At several such companies I worked at, I’d always call this innogration. As a developer, if that’s not your thing, either get clever or get out, because it’ll drive you crazy.

Now, the danger for Maintenance companies is that they’ll spend so much time keeping their eye on their golden egg laying gooses that a whole new type of ore-pooping foul will come around that another company capitalizes on. This is the Microsoft OS & Office vs. Google OS & Office everyone’s been drooling over since Microsoft killed off (by siege?) their last challenger in that war, Netscape.

There’s a lot more complexity to the legacy vs. green-field dance that this summary. If you’re really interested in it, it’s a substrate in the Big 4 vs. Systems Management 2.0 line of thinking. Big 4 systems management is all about Maintenance, and the Systems Management 2.0 people have quite a piece in front of them when it comes to re-crafting the story and, thus, the customer’s wish-lists to align with the new software.

As a final note, there’s nothing wrong with being this type of company. In fact, I’d say the majority of employees like it: it’s stable, hours are (more) normal, and pays well. Of course, Inventive-oriented developers tend not to like it, but too bad on their birthday for ending up in the wrong place to work for where their sweet-spot is on the curves. Getting a new job can be one of those “best things that happened to me” events in their lives, though they often don’t realize it.

Now, you could say that as a Maintenance company finds itself getting less and less from the old platform and model that it needs to re-invent itself. Indeed, you have the make the elephant dance every decade or few. Very few software companies are good at that feat.

Quick-cash

Like I said, I can’t think of examples off-hand. Well, I can think of jerk-examples: spammers. Spammers are all about developing software to get quick-cash. In retrospect, many of the bubble companies were quick-cash companies as well.

I would have whacked this category out, but I so like having sets of three.

Choose Your Context

In going over all of these, the point is to say the software development methodology you use is dictated by the business context you’re operating in. It’s a fun cliché we have in developer land to say “use the tool that fits,” but we often don’t include the business side of the house in that thinking.

I’m not suggesting that Agile is an ill fit for Inventive companies. In fact, as Steve outlines, several Agile practices are fantastic. What I see as bad in Inventive companies are too much structure and discipline. Although it only says in in the fine-print, Agile methodologies (maybe not the manifesto, but definitely Scrum and XP) are all about those two things. As I often like to say in discussions about companies adopting Agile: it’s often fallacious to think that they have any process, even a work-queue.

The point is more that judging how good Agile is without taking into account the business side of the house is only half the picture: the result is often dysfunctional Agile. People on both side of the fence have been guilty of forgetting that, and then drawing broad generalizations about what works and doesn’t work.

As a final note, one excellent point that Steve raises is how annoyingly easy it is for Agile to go dysfunctional: all it takes is people not speaking up. Ironically, it sounds like Google isn’t the type of place where that’d be a problem. For the rest of us who want to pursue Agile, we really need to come up with a way to move all the hallway and lunch complaining into the conference room where that energy can be tunneled into change for the better instead of indigestion.

Tags: business, developers, google