Skip to content

Notes on "Enterprise Agile"

As mentioned previously, my pet project is to start outlining the idea of “Enterprise Agile.” I should be talking with James sometime very soon about it, so I wanted to collect some starter items. And there’s plenty of other people I’ll be chatting with — I’ll be taking you up on your offer Chris, it’ll be great to compare BMC notes ;>.

I’ve done a poor job of tagging myself as interested in the topic: well, on this blog at least. As Bill alluded to, I’ve spent a mad amount of time talking about Agile in public.


I spent much of time as an Agilist building a product that’s sold to other companies, not an in-house system. Many of the early Agile stories (XP’s C3, for example) are about consulting gigs: one customer hires a group of coders to program a custom application, or extend it out. The point is: there’s one customer.

Developing enterprise software means you have many different customers, each with lots of money, who want very different things. Balancing those requests is challenging, and many of the platforms available don’t cater well to delivering highly end-use customizable applications/platforms.

So, the issue comes: how does Agile look when there 100’s or 1,000’s of customers?

The Scrum-of-Scrums Needs Work

Large shops make it possible to have many different teams, each with competing priorities. Even those priorities aside, getting 5-8 teams to work together on the same 2 week iterations is difficult. Part of the motivation for doing waterfall is to address this coordination problem.

Now, if you’re a super-cool project management shop, this won’t be a problem. But if you’re super-cool, whether you do Agile or not is irrelevant. To make a sub-point: methodology discussion only really matters for “the rest of us” those who aren’t already geniuses at project management. Successful Agile practices focus on people and context rather than process and cant. Cockburn is always incredibly relevant to Agile discussion because he addresses people’s involvement in developing software again and again.

So, how do you make Agile work across multiple groups who’re normal, not rock stars? How do participate in a baton race when you have no idea where you’re supposed to be waiting on the track for your teammate? …or if they’ll be passing you a baton at all, or something other than a baton?

Sales and Marketing

In a large part, much of Enterprise Agile has to do with Sales and Marketing in large companies. Most of Agile theory as it exists applies to development, QA, and product management. The flaw in Agile-think (as it exists in the collective mind of the software world) is that it hasn’t taken hold in the rest of the organization.

For example: how the hell do you sell software to enterprise clients when you have no idea what the software will be in 6 months? Software as it’s currently sold is largely sold by feature lists and sold into the future: “we need an identity system that does this, that, and this. Do you have that? And we need that to integrate with our 2 year plan for complete identity management.”

Thanks to some thinking from some former BMC colleagues (who can feel free to chime in and identify themselves if they wish), one starting theory of Enterprise Agile is that sales people can only sell what’s currently available. They can allude to what might be available in 3 months, and they can only discuss features available beyond that when they’re getting the client really trashed at the bar so that no one remembers. Think of Dell’s JIT manufacturing.

The point is: if you’re doing Agile, selling beyond what you have in the “warehouse” is dangerous. Sure, we do that now, but to use a smirky page from the Agile playbook, “yeah, how’s that workin’ for you?”


Support and maintenance are pillars of enterprise software. I haven’t come across much in the area of Agile on the topic of support and maintenance at the low nut-and-bolts level. Sure, you can take the same basic premisses, and try to apply them to a help desk and 3rd level support, but I’d like to see something at least as “with it” as ITIL when it comes to Agile support. When I read ITIL on help desk, I get that same “Good, God! That’s so right!” reaction that I get when I read about Agile methodologies in development. Sadly, I haven’t come across something about Agile support that gives me that same reaction.

Support is incredibly important in enterprise software, and we’d do well to address the question “can Agile make it better?” Of course it can. And if harnessed correctly, it can even make the development side of the software better.

Enterprise Installs Every Two Weeks?

If you’re one of the Agile chest-beaters out there, you probably run 2 week iterations no matter what the features being delivered are. You and I would get into a long discussion after a few drinks, but at 11:25AM on a Saturday morning, my response is just, “fine, good luck with that.”

Iteration debating aside, one of the results of an Agile methodlogy (more specifically Scrum) is a fully deliverable and ready system at the end of each iteration. This is difficult if you’re building a large system up from scratch and even harder if you’re a product instead of a hosted service. Nonetheless, software that could be used by your customers is the goal of every iteration.

The question, though, becomes: how often does your customer want to upgrade? Enterprise customers tend to fear upgrades because, to be blunt, they don’t work. So, part of the solution is simply making them work often enough. In my mind, delivering type of software takes huge mental, project management, and architectural shifts. Working upgrades are probably the #1 feature for any long lived project. How many projects operate accordingly?

