So, if one can succesfully deliver better software faster using Agile, with or without a BA, power to you. Meanwhile, I have tons of other projects to keep me busy.

Kevin – I appreciate clarification on the enterprise analysis bit.

What I was trying to express is that enterprise analysis is all-encompassing, not to imply that it concentrates on the “not-software” stuff. In re-reading my post, though, I see how my placement of that sentence could make it come off that way.

The biggest disconnect that I see between the Agile and business communities–and it’s growing, not shrinking–is that Agilists think software is important and interesting, and the business people should make it a priority. The business people, on the other hand, are increasingly coming to view it as a commodity. That’s an oversimplification, of course–there are companies that gain a real competitive advantage from software–but the vast majority of businesses see software as something that’s secondary to getting on with their real jobs.

I’ve worked on an Agile team, and one of the big lessons I learned from it is that Agile development requires a significant set of pre-conditions that very frequently don’t exist in businesses. You need to have a clearly defined and understood objective that all stakeholders are willing to put at the top of their personal priorities. You need to have substantial agreement about what the problem is and what you’re expected to achieve.

I think there is a set of problems which Agile development is very good at solving. I also think most of the advocates of it work in situations where they mostly encounter that kind of problem. However, most business problems fall outside of that set.

In terms of the BABOK–we’ve been taking the approach you mention above for the last year. We’re working to define the role, not the job.

One last point–Enterprise Analysis doesn’t mean “not software”. Enterprise Analysis is about defining the problem you’re trying to solve (what are the business goals and objectives, what is the context in which the solution will be implemented, what is the business case for making this change). Requirements Analysis is defining the solution, which may include process changes, organizational changes, policy definitions, and yes, software.

As you point out – it is sharing responsibilities across members of the team. Good article!