If you think that it would help the team's efforts, you should not hesitate to soften the "any developer can fix any bug" mentality which you see as creating issues.
The practice of Collective Code Ownership, sometimes also called Shared Code, is a fundamental principle in many flavors of Agile development, and it's probably what you're experiencing:
From extremeprogramming.org:
Collective Ownership encourages everyone to contribute new ideas to
all segments of the project. Any developer can change any line of code
to add functionality, fix bugs, improve designs or refactor. No one
person becomes a bottle neck for changes.
From c2.com:
ExtremeProgramming considers code to belong to the project, not to an
individual engineer. As engineers develop required functionality, they
may browse into and modify any class. They are responsible for keeping
all the UnitTests running (and writing new ones for new
functionality). They take on the same integrity-preserving duties as
the class owner in a CodeOwnership situation.
Working in this mode lets a responsible team move quickly to add new
functionality while keeping responsibility in the right objects.
CodeOwnership creates dependencies and bottlenecks when implementing
UserStories. We avoid code ownership, because it conflicts with
commitment from the PlanningGame. ("Code is nothing, stories are
everything!")
There's some definite benefits to Collective Code Ownership. However, you are not the first person to note deficiencies in that approach. None other than Martin Fowler describes an approach that lies in-between the extremes of Strong Code Ownership (where individuals "own" their modules) and Collective Code Ownership. He describes this as Weak Code Ownership:
Weak code ownership is similar [to Strong Code Ownership] in that modules are assigned to owners,
but different in that developers are allowed to change modules owned
by other people. Module owners are expected to take responsibility for
the modules they own and keep an eye on changes made by other people.
If you want to make a substantial change to someone else's module it's
polite to talk it over with the module owner first.
In the same article, he goes on to say:
The choice between weak and collective ownership has more to do with
the social dynamics of the team. Both seem to work, and fail, equally
well. Personally I prefer the dynamics of a collective code ownership
team - particularly in the context of Extreme Programming.
The bottom line is that to truly adhere to Agile principles, the team should do what leads to good-quality, working code. If that means loosening the grip on Collective Code Ownership, then there's nothing wrong (or anti-Agile) about that.
I would not expect any "agile development process" here as a solution to your current problem. First thing for you should be: clear your mission. That means:
- clarify what your own responsibilities are
- clarify what the responsibilities of the other stakeholders are
- identify who is responsible for each of the legacy systems
- if there is no client (yet) for your web application, find one who is going to use it in the future and ask for permission to incorporate him as a representative user of your system (a person you can discuss the requirements with)
- if there are different stakeholders with different goals, collect their requirements (for example, by interviewing them one-by-one, not 18 people alltogether in one room). Write the results on a list. Afterwards, start priorizing.
- write down a roadmap (the big picture) and a small spec for release 0.1 and make your boss as well as the representative client agree to it formally
- EDIT: see GlenH7`s comment
This can take a while, you will probably don't write much code at this stage of the project. In such a situation, you should do some "requirements engineering" first. But start small, think big. Once you have developed your first release, you will have something to show around, discuss requirements again with the stakeholders etc.
Best Answer
I used to work for a company where every app we gave them led to the question: Can we export this data to Excel?
After a while, I decided I had to know why they were obsessed with Excel exports for everything. It turned out that a lot of departments had one person who was an expert in Excel and could write a useful data-analysis app in no time. These apps would spread around the department like wildfire and we, the techies, had no idea they even existed.
Why didn't they come to us first? Because there was a reputation that the technical team had far too much to do and, if they did ask for it, they might (if they were lucky) get it queued up six months later.
That wasn't an unfair accusation and they never asked us to support their Excel apps, so no one really thought it was a problem. When these Excel developers left, they always managed to find someone else to pick it up.
You could argue that it meant we were prioritising incorrectly, that important work wasn't getting done. But I would argue that it freed up the more-highly-paid developers to do more difficult work. What can it hurt?
Now I would forbid software that updates the database being written outside of the development team. And I would refuse to support apps written outside of the development team. But I wouldn't try to forbid all software from being written by the business itself, and I would happily write data-exports to empower them to do so (as long as that doesn't expose data that they shouldn't see, obviously).