Ich habe seit längerem bereits keine Beiträge mehr verfasst. Das soll sich nun wieder ändern. Allerdings steige ich hier nur mit einem Verweis auf eine Präsentation von Xing ein, die Traian Kaiser und Mark Weber zum SCRUM Day 2009 vorgestellt haben. Der Informationsgehalt ist ohne Tonspur nicht allzu groß, aber sehenswert ist sie dennoch.
Auf dem Xing Blog habe ich drei Artikel gefunden, in denen Traian Kaiser über die Einführung von Scrum berichtet.
Hintergrund dabei ist natürlich, die damit verbundene Möglichkeit, Kundenwünsche zeitnah umzusetzen und die Ship It!-Strategie besser verfolgen zu können.
Das größte Hindernis bei der Einführung von Scrum bestand wohl darin, die agilen Werte richtig zu kommunizieren und die neuen Rollen den vorherrschenden Jobbeschreibungen zuzuordnen.
Das benötigte Wissen haben die Projektmanager und einige Lead Engineers durch Scrum-Trainings erhalten. Traian Kaiser beschreibt weiter, dass die Prozesse im Unternehmen und der Ablauf der Produktentwicklung angepasst werden mussten - sich die Umstellung aber insgesamt gelohnt hat, und sie nun für die Zukunft gerüstet sind.
So kann also eine Scum-Einführung in einem Unternehmen aussehen. Die beschriebenen Hindernisse, wie das Verinnerlichen der agilen Werte, ist sicherlich eine der größten Herausforderungen für ein Unternehmen, welches nach Scrum arbeiten möchte. Ich habe die Erfahrung gemacht, dass es tatsächlich schwierig ist Scum in Reinform anzuwenden. Daher bediene ich mich vereinzelter Konzepte von Scrum und nenne es Scrumish 
Die Artikel sind alle mal lesenswert und zeigen, dass es nicht so einfach ist, Scrum unternehmensweit einzuführen.
Agile Softwareentwicklung scheint nun endlich aus den Kinderschuhen zu sein. Wenn selbst eine Firme wie Microsoft sich bei der Entwicklung von Windows 7 auf dieses Vorgehen festlegt. So ist es derzeit bei Spiegel-Online nachzulesen. Die Redmonder setzten vor drei Jahren auf das Thema Extreme Programming und versuchten dadurch die Fehler der Vergangenheit zu vermeiden.
So ist Microsoft neben Google und ebay ein weiteres großes Unternehmen, das auf Agilität in der Softwareentwicklung setzt. Dass ich ein großer Freund von Agilen Methoden bin, hat der ein oder andere vielleicht bereits bemerkt. Für mich der Schlüssel zu guter Software, da wir uns in kleinen Schritten dem Ziel nähern. Leider kenne ich aber immer noch Unternehmen, die strikt nach den Phasen der Softwareentwicklung (Analyse, Design, Realisierung und Test) eine SAP-Einführung planen.
Das große Problem dabei entsteht, durch die Aussicht alles Technische umsetzen zu können und die Softwareentwicklung wie den Bau eines Hauses zu sehen. Zumindest hat Microsoft damit eine weitere Lanze für agile Softwareentwicklung gebrochen. Ich hoffe andere Unternehmen folgen dem Beispiel und lassen die Phasenmodelle dort wo sie hingehören – in die 70er und 80er.
Eben erst hatte ich Zeit mir die neue iX anzusehen und mir spring sofort der Artikel auf Seite 110 in die Augen. Ein Beitrag über agile Softwareentwicklung speziell mit Scrum - insgesamt lesenswert. Was mir aber besonders gefallen hat, ist die Liste der Scrum-Anti-Patterns:
Diese Liste ist bei weitem noch nicht vollständig. Mir fallen da spontan noch ein paar Ding wie „Bug-fix Sprints“ oder die aktive Beteiligung des Management am Daily Scrum ein.
Fallen Ihnen vielleicht noch ein paar schöne Scrum-Anti-Patterns ein? Ich bin gespannt.
(Bildquelle: Stock Exchange, johnmckeag)
Jens Coldewey beschreibt in seinem Artikel “Certified Scrum Developer und implizites Wissen” sehr anschaulich wie implizites Wissen eigentlich aufgebaut wird und welche Gefahren in Zertifizierungen von Programmierern lauern.
Er geht davon aus, dass das der Erfolg von Scrum auch zum Teil auf den Zertifizierungen der Scrum-Alliance beruht, was ich genau so sehe. Weiterhin geht er davon aus, dass ein unfähiger Scrum Master nicht so großen Schaden im Projekt anrichten kann wie es die nicht so talentierten Programmierer könnten. Dieser Schaden könnte dann auf die Scrum-Zertifizierungen oder gar Scrum zurückfallen.
Dies hat mich dazu bewegt mich mit dem Thema nochmals auseinanderzusetzen. Tatsächlich sehe ich es auch so, dass schlechter Code das Projekt weit zurückwerfen kann, nämlich genau dann wenn der Programmierer aufgrund seiner Leistungen (meist wird ein anderer Grund gefunden) aus dem Projekt ausscheidet und die verbleibenden oder nachfolgenden Programmierer ein Refactoring durchführen müssen.
Faktisch habe ich in meinem Studium ebenfalls erlebt, dass einigen Professoren die Meinung vertreten: “Programmieren ist Sekretärinnen Arbeit.” Insgesamt kommt es aber sicherlich auf das Projekt und das Umfeld an. Ich habe Programmierer kennen gelernt, die nicht mehr geleistet haben als fertige Konzepte in Code zu gießen.
Da wir uns hier aber in agilen Projekten bewegen, werden solche Programmierer sicherlich nicht daran beteiligt sein.
Dass Programmieren als niedere Tätigkeit angesehen wird, liegt einerseits an den Hochschulen, die es so lehren, andererseits aber auch an den Unternehmen, die diese “homogene Tätigkeit” in Niedriglohnländer verlegen.
Für mich entscheidend liegt es aber auch an den Programmierern selbst, die wie Administratoren ihre Tätigkeiten nicht angemessen kommunizieren und zu wenig Eigenmarketing betreiben. So werden IT-Spezialisten von den Fachabteilungen häufig als arrogant und überheblich angesehen. Da man sich nicht mit den “Standard Nerds” auseinandersetzen möchte, wird deren Tätigkeit eben degradiert.
Also, Informatiker aller Länder redet mehr mit anderen Menschen!
(Bildquelle: Stock Exchange, Zela)
