Application Architecture for the Enterprise

Thoughts from Dave Nicolette on Enterprise Agile

Dave Nicolette offered up some phenomenal thoughts in a comment here on the enterprise Agile discussion that Cote' started. I thought these were worth re-posting at least for the benefit of the aggregator readers who don't check back for comments.... my thoughts below.

>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.

It's ideal in one sense when your users are inside the enterprise because you have a (perhaps?) captive audience, and usually have much easier access to your user base than if you were building a commercial software product. I think co-location is definitely a challenge in enterprises, unless the teams are small and there is some kind of office space glut - not common in my experience. But your're right on that this makes a huge difference.

>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.

This is an extremely keen differentiation between types of projects in an enterprise, and appropriate approaches. I wish I had come up with that paragraph ;-) I think you are correct that tactical projects and user interfaces lend themselves very naturally to Agile as compared to larger enterprise efforts. (I would add product line practices to your list of approaches.) I don't mean to sound like a one-size-fits-all thinker (who would sign up for that moniker?).

I would not call myself a methodologist, though I am very interested in methodology. Others will surely disagree, but for me Agile approaches represent more than anything a set of values. I think those values and, now getting more specific, some practices should be applicable across projects using a variety of formal methodologies. A key Agile principle is that teams set their own rules - I think teams should be allowed to pursue a project with the methodology of their choosing, and that might not be Agile, XP, etc. But I do think they would benefit from still using certain Agile practices.

And I will plead guilty to using the Agile term to liberally, especially regarding lean. If I sat down with a methodology therapist, I would probably learn that I am perhaps more of a lean proponent than an Agilist when it comes to fundamental beliefs. I have spoken with Mary Poppendieck on a few occassions, and appreciate a lot of her thinking. Having said that, I think individual Agile practices are again quite portable across various approaches.

>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.

I think you made this point better than I did, but you are saying what I was trying to get at. The fact is that support is not a project, and many of the formal methodologies are oriented around running projects. I think a phrase like Agile Support is intended to indicate that you are applying Agile principles and practices to the support process. You mention some good practices that apply - pairing, TDD. One point I was making is that I just haven't seen any flesh out a model around applying these practices to support because so much of the conversation is around running development projects - but this is an area of prime concern generally speaking within large enterprises, and I think they would benefit from applying Agile practices - lean approaches - to support.

Thanks for the fantastic comments, Dave, and taking the time to contribute here. I will be subscribing to your blog and look forward to your influence on my thinking.

posted by scott @ 6:22 AM