Comments on: Notes on “Enterprise Agile”

By: Helen, software developer

Helen, software developer — Tue, 04 Apr 2006 16:10:14 +0000

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

By: dk

dk — Tue, 14 Mar 2006 05:38:39 +0000

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

trackback here: http://controlledagility.typepad.com/weblog/2006/03/operationalizin.html

By: James

James — Thu, 09 Mar 2006 12:10:06 +0000

Couldn’t resist commenting on another aspect of agility: http://duckdown.blogspot.com/2006/03/agility-in-large-enterprises.html

By: Scott Diedrick

Scott Diedrick — Wed, 08 Mar 2006 00:24:36 +0000

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.

By: Brandon Whichard

Brandon Whichard — Wed, 08 Mar 2006 00:15:08 +0000

My thoughts here:
http://speakercity.blogspot.com/2006/03/re-cote-on-enterprise-agile.html

By: Scott

Scott — Tue, 07 Mar 2006 14:49:33 +0000

Nice post, Cote’ - let’s keep this ball in the air… my thoughts at http://scottmark.blogspot.com/2006/03/agility-in-large-enterprises.html

(BTW - where is your trackback?)

By: Jaime Cardoso

Jaime Cardoso — Tue, 07 Mar 2006 01:35:27 +0000

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.

By: Kevin Brennan

Kevin Brennan — Mon, 06 Mar 2006 20:59:20 +0000

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 cant 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 theyre able to shut down the old. Until that transition point is reached, until what youre constructing better than what is currently there, theres nothing to give the user and you cant ask them to use it and give you feedback, at least not in a consistent fashion.

When theres no system, when youre building something totally new, then it can be a lot easier. To make a comparison, lets say youre building a word processor. Most Agile methods start as if youre 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, lets 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 whos used Microsoft Word 95 for the last decade, and needs you to support 90% of what it does while adding new features. Theyve got 10 years of files that need to be readable by the new application. Theyve 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 applicationsand 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 occursbecause 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, thats easily donebut its hard when you have to replace something that already works.