Liegen die Probleme, die der Artikel anspricht, nicht eher im „Verständnis-Dschungel“ als bei den Rollen?

Developer Verantwortlichkeit
Obwohl das Problem „was bedeutet Developer“ thematisiert wurde, wird im Artikel von den „klassischen Rollen“ wie z.B. Business Analysten gesprochen. Hier wird die Idee von Scrum, die „Reduktion der sozialen Komplexität“, nicht wirklich berücksichtigt: Scrum kennt nur drei Rollen; eine davon ist der Entwickler („Developer“), von der es zwischen 6 +/- 2 im Team gibt. Die Skills jedoch, die diese Developer als multifunktionales Team benötigen, sind sehr vielseitig. Da benötige es UX-Know How, Leute mit Skill in Busines Analyse, Software-Entwickler, techn. wie fachl. Tester und heute üblicherweise auch Leute, die als DevOp tätig sind. (Warum wird der „fachl. Tester“ extra genannt und sollte er kein Developer sein?)
Ein Entwickler (und hier bitte nicht „SW-Entwickler“ assoziieren!) kann viele Skills abdecken.
Wenn aber weiterhin jeder Skill der benötigt wird, als Rolle angesehen wird; und dann – so wie ich das in vielen Firmen sehe – eine Rolle eine 1:1-Beziehung zu einer Person darstellt, wundert es mich nicht, dass viele Teams
- zu groß sind („Wir brauchen doch jede Rolle und die muss doch wegen Ausfallsicherheit mehrfach besetzt sein…“)
- durch „klare Verantwortlichkeiten“ der Rollen sich schwertun, voneinander zu lernen und ein Team zu werden
- weiter als Gruppe von Experten mit vielen Schnittstellen & Übergaben nebeneinander her arbeiten
1. Fazit:
Klassisch – viele dedizierte Rollen für die Umsetzung der Projektinhalte
Scrum – eine Rolle für die Umsetzung der Projektinhalte (und nicht mehr!). Aufgabenfokus & Ergebnisverantwortung liegen bei den Developern.

PO-/SM-Verantwortlichkeit
„Reduktion der sozialen Komplexität“ findet bei Scrum auch bei den Rollen Product Owner & ScrumMaster statt. Der PO ist der „Unternehmer“ der durch seine Arbeit (Stakeholder Management, Priorisierung nach Busines-Wert, Backlog-Refinement) dafür sorgt, aus den zur Verfügung stehenden Budget den größten Nutzen zu generieren. Was soll da ein klassischer PL an „formaler Steuerung“ noch für Tätigkeiten haben. Projektfokus bzw. besser Produkt-Fokus, klarer Projektauftrag bzw. besser die Produkt Vision & die Schnittstelle zwischen Auftraggeber, den Fachbereichen und dem Projektteam sind Verantwortungen des PO. Das würde ja zu Doppelarbeiten führen und ggf. Widersprüche hervorrufen, hierfür einen PL einzusetzen. Auch würden Komplexität und unnötige Kosten erzeugen.
Und der ScrumMaster sorgt für den reibungslosen Ablauf der Prozesse; insb. für die Beseitigung von Hindernissen (Entfernung aller Motivationshemmer). So können die Developer im Flow („Schaffensrausch“) arbeiten. Auch hier: Was soll der PL noch beitragen?
2. Fazit:
Der Interessenskonflikt aus dem „Drama-Dreieck“, Time – Function – Budget einhalten zu müssen, und dazu noch „die Entwickler bei der Stange zu halten“, mit dem der klassische PL zu kämpfen hat, wird durch das Duo PO & SM aufgelöst.

Projekt- vs. Produktmanagement
Der 3. Fehler, der m.E. in der leichtfertigen Verwendung von Begrifflichkeiten liegt, ist der Begriff Projektmanagement im Agilen Kontext. Agiles Vorgehen und insb. Scrum fokussieren auf die Produktentwicklung
– iterativ, inkrementell in kurzen Zyklen mit langlebigen stabilen Teams. Kein „Big Bang“! Kein neues Team für jedes Projekt!
Umsetzungserfolg bei Agile (Nutzen für den Kunden) vs. Abwicklungserfolg bei klassischem PM (Einhaltung von Time & Budget).
3. Fazit:
Wenn man Agiles Vorgehen in den Rahmenbedingungen des klassischen PM und deren Instrumenten betreibt, verwundert es mich nicht, dass Agiles Vorgehen nicht wirklich seine Potenziale entfaltet.
Metapher: Wenn ich Autos (agile Vorgehen) auf Schienen (klassisches Vorgehen) fahren lasse, brauche ich mich nicht wundern, dass die Flexibilität des Individualverkehrs verloren geht… (Und dann hat jedes Auto noch einen Lockführer zusätzlich mit an Bord.)

Betrachtung der aufgeführten Gefahren, die durch falsche Implementierung Agiler Methoden entstehen
• „Der für die Team-Performance zuständige Scrum Master hat keine Ergebnisverantwortung und auch keinen Stakeholder-Kontakt.“
=> Gut und genau richtig so!
Um bei meiner Metapher zu bleiben: Das wäre ja sonst so, als ob das Öl im Motor für das Ziel und die Wegstrecke verantwortlich wäre…
• „Der für die Wertmaximierung zuständige Product Owner hat keinen Einfluss auf die Team-Performance (d.h. auf die Aufgabe des Scrum Masters).“
=> Auch hier: Gut und genau richtig so!
Als Fahrer meines Autos, der das Ziel bestimmt, habe ich doch keinen Einfluss auf die Leistung des Motors. Dafür habe ich Mechaniker in der Werkstätte meines Vertrauens.
• „Der Projektleiter hat weder Einfluss auf das Produkt noch auf die Team-Performance, muss aber die Budgets (und irgendwie auch das Ergebnis) verantworten.“
=> Ja & nein!
Er hat keinen Einfluss auf das Produkt: Ja! Das macht auch der PO.
Er hat keinen Einfluss auf die Team-Performance: Ja! Das macht der SM.
Er muss das Budget verantworten: Nein! Das macht der Unternehmer, der PO.

4. Fazit:
In Scrum ist die Rolle des PL obsolet!
Kaum macht man Scrum „by the Book“, hat man kein Rollendschungel …