Agility in Large Enterprises
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...
Products
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.
Support
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.
posted by scott @ 6:33 AM
2 Comments:
Interesting comments.
>I'm thinking what you actually had was a single point of representation
Right. "Customer" is a role on the team; there's no implication that the solution will be used by exactly one individual. In Scrum it's called "Product Owner." It's often a single individual, but there's no reason it can't be more than one person depending on circumstances. In "pure" Agile projects the development team is supposed to be colocated with the customer(s). On projects like those, I've had direct access to anyone who was to become a user of the new solution. But that's certainly not always feasible.
>The finances of enterprise IT are one of the most difficult aspects to manage [...] annual planning cycles that are difficult to merge with a business-responsive development approach...
I think there's a widespread myth in our industry that there's a one-size-fits-all approach to software development. Most IT organizations do at least a couple of different types of software development work. Why assume both types call for the same approach or methodology? One type is user-facing, tactical, vertical business application development. These are projects that have a short list of business goals, a fixed timeline, and an identifiable business customer. They're usually funded by the business unit that engages the IT department to do the work, and they're cost-justified on the basis of direct impact to the bottom line. That's where Agile methods like Scrum, Crystal, and XP really shine.
The other type of development initiative is more akin to product development than project work. Enterprise-scale services are built and maintained on an ongoing basis. Unlike project work, there's not really an end date and "customers" may be indirect. An example is enterprise SOA development and maintenance. This is likely to be an ongoing effort that has a predictable release schedule, is constrained more tightly by compliance requirements than a tactical app, is funded out of the IT base budget, and cost-justified on the basis of anticipated future savings on tactical projects that are expected to make use of the resulting enterprise facilities. This operation might cull reusable features from various business applications over time, as well, and fold them into the SOA. For this sort of work, a lean development approach is often more practical than a pure Agile approach. Methods like TPS, CMMI, or MSF Agile can apply very well.
Contributing to the general confusion about all this is the fact vendors and consultants tend to use the word "agile" to describe both Agile and lean development methods. Both are aimed at reducing unproductive procedural overhead, but the two are otherwise quite different, and they apply to different classes of problems. Many people say "agile" when what they're really thinking about is reducing wasteful process overhead, whether through Agile methods or otherwise.
>Agile support models...
In a way, you're making my point about the belief in a one-size-fits-all approach even by raising this issue. Why assume that just because the development teams use Agile methods that the support group must use Agile methods, too? That said, it can be valuable to apply selected Agile practices to production support activities. At our company, we find the XP practice of pair programming works very well in production support. Two brains are better than one, and problems are solved faster. In addition, when two people work a problem together we end up with two individuals knowledgeable about the problem, for future reference. All good.
When supporting applications that were originally built using Agile methods, the support staff has the added advantage of a working, comprehensive test suite. They can run the test suite before making any modifications to code. That way, they can tell whether they are working from a clean starting point. If they write tests for all the changes they make in fixing the problem, then the test suite remains comprehensive and useful for future support issues and for future enhancement projects.
Often, production support teams work down a list of known problems and requested enhancements when they're not occupied with fire-fighting. They can apply Agile methods in that portion of their work, to gain the same sort of professional satisfaction and the same sort of good results as their colleagues in the development area.
Dave: I liked your detailed comment. Thanks for taking the time to type it up ;)
I'll look forward to reading/taling with you more on the topic.
Post a Comment
Trackbacks
<< Home