Welcome to the real world - I have seen what you are describing to a higher or lesser degree in all agile or not-so-agile teams I have ever come in contact with.
The thing is - and devs can be awfully short-sighted about this - that with good people, this will just work splendidly. Too splendidly, in fact.
All is well until one of your key persons (and eventually, all of them will be a key person for one topic or another) goes away. People do tend to take vacations eventually; they do get ill; they do leave companies or eventually die.
Yes, Scrum and other agile processes often are sold to dev teams with the reasoning that they protect the team from outside harm (i.e., stakeholders telling them directly what to do), but that is not the only reason they are there. Knowledge sharing is a big other aspect. This is achieved by:
- Tracking stories in a meaningful way, with lots of details in written form in the story-tracking system.
- Keeping meaningful DODs which include a strong "documentation" aspect (either in the form of significant amounts of tests which then serve as documentation-as-code; or in the form of exceptionally well-structured code in itself; and/or in the form of written documentation in a CMS separate from the stories).
- Very importantly: not having stories assigned to individuals all the time, but having a meaningful rotation capability - i.e. it should be the norm that each story should have more than one person in the team who has a reasonable chance to implement it.
In a team of senior experts as you describe, these three points tend to nil.
In my experience, these teams either continue happily like this until something happens to one of them, and then lamentation ensues. Or a product owner or Scrum master (or however the role is called) appears who puts a strong focus on the process.
I would suggest this:
- Pick one agile process that you like and which fits the product or service you are responsible for. I use Scrum for this answer just as an example.
- Step by step, pick "artifacts" from that process, and implement them on top of whatever you have - if applicable, replacing whatever is in place now. The following is the usual aspects you are used to if you are familiar with agile, just a little reframed for the issue at hand. For example, if you pick Scrum:
- Create a daily standup if you do not have one yet. If you already have one, and if it is the usual half hour where just "anything" is discussed with no measure whatsoever, focus on changing it to the 30-45s per person, "have done - will do - impediment" format, postponing all further discussion to separate sessions afterwards.
- Introduce weekly refinement sessions with the team separately from the Sprint Review / Sprint Planning artifacts, to work on speccing out the stories for the next sprint.
- Tighten down review/planning sessions; i.e. if you had sprints before, and if the planning session was just a random mess, order it in a way where you do all the review in the first half - then consciously close the current sprint - then focus on the planning part.
- During planning, really make sure that everybody who even is in the slightest technically able to takes part in estimations, to avoid individuals just "owning" their stories right from the get-go.
- It may be OK to have names next to stories in the planning meeting already; but make sure that the implication of this does not necessarily mean that this person is the one implementing the story, but that it only means that this person is responsible for it - they must either implement it by the end of the sprint, or they must take care that someone else does it. If this does not useful, then leave the names off.
- For each story, ask yourself or the team who can implement it, and if it is only one person, consciously find ways to bring at least one other person up to the task. This will drop overall speed, but this is to be accepted - know-how-sharing is sacrosanct and trumps basically everything else. Make sure that the product owner protects the team from outside influence (stakeholders complaining about reduced speed).
- Really stress that the team focusses on finishing things at the end of the sprint; and don't regularly let uncompleted tasks slip through. This is an indication that stories were not cut correctly; which then makes it harder for other people not that familiar with the topic to jump in.
- Use formal Pull Requests and enforce that the code reviews actually happen (a good metric is to look for any comments - a PR with no comment at all is a bad PR...).
- Make sure to occasionally do retrospection meetings. In my experience, I would not even start to do them right at the beginning if your team is not used to them. Give it about 2-3 sprints, and then do a retro, so they have something to think about.
- Having a professional Scrum master can be incredibly powerful. They should know how to do these sessions (especially retros) in a creative, thought-provoking an efficient way. They are also out of the power hierarchy, so can really focus on moderating meetings if things get out of hand.
That's the "what". As to "how" to do all this: just do it. Tell them that this is the way it works now. Of course, if you are more of a lenient, cooperative person, which it looks like by your question, you can help matters by picking the easier measures first. Order does not matter that much, in the end. But still be firm about it. They will get used to it; if you do it right (assuming you have your agile process down correctly yourself) they will eventually see a benefit, or at least grudgingly take part. Feel free to optimize everything as much as humanly possible, don't waste their time with useless meetings; a long meeting which is chaos will be more useless than a shorter one which is strictly moderated.
Try to have a bit of fun too, and good luck!