IT-Manager müssen sich vom klassischen Hierarchiedenken verabschieden, wenn sie den Sprung in die agile Unternehmenskultur schaffen wollen.
In der agilen Welt steht das Team in Mittelpunkt. Foto: Andres Rodriguez/Fotolia.de
Die IT hat eine schlechte Reputation. Sie wird oft als zu teuer und unflexibel beschrieben. In der letzten Dekade versprach Outsourcing das Problem zu lösen und das Kosten-Nutzen-Verhältnis zu verbessern - mit fraglichen Ergebnissen. Seit ein paar Jahren bietet nun die agile Bewegung eine Alternative. Der Ansatz besteht in der Reduktion von allem unnötigen Ballast. Anwender agiler Techniken beschreiben den Ansatz als leistungsfähig und angenehm. Für Manager, die im klassischen Projekt-Management aufgewachsen sind, ist das schwer nachzuvollziehen.
Fünf Methoden für den agilen Ansatz
Fünf Gründe für den agilen Ansatz Neue Methoden der Softwareentwicklung begeistern die Mitarbeiter und die Kunden. Da stellt sich die Frage, woher es kommt, dass "Agilität" derartig beliebt ist? Alexander Ockl nennt Fünf Gründe:
Weniger Prozess - dafür mehr Mensch Offenbar haben wir gelegentlich das Prozessrad zu weit gedreht. Mit Know-how in den Prozessen wollten wir gute Software wie am Fließband im "billigen Ausland" herstellen lassen. Probleme lassen sich mit noch ausgefeilteren Prozessen und Rollen beseitigen, so dachten wir. Aber inzwischen wissen wir, dass wir am so genannten Fließband meist individuell arbeiten. Und talentierte Mitarbeiter haben auch im Ausland inzwischen ihren Preis.
Persönliche Motivation statt Existenzangst In der agilen Welt zählt der Mensch wieder etwas. Statt verteilt zu sitzen, schauen sich agile Teams wieder in die Augen. Effektive, direkte Kommunikation ersetzt endlose, anonyme Telefonkonferenzen und überlaufende E-Mail-Postkörbe. Größerer Gestaltungsspielraum und überschaubare Rollen geben Mitarbeitern das Gefühl, endlich wieder etwas bewegen zu können. Das setzt Kräfte frei. Und motiviert, anstatt zu frustrieren.
Entfaltete Stärken statt Fesseln Endlich wieder kreativ sein und nicht starre Prozesse befolgen müssen! Kein Wunder also, dass gerade Entwickler und Analysten diesen Ansatz lieben. Im agilen Umfeld sind sich alle bewusst, wie wichtig ein gut zusammengestelltes Team ist. Das übersehen wir in der "alten IT-Welt" häufig - zwischen den vielen Prozessdetails und virtuellen Teams. Unsere Kunden freuen sich auch, denn schließlich steht wieder die Lösung ihrer Probleme im Vordergrund.
Gemeinsam entwickelte Arbeitsweise Neue Prozesse bedeuten in unserem herkömmlichen Alltag häufig neue Rollen. So entstehen Teamveränderungen und Umstrukturierungen. Die vorgegebene Arbeitsweise passt aber vielfach nicht zum Team. Agile Methoden wie Scrum zeigen, dass es auch anders geht. Den "Toyota-Weg" als Vorbild, organisieren sich schlanke Teams innerhalb eines groben Rahmens am besten selbst.Es lohnt es sich, ein funktionierendes Team - wie im Fußball - nicht zu stark zu verändern. Gemeinsam entwickelt, richtet sich die Arbeitsweise nach den Möglichkeiten der Mitarbeiter.
Eine nachvollziehbare Teamleistung Schreit unser Umfeld nach Agilität, so sollten wir nicht dagegen reden, sondern genau hinschauen. Agilität und gute Prozesse wollen das Gleiche. Müssen wir dennoch verteilt arbeiten, so sollten wir unbedingt auf die menschliche Komponente achten. Frei nach Felix Magath bei der Vorstellung des Spielers Raul sollte es "unsere Verpflichtung sein", die Mitarbeiter "so in Szene zu setzen", dass Sie "ihre Fähigkeiten voll ausspielen können". Andernfalls schließt auch Raul keine Tore, sondern wird zu einem mittelmäßigen und schließlich frustrierten Mitspieler.
Was ist anders? Im Rahmen des agilen Vorgehens, insbesondere nach Scrum, arbeiten Teams weitgehend selbstorganisiert und übernehmen Verantwortung. Es gilt der Grundsatz, dass beispielsweise Aufgaben wie Planung und Steuerung am besten bei denen liegen sollten, die auch mit der Umsetzung betraut sind. Dabei wird die Planung kontinuierlich auf der Basis neuer Erkenntnisse ausgerichtet. Die hohen Freiheitsgrade agiler Teams ermöglichen effizientes Arbeiten. Im agilen Kontext gibt es keinen klassischen Projektleiter, der mittels Diagrammen das Projekt simuliert und plant. Die Planung verläuft nach agilen Prinzipien und basiert auf empirischen Fakten, wodurch sich das Risiko der Fehlplanung reduzieren lässt. Stattdessen wird das Projekt permanent am Projektziel ausgerichtet, was eine Einhaltung der Rahmenbedingungen wie Termin und Budget erleichtert. Die agile Vorgehensweise basiert auf der Erkenntnis, dass der Verlauf von Projekten, insbesondere großen, nicht ausreichend vorherzusehen ist und daher eine umfassende Vorabplanung wenig weiterhilft. Die Annahme, dass sich das Projektergebnis linear zu den eingesetzten Mitarbeitern entwickelt (Chinesen-Prinzip) ist ebenso widerlegt, da es die gruppendynamische Prozesse und äußere Einflussfaktoren nicht einbezieht.
Teams organisieren sich selbst
Der Begriff Ressourcenplanung spiegelt das zugrundeliegende maschinistische Menschenbild, nachdem Menschen wie Teile einer Maschine beliebig austauschbar sind. Zudem basiert es auf Misstrauen, das eine Überwachung und Steuerung der Mitarbeiter erfordert. Dagegen stellen agile Methoden das Team als produktive Einheit in den Mittelpunkt. Teams organisieren sich selbst und verfolgen ein gemeinsames Ziel. Die Kultur der Teamverantwortung im agilen Kontext steht in Kontrast zu den Methoden des klassischen Managements, das weitgehend hierarchisch organisiert ist. Daher entstehen an dieser Schnittstelle häufig Reibungen bei der Einführung agiler Vorgehensweisen.
Der Wert agiler Vorgehensweisen erschließt sich vor allem in der praktischen Arbeit und weniger durch die Lektüre entsprechender Publikationen. Da das Management aber in der Regel nicht in Projekten mitarbeitet, bleibt ihm diese Erfahrung verschlossen. Daher gibt es immer wieder Konflikte zwischen Mitarbeitern in den Projekten, die agile Techniken stark befürworten, und dem Management, das sich schwer vorstellen kann, wie ein Vorhaben ohne umfassende Projektleitung ablaufen soll. Zudem entsteht ein Bild der Bedrohung, wenn immer wieder Gerüchte kursieren, dass beispielsweise Projektleiter im agilen Kontext keine Zukunft haben. Diese Polemisierung ist wenig hilfreich, da sie nur der Frontenbildung dient.
Management bleibt wichtig
Es steht außer Frage, dass Aufgaben wie Planung, Steuerung und Kontrolle in Bezug auf die Unternehmensziele auch im agilen Kontext enorm wichtig bleiben. Agile Vorgehensweisen bieten hier lediglich andere Mechanismen. Die Planung wird vom Product Owner in enger Zusammenarbeit mit dem Team übernommen, die Steuerung erfolgt über kontinuierliche Velocitiy-Messungen, und empirisch belegte Terminprognosen und die Kontrolle wird durch maximale Transparenz in Verbindung mit standardisierten Charts erreicht. Diese Techniken sind vielfach bewährt, so dass sich für Scrum-Anwender meist nicht mehr die Frage stellt, ob Scrum besser funktioniert als phasengetriebene Ansätze, sondern nur, wie sich das eigene agile Vorgehen noch weiter optimieren lässt.
Die wichtigsten Methoden
ActiF Requirement-Management (RM) und Implementierung (IMP) sind ist voll abgedeckt, keine Unterstützung gibt es für Wartung (W) und Betrieb (B). Auch der Test (T) ist schwach ausgeprägt. Besser schneidet AcriF bei der Integration (INT), Projekt-Management (PM), Qualitäts-Management (QM) und Systemdesign (SD) ab.
Adaptive Software Development (ASD) ASD schneidet nur im Qualitäts-Management (QM) sehr gut ab. Disziplinen wie Integration (INT), Wartung (W), und Betrieb (B) werden überhaupt nicht abgedeckt. Projekt- und Requirement-Management (PM/RM), Systemdesign (SD), Implementierung (IMP) und Test (T) sind schwach ausgeprägt.
Agile Enterprise Agile Enterprise leistet vollständige Unterstützung in den Bereichen Projekt-Management (PM), Requirements-Management (RM), Implementierung (IMP) und Test (T). Nicht ganz so gut sieht es bei der Integration/Einführung (INT), dem Qualitäts-Management (QM) oder dem Systemdesign/technische Konzeption (SD) aus. Schwachpunkt ist die Wartung (W), für den Betrieb (B) kommt überhaupt keine Unterstützung.
Agile Model Driven Development AMDD deckt unter den Disziplinen des Software Engineering die des Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Integration/Einführung (INT), Wartung (W) und Betrieb (B) sowie für Implementierung (IMP). Auf mittlerem Niveau bewegen sich das Qualitäts-Management (QM), Requirements-Management (RM) und das Systemdesign/technische Konzeption (SD) während für Projekt-Management (PM) nur wenig Unterstützung kommt.
Behavior Driven Development Behavior Driven Development schneidet nur im Requirements-Management (RM) sehr gut ab, gefolgt vom Qualitäts-Management (QM). Keine Punkte gibt es im Bereich Wartung (W), Betrieb (B) und Projekt-Management (PM). Die Disziplinen Systemdesign (SD), Implementierung (IMP), Test (T) und Integration (INT) schwächeln.
Crystal Crystal hat seine Stärke im Bereich Test (T), auch das Qualitäts-Management (QM) und die Implementierung (IMP) werden gut abgedeckt. Mittel bis schwach ausgeprägt sind dagegen Projekt-Management (PM), Requirement-Management (RM), Integration/Einführung (INT) und Wartung (W). Keine Unterstützung gibt es für Betrieb (B) und Systemdesign/technische Konzeption (SD).
Design Driven Development D3 unterstützt nur wenige Disziplinen im Software Engineering. Am ehesten gilt dies noch für das Requirement-Management (RM), schwache Abdeckung gibt es auch in den Bereichen Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Qualitäts-Management (QM). Keine Unterstützung gibt es für Integration/Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).
Dynamic System Development Method DSDM spiel seine Stärken in den Bereichen Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Integration/Einführung (INT) aus. Weniger gut werden die Aspekte der Wartung (W), des Betriebs (B) sowie des Projekt- (PM) und Qualitäts-Managements (QM) abgedeckt.
Eclipse Way Process Aufgrund der Kombination unterschiedlicher Techniken im Eclipse Way Process ergeben sich zahlreiche Stärken. Disziplinen im Software Engineering, die vollständig abgedeckt werden, sind Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP) und Test (T). Nicht ganz so gut schneidet Integration/Einführung (INT) ab. Eine schwache Abdeckung gibt es für Wartung (W) und Qualtitäts-Management (QM), während Betrieb (B) überhaupt nicht unterstützt wird.
Evolutionary Process For Integrating Cots-Based Systems (Epic) Epic hat seine besondere Stärke im Projekt-Management (PM). Recht gut abgedeckt werden auch Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Test (T) und Integration/Einführung (INT). Mittlere Abdeckung gibt es für den Bereich Implementierung (IMP), während Wartung (W) und Betrieb (B) überhaupt keine Unterstützung finden.
Evolutionary Project Management & Product Development (EVO) Projekt-Management (PM) und Test (T) sind die Stärken des EVO-Vorgehens. Schwächer fallen Systemdesign/technische Konzeption (SD), Qualitäts-Management (QM), Requirements-Management (RM), Implementierung (IMP) und Integration/Einführung (INT) aus. Die Bereiche Wartung (W) und Betrieb (B) werden überhaupt nicht abgedeckt.
Extreme Programming Extreme Programming (XP) deckt unter den Disziplinen des Software Engineering die Implementierung (IMP) und den Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Qualitäts-Management (QM) und Requirements-Management (RM). Mittlere Abdeckung erfährt das Systemdesign/technische Konzeption (SD) sowie die Integration/Einführung (INT), während Wartung (W) und Projekt-Management (PM) nur schwach ausgeprägt sind. Der Betrieb (B) ist nicht abgebildet.
Feature Driven Development FDD deckt die Aspekte des Systemdesign/technische Konzeption (SD) vollständig ab. Nicht ganz so gut sieht es beim Projekt-Management (PM), Qualitäts-Management (QM), Requirements-Management (RM) und bei der Implementierung (IMP) aus. Wenig Abdeckung gibt es für Test (T) und Integration/Einführung (INT). Wartung (W) und Betrieb (B) werden überhaupt nicht unterstützt.
Iconix Iconix deckt die Bereiche Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign (SD), Implementierung (IMP) und Test (T) vollständig ab. Recht gut ist die Methode auch, wenn es um die Integration (INT) und das Projekt-Management (PM) geht. Defizite gibt es bei der Wartung (W), der Betrieb (B) wird überhaupt nicht berücksichtigt.
Internet-Speed Development Internet-Speed Development ist im Bereich Integration und Einführung (INT) hervorragend. Keine Abdeckung erfährt der Bereich Wartung (W) und Qualitäts-Management (QM). Mäßige bis gute Abdeckung erzielt die Methode bei Betrieb (B), Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP) und Test (T).
Lean Software Development Lean Software Development zeigt seine Stärken vor allem in den Bereichen Qualitäts-Management (QM) und Test (T). Auch das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) sind gut abgedeckt. Vergleichsweise schwach ausgeprägt sind dagegen die Bereiche Requirements-Management (RM), Integration und Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).
Microsoft Solutions Framework (MSF) Das Microsoft Solutions Framework for Agile Software Development deckt die Bereiche Projekt-Management (PM), Implementierung (IMP) und Test (T) gut ab. Mittlere Unterstützung gibt es für Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD)sowie Integration/Einführung (INT). Wartung (W) und Betrieb (B) erfahren dagegen keine Abdeckung.
Mobile-D Gute bis mittlere Abdeckung bietet Mobile-D für die Software-Engineering-Disziplinen Test (T), Implementierung (IMP), Requirements-Management (RM), Qualitäts-Management (QM) und Projekt-Management (PM). Schwach ausgeprägt sind Systemdesign/technische Konzeption (SD) und Integration/Einführung (INT). Keine Unterstützung gibt es für Wartung (W) und Betrieb (B).
Rapid Application Development RAD deckt die Belange der Implementierung (IMP) voll ab, gut ist die Methode in den Bereichen Test (T) und Integration/Einführung (INT). Mittlere bis schwache Abdeckung gibt es fürs Requirements-Management (RM), Qualitäts-Management (QM), Projekt-Management (PM) und für die Wartung (W). Systemdesign/technische Konzeption (SD) und Betrieb (B) sind nicht berücksichtigt.
Scrum Scrum punktet in den Software-Engineering-Disziplinen Projekt-Management (PM) und Requirements-Management (RM). Gut abgedeckt sind auch das Qualitäts-Management (QM) und die Integration/Einführung (INT). Nur mäßige Unterstützung gibt es dagegen für Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Wartung (W). Der Betrieb (B) ist nicht abgedeckt.
Test Driven Development Seine Stärken zeigt TDD naturgemäß im Bereich Test (T), aber auch bei der Implementierung (IMP). Gute bis mittlere Abdeckung gibt es für das Qualitäts-Management (QM) und die Integration/Einführung (INT), während Wartung (W) und Requirements-Management (RM) nur schwach ausgeprägt sind. Keine Unterstützung erfahren die Disziplinen Betrieb (B), Projekt-Management (PM) sowie Systemdesign und technische Konzeption (SD).
Unified Process Unter den Disziplinen im Software Engineering deckt UP das Requirements-Management (RM), das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Test (T) und Integration/Einführung (INT). Schwach ausgeprägt sind dagegen die Wartung (W), das Projekt-Management (PM) und das Qualitäts-Management (QM). Den Betrieb (B) unterstützt die Methode nicht.
Agile Unified Process Der Agile Unified Process (AUP) deckt die Disziplinen Projekt-Management (PM) und Implementierung (IMP) vollständig ab. Gute Unterstützung kommt auch für das Requirements-Management (RM), das Systemdesign/technische Konzeption (SD), den Test (T) und die Integration/Einführung (INT). Schwach ist die Methode dagegen in den Bereichen Qualitäts-Management (QM) und Wartung (W), während der Betrieb (B) überhaupt nicht unterstützt wird.
Essential Unified Process EssUP hat seine Stärken in den Software-Engineering-Disziplinen Projekt-Management (PM), Systemdesign/technische Konzeption (SD) und Implementierung (IMP). Gut abgedeckt sind auch Test (T), Integration/Einführung (INT) und Requirements-Management (RM). Etwas schwächer ist die Methode beim Qualitäts-Management (QM) und bei der Wartung (W) - der Betrieb (B) wird überhaupt nicht unterstützt.
Open Unified Process Der Open Unified Process deckt die Software-Engineering-Disziplinen Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD) und Implementierung (IMP) vollständig ab. Auch die Bereiche Test (T) und Integration/Einführung (INT) werden gut unterstützt. Schwach ist OpenUP dagegen bei der Wartung (W), während der Betrieb (B) überhaupt nicht berücksichtigt wird.
Usability Driven Development Usability Driven Development besitzt seine Stärken in den Bereichen Test (T) und Integration/Einführung (INT). Gut bis befriedigend ist die Methode auch beim Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), bei der Implementierung (IMP) und beim Projekt-Management (PM). Schwächen gibt es bei der Wartung (W), der Betrieb (B) wird nicht unterstützt.
Dem Management kommen im agilen Kontext eher unterstützende Aufgaben zu, beispielsweise wenn es darum geht, Hindernisse zu beseitigen und zeitnahe Entscheidungen der Geschäftsleitung zu erwirken. Reporting, Budget-Planung sowie die Koordination verschiedener agiler Initiativen gehören ebenso zum Aufgabenspektrum. Autorität entsteht weniger durch Hierarchie, sondern durch vorbildliches Verhalten und persönliche Anerkennung. Positive Fehlerkultur bildet das Fundament für vertrauensvolle Zusammenarbeit zwischen Projektteams und Mitarbeitern.
Diese Sicht entspricht oft nicht dem Selbstverständnis des Managements. Am ehesten findet man sie im Mittelstand, wenn Inhaber vertrauensvoll mit ihren Mitarbeitern zusammenarbeiten. Wenn agile Praktiken eine Produktivitätssteigerung und mehr Flexibilität entfalten sollen, ist es unabdingbar, dieses Selbstverständnis zu überdenken.
Agile Kultur - aber wie?
Für die Verankerung agiler Techniken in einer Organisation bedarf es eines strukturierten Change-Prozesses. Dieser hilft Vorurteile abzubauen und die Intentionen des agilen Ansatzes zu erklären und zu verbreiten. Er stellt das agile und das klassische Rollenmodell gegenüber und eröffnet Perspektiven für alle Beteiligten. Für eine nachhaltige Einführung muss das Management die agilen Prinzipien verinnerlichen und leben. Da die Unternehmenskultur stark durch Vorbilder geprägt ist, kommt dem Management sogar eine besondere Bedeutung zu.
Scrum-Glossar
Kleines Scrum-Glossar Was meint eigentlich Scrum, Product Owner oder Backlog? Wir stellen Ihnen die wichtigsten Begriffe und ihre Bedeutung vor.
Scrum Der Begriff stammt aus dem Rugby und bedeutet wörtliche "Gedränge". In der Softwareentwicklung bezeichnet er ein Vorgehensmodell der agilen Softwareentwicklung, das 1995 von Ken Schwaber, Jeff Sutherland und Mike Beedle veröffentlicht wurde.
Das Scrum-Team Aufgabe des Teams ist es, die Anforderungen der Fachabteilung umzusetzen. Es bietet drei Rollen:
1. Rolle: Product Owner Er vertritt den Auftraggeber, also die fachliche Seite. Also zeichnet er für die Priorisierung der Anforderungen verantwortlich und letztlich auch für den Nutzen, den das Projekt dem Unternehmen bringt.
2. Rolle: Scrum-Master Er ist quasi der Herr über die Prozesse. Er sorgt dafür, dass die Scrum-Regeln im Projekt eingehalten werden, er fördert die Transparenz, unterstützt das Team bei der Beseitigung von Hindernissen und sucht ständig nach möglichen Verbesserungen.
3. Rolle: Die Entwicklergruppe Sie besteht idealerweise aus sieben Entwicklern.
Sprint Mit diesem Begriff bezeichnet Scrum einen Iterationszyklus, innerhalb dessen ein Scrum-Teams eine Anforderung umsetzt. Ein Sprint dauert mindestens zwei Wochen und maximal einen Monat.
Backlog So heißt in Scrum die priorisierte Anforderungsliste für das zu entwickelnde Produkt. Sie wird vom Product Owner verantwortet und gepflegt.
Definitionen von fertig Dabei handelt es sich um die Kriterien, unter den ein Produkt als umgesetzt akzeptiert wird.
Daher ist es erforderlich, das Rollenverständnis und die Erwartungen auch des Managements zu verändern. Das Gelingen eines solchen Vorhabens hängt stark von der Ausgangslage in Form der existierenden Unternehmenskultur ab. Dabei haben es Organisationen leichter, die offen für Veränderung sind und Zweifel an klassischen, kontrollbasierenden Management-Techniken haben. Diese Zweifel basieren in der Regel auf Erfahrungswissen, das bei der Umsetzung von Projekten in der Vergangenheit entstanden ist. Organisationen, die stark an klassische Management-Techniken glauben und wenig offen für Veränderungen sind, tun sich mit agiler Evolution schwer.
Bei der Bildung von Scrum-Teams gelten Befähigung und Motivation als wichtige Voraussetzungen für die Teamzusammensetzung. Das gilt auch für die Mitarbeiter des Managements. Ohne die aktive Mitarbeit der Chefs ist es kaum möglich, agile Techniken nachhaltig einzuführen. Wissensvermittlung auf allen Organisationsebenen ist der Schlüssel zum Erfolg. Erfahrene externe Coaches können helfen, agile Werte zu vermitteln und die Unterschiede und Gemeinsamkeiten zwischen klassischem und agilem Management deutlich zu machen.
Damit das Engagement kein Lippenbekenntnis bleibt, sollte sich das veränderte Rollenverständnis in Stellenbeschreibungen und Zielvereinbarungen wiederfinden. Die Ernsthaftigkeit der agilen Ausrichtung erreicht ein Unternehmen etwa durch ein offizielles Bekenntnis zu agilen Techniken. Dafür ist ein Mandat seitens der Geschäftsführung erforderlich. Die Etablierung einer agilen Unternehmenskultur ist ein evolutionärer Prozess, der einer ständigen Begleitung und Ausrichtung bedarf.
Agile Ansätze entfalten ihre volle Wirkung, wenn ein Unternehmen sie ganzheitlich anwendet und sie in die gesamte Produktionskette einbezieht. Am Ende geht es darum, alle Beteiligten von der Fachseite über Entwicklung, Management, Qualitätssicherung bis zum Betrieb auf das gemeinsame Ziel zu verpflichten, das darin besteht, qualitativ hochwertige Software in kürzester Zeit produktiv bereit zu stellen. Wenn das gelingt, wird die IT wieder als Unterstützer der Fachabteilungen wahrgenommen. Agile Vorgehensweisen und Techniken bieten dazu ein enormes Potenzial. Entscheidend ist, ob es gelingt eine agile Kultur nachhaltig im Unternehmen zu verankern. Weiterbildung auf allen Ebenen ist der Schlüssel dazu.
*Wolfgang Pleus ist freiberuflicher IT- und Methodenberater.