Another part of the solution is to figure out other ways to upgrade the software: Windows and OS X auto-update come to mind. The best example is the seamless updating that Growl does: Growl auto-update itself with just a click of the OK button. There’s no need to download something, run an installer, reboot your machine, or even Growl: just click OK. But even more impressive and user friendly, applications that use Growl can auto-update Growl as needed. That kind of dependency upgrade is the stuff of wet dreams and big sales deals…and those lucky linux command liners.

The question is: how do you help your customers upgrade when they want to and need to, and be happy about it? How can you make continuous upgrading a much desired feature rather than not a too often encountered fear?


These are just some items to start the ball rolling. My hope is that these will be enough to start a longer conversation with those of you, dear readers, who’re interested. I’ve already got a few people lined up to talk with, but please consider this an open invitation to start up a conversation with me (yourself, or whoever else ;>) about these topics: via email, IM, blog posts, comments, phone, or whatever (see the side bar on the blog for all the contact details).

I haven’t posted much about Agile on this blog since my attention has been split on the fascinating stream of topics that RedMonk chews on day-to-day — such is my shiny objects syndrome. I assure you, I am an Agile nut-bag. I would live my life based on stories and iterations if I could get everyone else to play along ;>

Disclaimer: BMC and Microsoft are clients.

Categories: Agile, Ideas.

Comment Feed

8 Responses

  1. I'm one of the guys that get terrified when I see people using apt-get to install applications in production environments and you're talking about ending all the product lifecycles?
    If I understood you correctly, Sun uses basically the same methodology to develop Solaris Express (the next version of Solaris) but, since the code goes into production, it's a completelly different way to go from there.
    My take is that if you have a very granular code, you could actually fit a module into a two week development – testing – regressive testing and backout testing cycle but, c'mon, most applications aren't all that modular.
    But, I'll just wait for your follow up posts on this so I can have a clearer picture about this methodology.

  2. I’ve encountered exactly the same problem when trying to discuss Agile methods in a business environment.

    A bigger problem is not Big Design but Big Implementation. In most enterprise apps, you’re replacing an application that already exists and probably does a lot of different things. Users aren’t going to accept a system that doesn’t give them everything that they already had.

    You can?t start small, and build, and build, and deliver value to the users because the value is exactly zero until the whole thing is in place and they?re able to shut down the old. Until that transition point is reached, until what you?re constructing better than what is currently there, there?s nothing to give the user and you can?t ask them to use it and give you feedback, at least not in a consistent fashion.

    When there?s no system, when you?re building something totally new, then it can be a lot easier. To make a comparison, let?s say you?re building a word processor. Most Agile methods start as if you?re working with a user who currently writes everything out in longhand. So, for a first iteration I could just have something that lets me type out information and then print it off. Save? Hey, you mean I could change a document after starting it rather than write it out from scratch again? Cool! OK, let?s do that. Fonts? Wow! ?and so on. From the perspective of a person with nothing, each feature adds to the value of the end product.

    A business app, on the other hand, is more like designing a word processor for someone who?s used Microsoft Word 95 for the last decade, and needs you to support 90% of what it does while adding new features. They?ve got 10 years of files that need to be readable by the new application. They?ve got a bunch of macros that they want to see integrated as core functions. Mail merge has to work. They want to be able to cut and paste from a bunch of different office applications?and all of these things have to work before they can stop using Word 95.

    This is, I think, where much of the disconnect between developers and business users occurs?because the developers try to get the business users to set differing priorities on features that the business users view as minimal satisfiers. When developing ab initio, that?s easily done?but it?s hard when you have to replace something that already works.

  3. Nice post, Cote' – let's keep this ball in the air… my thoughts at

    (BTW – where is your trackback?)

  4. I work for a very small startup, but we are also trying to deal with the problems of integrating Agile into the development of Enterprise software. Enterprise software due to its price and customers tends to have long sales cycles, extensive marketing campaigns, and require long term roadmaps to close sales or retain customers. How can you support these things as a development team if you cannot tell management when any feature will be complete more then a month or two in advance. Sales and Marketing have to work up materials, pitches, etc. and need to know what kind of product they will be selling with a good lead time. I would say 3 months at least. The Product Manager, the CTO and I are trying to form a broad idea of where the feature set is going over they next 3-4 releases to the customer. That is about 9-12 months out for us. Then for each release the specifics are chosen during pre-sprint meetings. This also allows us the reevaluate our priorities and assumptions on the features after each iteration. It is still in a process that is in flux and it is a bumpy ride, but I think we will be working out the kinks and have a pretty good system in a few iterations.

    Scott DiedrickMarch 7, 2006 @ 5:24 pm
  5. Couldn’t resist commenting on another aspect of agility:

  6. Agilists working in enterprises bemoan the fact that the enterprise just doesn't get Agile.

    trackback here:

  7. I must agree with Kevin. It's really hard…though not impossible.