This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Notes on "Enterprise Agile"
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
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 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
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.
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?
More...
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 ;>
Previous Topic
