Cote’ offers up some notes on the practice of Agile techniques at large enterprises, and asks some good questions. I thought I would offer my take here…
What product have you ever built that had 1 customer? 🙂 I’m thinking what you actually had was a single point of representation – and yes that is still a factor in enterprises. The key value at work is customer input – on a frequent basis with very open lines of communication. In our experience, a business analyst or user interface designer helps garden the input; we also hold frequent group meetings with users (more frequent than waterfall, less frequent than purist XP).
The Scrum-of-Scrums Needs Work
This is definitely a difficult point in enterprises, especially because groups are at very different places on the Agile learning/practicing curve (forget the same iteration cycle!), if they are on the curve at all. But I think many other groups appreciate the fact that Agile teams do things like include them as much or as little as they want, communicate with them frequently (rather than dropping a Gantt chart on them 6 months in advance and forgetting to tell them when the rest of the team slips), and give them short but reasonable notice on when to get things done. Yes, the last point is correct – I think a lot of the teams that are just staying afloat with operational activity don’t do well with huge amounts of advance notice. Working short cycles and smaller tasks fits in better with operations.
Sales and Marketing
The finances of enterprise IT are one of the most difficult aspects to manage when practicing Agile, IMHO. Many enterprises have annual planning cycles that are difficult to merge with a business-responsive development approach, where you don’t always know what it will cost up front. So I think the answer here is zone defense – you do what you can to stay traditional for these ceremonial activities, trying to carve out enough room to breathe. I think the proof is in the pudding – you need to demonstrate a lot of success with Agile before these behaviors will change.
Agile support models are the final confrontation in an enterprise. A goal of Agile is to reduce waste in the process, waste here being ceremonial or overhead activities that do not directly add value. Contrast that with compliance needs in an operational environment, and you have some interesting forces on your hands. I think you are right that you can certainly apply the same principles, but where is the actual framework? It’s too fun and cool to talk about development – none of these wonks want to flesh out an Agile support approach. Maybe we should make sure James tackles that in his coming book (again, I’m plugging you for info, James)?
Enterprise Installs Every 2 Weeks?
You had to say installs, didn’t you? I choose to interpret the working-system-at-the-end-of-iteration mantra so it suits my needs. I think what you really need is usable system somewhere – preferable an integration environment – at the end of every iteration, with Production schedules less frequent, but frequent enough to be aggressively useful. The idea behind continuous delivery in my view is to ensure that integration happens sooner rather than later, to make sure the implementation stays integration-friendly (is on people’s minds while coding), and to close the loop with customers. On the last point – that means both ensuring that what you did is correct, but also to let them play around before prioritizing your next amount of work… part of the maximizing the amount of work not done principle (“oh, we can just do it that way? well, let’s forget about that other idea, then…”).
Sure there is hype in the Agile community, but I think a lot of that is not from is promoters, it’s from recently-bitten practitioners. You have to dig an approach that gets people excited about their jobs again. But without being a dogmatist trying to apply Agile to how you fill the coffee filter, there are no doubt ways to solve some long standing enterprise IT practices that are low value.