In einem Projekt werden die einzelnen Themengebiete in sinnvolle Teilaspekte (Teilprojekte) gegliedert. Nehmen wir ein fiktives Projekt an, bei dem folgende Themengebiete erkannt und als Teilprojekte bearbeitet werden sollen:

• Infrastruktur Setup
• Operational Management Setup
• Applikationsentwicklung

Einsatz eines traditionellen Projektvorgehens

Für das Infrastruktur Setup und das Operational Management Setup kann es durchaus Sinn ergeben ein traditionelles Projektvorgehen einzusetzen. So kann es vorkommen, dass ein normales Wasserfallvorgehen für die Erarbeitung der Lieferobjekte in diesem Bereich eingesetzt wird.

• Projektphasen mit Meilensteinen im Wasserfallmodell

In unserem Beispiel erhalten wir so einen Projektverlauf mit sechs Meilensteinen (M1-M6) an denen jeweils das Ende einer Projektphase markiert ist. Die Lieferergebnisse, die pro Meilenstein erreicht werden müssen, sind sauber beschrieben und können im Gesamtprojekt entsprechend überwacht werden.

Scrum für die Applikationsentwicklung

Bei der Applikationsentwicklung sind zu Projektbeginn noch nicht alle Anforderungen von allen Beteiligten richtig und vollständig beschrieben, bekannt und verstanden. Es ist mit vielen Änderungen zu rechnen. Den kompletten Projektscope zu beschreiben würde eine sehr teure Vor-, Grob- und Detailstudie erfordern.

Und selbst nach einer solchen Studie sind wir noch nicht sicher, dass alle Anforderungen bekannt sind. Während der Projektlaufzeit ändern sich die äußeren Bedingungen, neue Anforderungen kommen hinzu und bestehende Anforderungen werden nicht mehr benötigt. Es wäre somit vernünftig, eine agile Vorgehensweise für dieses Teilprojekt einzusetzen. Das entsprechende Projektvorgehen ist in folgender Skizze erläutert.

• Projektvorgehen nur mit SCRUM

Was beim Wasserfallvorgehen als Vorstudie bezeichnet wurde, kann bei SCRUM als Vision verstanden werden. Es wird grob beschrieben, was mit dem System erreicht werden soll. Danach werden mehrere Sprints durchgeführt, die immer dem gleichen Muster folgen.

• Sprint Planungsmeeting 1 und 2 um den Umfang und die Qualität der Lieferergebnisse festzulegen
• Development mit Daily-Scrum-Meetings um jeden Tag schnell auf auftretende Schwierigkeiten reagieren zu können
• Sprint Release stellt einen neuen Applikationsrelease zur Verfügung der vom Kunden bereits verwendet werden kann. Falls, wie in unserem Beispiel, die Infrastruktur noch nicht bereit steht, kann dieser Release für die Integrationstests verwendet werden.
• Sprint Retrospektive liefert das Feedback um festlegen zu können, was in diesem Sprint gut lief und was verbessert werden soll.

Dieser Zyklus wiederholt sich bis alle vom Kunden tatsächich benötigten Elemente umgesetzt worden sind. Nach jedem Sprint kann der Kunde mit dem lauffähigen Release sehen ob er die Software erhält, die er wirklich benötigt und kann sein Feedback liefern um Änderungen am System zu erreichen.

Scrum in das Gesamtprojekt einbinden

Die hier gezeigte Vorgehensweise lässt sich sehr elegant in das Gesamtprojekt einbinden.

• Es muss dafür gesorgt werden, dass die einzelnen Sprintzyklen mit den Meilensteinen des Wasserfallvorgehens übereinstimmen.
• Weiterhin muss erreicht werden, dass die Lieferobjekte des Wasserfallmodells mit den einzelnen Releases der Sprints in Einklang gebracht werden können.

Das klingt komplizierter als es ist. In den ersten Releases einer Applikationsentwicklung wird die Architektur erstellt, die Umsetzungsrichtlinien festgelegt und die einzusetzenden Tools und Libraries definiert. Weiterhin kann in den ersten Releases schon gut erkannt werden, wie das Zielsystem aussehen wird. Diese Erkenntnisse können als Vor- und Grobstudie angesehen werden.

Nach weiteren Sprints ist sichergestellt, dass die Detaildokumentation erarbeitet wurde. Bei Scrum besteht die Devise, dass der Code die Dokumentation ist. Aus dem Code kann mit Reverse-Engineering und der Beschreibung der wichtigsten Architekturkonzepte durchaus eine sinnvolle Dokumentation erstellt werden.
Für die Planung im Projekt ergibt sich somit folgende Vorgehensweise:

• Gesamtprozess der Projektvorgehensweise

Die Sprints werden auf die einzelnen Projektphasen aufgeteilt.
Nach der Vorstudie steht schon ein erster Prototyp zur Verfügung, mit dessen Hilfe die Grobstudie zusammen mit dem Kunden erarbeitet werden kann. Jederzeit kann auf Änderungen und Schwierigkeiten Einfluss genommen werden.

Falls ein Standard-Sprintzyklus sich nicht mit den Meilensteinen vereinbaren lässt, kann man entweder längere Sprints durchführen, oder die Sprints verkürzen (Siehe die „S“ Sprints). Unsere Sprints lassen sich vom Schwerpunkt her den einzelnen Projektphasen zuordnen.

• So kann dafür Sorge getragen werden, dass nach der Vorstudie eine Vision und ein erster architektonischer Prototyp steht.
• Nach der Grobstudie sind erste Businessprozesse umgesetzt und können während der Detailstudie verfeinert werden.
• Bei der Implementation kann die Integration der Applikation in die Infrastrukturkomponenten und operationellen Prozesse angegangen werden.
• Bei den abschließenden Tests sind die Applikationskomponenten bereits getestet und es geht vor allem um die Integration in die Systemumgebung.
• Die Transition kann dazu verwendet werden, abschließende Änderungen einzupflegen oder die Übergabe an den Betrieb zu managen.

Die Schwerpunkte der einzelnen Sprints sind in der folgenden Grafik angedeutet.

• Scrumprozess in den Farben des Wasserfallvorgehens

Durch die Übernahme der Farben aus dem Wasserfallvorgehen werden die Schwerpunkte des Gesamtprojekts auf das Teilprojekt übertragen. Die Entwickler können sich in den Projektphasen wiederfinden.

Fazit

Mit dieser Vorgehensweise ändert sich für die beiden Welten (Scrum und Wasserfall) sehr wenig. Die einzelnen Projektbereiche können miteinander kommunizieren und wir erhalten uns die einfache Rapportierbarkeit des Wasserfallmodells und die Agilität von Scrum.

Ähnliche Beiträge

Die Idee

Zuerst braucht es eine Idee, die bei Scrum Vision genannt wird.
Der Product Owner nimmt diese Idee und beschreibt die daraus resultierenden Requirements, oder auf Deutsch Anforderungen.

Mit den Anforderungen kann die Entwicklung das gewünschte Produkt erstellen.

Nach der Entwicklung ist das Produkt bereit.
Soweit so gut.
Doch im rauhem Leben gibt es Störungen.

Der Product Owner schreibt seine Anforderungen im Product Backlog nieder.
Er weiß nicht alles oder er formuliert es in einer Form die von den Entwicklern nicht verstanden wird.
Wir haben also eine Fehlerquelle.

Die Entwickler werden beim Umsetzen ebenfalls auf Fehler stoßen.
Sie werden Dinge falsch interpretieren, Kundenwünsche nicht verstehen oder schlicht Entwicklungsfehler haben.

Zu guter letzt werden die Kunden Änderungswünsche am Produkt haben. Wenn die Entwicklung zum Beispiel zwei Jahre dauert, wird sich der Markt verändern.

Wir müssen somit die Entwicklung überwachen und die Änderungen im Product Backlog vermerken. Wir müssen auf Änderungen und Fehler zeitnah reagieren.
Wir benötigen also ein Framework, dass auf Änderungen schnell reagieren kann.
Wir müssen eine Umgebung schaffen, die Fehlertolerant ist.
Also erstellen wir einen Regelkreislauf der uns erlaubt, schnell auf Fehler und Änderungen zu reagieren.
Zuerst überwachen wir unsere Entwicklung. Wir gehen in Sprints vor und kontrollieren mit den Daily Scrums wo wir stehen und was wir verbessern müssen.

Und wir müssen die Änderungen von der Produktseite her zurückführen.

Jetzt haben wir einen Regelkreis, der uns erlaubt während der Entwicklung schnell auf Störungen zu reagieren und auf Marktänderungen und Kundenanforderungen schnell zu reagieren.
Und ich habe jetzt einen Krampf im Daumen vom Tippen auf diesem IPhone.

Ähnliche Beiträge

Und wieso gehe ich heute zum Kurs?

Ich verspreche mir von dem Kurs, dass ich die Feinheiten und die Philosophie von Scrum mehr verstehe.
Bei meinem Projekt arbeite ich als Scrum Master. Ich möchte die Besonderheiten und Integrationsmöglichkeiten sowie die Grenzen von Scrum mehr verstehen.
Damit habe ich ziemlich hohe Anforderungen an den Kursleiter
Wenn ich Kurse gebe haben die Teilnehmer auch hohe Anforderungen…
Also bin ich auch mal so

Meine ersten Erkentnisse vom Einsatz von Scrum

Wir befinden uns im ersten Sprint.
Was mir bei agilen Methoden sehr gefällt ist, dass das Team entscheidet wie es gemacht werden soll.
Das kommt mir sehr entgegen, da ich immer versuche die Experten entscheiden zu lassen. Ich halte es für unsinnig erwachsene Profis zu bevormunden. Die können die Entscheidungen viel besser treffen.
Ich helfe lieber, anstehende Probleme und Koordinationsschwierigkeiten aus dem Weg zu räumen.
Und Scrum zwingt das Team dazu Eigenverantwortung zu übernehmen.
Das ist für viele Entwickler neu und ungewohnt. Sie sind ziemlich erschrocken als ich sie planen ließ und nur noch fragte, ob sie sich das alles in einem Monat zutrauen:)
Aber sie sind nun gut unterwegs und managen sich selbst.
Jetzt bin ich mal gespannt ob der Kurs mich weiter bringt.
Ich werde es euch erzählen. Wozu hat man sonst ein IPhone?

Ähnliche Beiträge

Meine Problemstellung

Wenn man im Operations arbeitet, hat man unter anderem folgende Charakteristik von Arbeitsabläufen:

Schichtbetrieb

Die unterschiedlichen Teams müssen häufig in einem Schichtbetrieb (7*24h) oder on Call usw. arbeiten. Das bedeutet, dass man z.B. für eine Aufgabe wie Serverbetrieb grundsätzlich 5 Personen benötigt um einen 7*24h Betrieb abdecken zu können.

Viele unterschiedliche, wiederkehrenden Aufgaben

Ein Mitarbeiter im Operations muss z.B. jeden Abend ein Backup anfertigen, jeden Monat Security Patches einspielen usw. Diese Aufgaben sind planbar und müssen nach einem bestimmten Muster ohne Unterbrechung durchgeführt werden. Will heißen, bei einem Projekt darf deswegen nicht der Betrieb vernachlässigt werden.

Sporadische nicht planbare Aktionen

Wenn dann doch mal ein Fehler auftritt, eine Sicherheitslücke entsteht, oder eine Hardware stirbt, muss sofort gehandelt werden. Mitarbeiter, die gleichzeitig in Projekten arbeiten sollen, können ihre Aufgaben im Projekt somit nicht wahrnehmen.

Aus diesen Charakteristiken kann man ein paar Eigenschaften der Betriebsmitarbeiter ableiten:

Hochspezialisierte Mitarbeiter

Es ist kaum möglich einen Windows und Unix Server von ein- und der selben Person betreiben zu lassen. Somit müssen mehrere Teams (Netzwerk, Storage, Windows, Citrix, Mail, Unix, DB usw.) aufgebaut und permanent geschult werden.

Leerlauf vorhanden

Wenn die Teams richtig dimensioniert sind, wird es Leerläufe geben. Etwas Überkapazität ist notwendig, damit im Fehlerfall schnell reagiert werden kann. Zudem kommt noch, dass Mitarbeiter Urlaub, Krankheit, Kurse usw. haben und somit nicht 100% verplant werden können.

Wissen ist auf viele Personen verteilt

In großen Firmen ist das Wissen über die einzelnen Applikationen auf mehrere Personen verteilt. Wenn z.B. eine Migration einer Applikation durchgeführt werden muss, kann es sein dass 20% von einem Applikationsverantwortlichen, 10% eines Server-Menschen, 10% vom Netzwerk und 50% eines Engineers benötigt werden. Die Zuteilung einer einzelnen Person zu einem Projekt ist nicht sinnvoll, da das Wissen nicht von einer Person abgedeckt werden kann.

Herausforderungen für den Projekt Setup

Stellt euch jetzt mal vor, ihr habt ein dickes Projekt geangelt und müsst z.B. 8000 Personentage Aufwand in einem Jahr erbringen. Eure Abteilungen sind mit Operations beschäftigt. Ihr wollt jedoch ein paar Dinge erreichen:

Mitarbeit der Betriebsmitarbeiter im Projekt

Ihr wollt vermeiden, dass die Betriebsaspekte im Projekt nicht betrachtet werden. Vielleicht kennt ihr das ja. Ein Projekt erstellt die neue Systemlandschaft und übergibt diese innerhalb einer Woche an den Betrieb. Der Betrieb kennt sich mit der neuen Systemlandschaft nicht aus und es entstehen Folgeprojekte um die Nichtbetreibbarkeit der Systeme zu korrigieren. Die Kosten explodieren und die Projektteams und die Betriebsmitarbeiter sind unzufrieden. Man nennt es auch “Die Lieferobjekte über den Zaun werfen”. Damit die Betriebsbelange von Anfang an Beachtung finden, wollen wir also die Betriebsmitarbeiter mit einbeziehen. Dummerweise arbeiten die aber am Daily Business und interessieren sich wenig für neue Systemlandschaften. Also sollen sie dediziert dem Projekt zugeordnet werden. Und schon haben wir das Dilema, da die einzelnen Mitarbeiter nur Teilaspekte des Betriebs abdecken können…

Regulärer Betrieb muss gewährleistet bleiben

Während die internen Mitarbeiter im 8000 Personentage Projekt mitarbeiten, muss jemand anderes die Standardaufgaben durchführen. Also können externe Mitarbeiter organisiert werden die die bestehende Landschaft weiter betreiben. Das Spezial Know How der internen Mitarbeiter muss an die externen Kollegen übergeben werden. Dies kostet vor dem Projekt Zeit und Aufwand. Und nach dem Projekt muss das Know How der externen Mitarbeiter wieder an die Internen übergehen. Also entsteht hier nochmals Aufwand.

Projekt benötigt stabiles Kernteam

Trotz allem ergibt es meiner Meinung nach keinen Sinn, ein 8000 Personentage Projekt nur mit der Nutzung der Matrixorganisation durchzuführen. Der Projektleiter muss für jeden Auftrag hinter den Mitarbeitern herrennen und benötigt einen unglaublich hohen Aufwand für die Verwaltung des Arbeitsfortschritts. Das Projekt wird deutlich länger dauern und die Lieferobjekte können kaum realisiert werden.

Und da waren sie wieder, unsere Probleme.
Ein Großprojekt sollte, laut Lehrbuch, in einer Projektorganisation durchgeführt werden.
Die internen Mitarbeiter müssen ihr Firmenspezifisches Know How einbringen und sollten daher für die Projektlaufzeit im Projekt verfügbar sein. Sie können jedoch nicht gleichzeitig den geordneten Betrieb aufrecht erhalten.
Eine Idee für die Lösung dieses Dilemas könnte sein:

Rotation der Mitarbeiter zwischen Projekt und Betrieb

Die Mitarbeiter werden nicht für die ganze Projektlaufzeit (z.B. für ein Jahr) aus dem Betrieb “gerissen”. Sie werden Beispielsweise nur für drei Monate dem Projekt zugeteilt. In dieser Zeit kann das Projekt das spezifische Wissen der Personen “absaugen” und so die benötigten Lieferobjekte erstellen. Danach gehen die Mitarbeiter wieder zurück in den Betrieb. Falls sie nochmals benötigt werden können sie wieder, geplant, beantragt und eingezogen werden.

Pool von Springern

Das Loch, welches entsteht, wenn man viele Mitarbeiter aus dem Betrieb herauszieht, könnte durch einen Pool von Springern gedämpft werden. Im Detail könnte das so aussehen:

1. Es wird ein Team von z.B. 10 Mitarbeitern mit verschiedenen Skills (Unix, Windows, DB usw.) aufgebaut
2. Ein Operationsmitarbeiter (Spezialist) geht in das Projekt
3. Ein Springer, oder zwei Springer zu je 50%, übernehmen die Business As Usual (BAU) Aufgaben des Spezialisten
4. Der Spezialist kommt zurück, falls sein Spezialwissen benötigt wird. (Z.B. bie einem großen Release)
5. Im Normalfall arbeitet der Spezialist mindestens 60% im Projekt
6. Nachdem die Aufgaben im Projekt erledigt sind, kehrt der Spezialist zurück und der Springer geht in seinen “Springerpool” zurück

Auf diese Weise werden dedizerte Mitarbeiter für die Kompensation einzelner Spezialisten vorgehalten. Die Springer werden im Lauf der Zeit mehr Wissen über die gesamte Operationsorganisation ansammeln und können so auch bei Krankheit usw. einspringen.
Das Projekt erhält eine “Quasi” Projektorganisation und kann seine Aktivitäten in weiten Teilen mit fest definierten Mitarbeitern durchführen.

Könnte das klappen?

Glaubt ihr, dass diese Idee klappen könnte? Könnte so eine Organisationsplanung durchgeführt werden die es sowohl dem Betrieb als auch dem Projekt erlaubt die gegenläufigen Ziele zu vereinbaren?

Ähnliche Beiträge

Klingt das gut?

Was haltet ihr davon?
Wäre das für unser Newssystem eine passende Stakeholder Analyse oder habe ich alles voll falsch verstanden?

Ähnliche Beiträge

In der Kantine

Gott sei dank hat unsere Firma eine eigene Kantine!
Was ich absolut schätze ist die Möglichkeit mittags mal ein Tablett zu schnappen, ein paar Minuten den Kopf zu leeren und vor allem den Bauch zu füllen.
Da mein Studium noch nicht lange genug vorbei ist (so schlappe zehn oder fünfzehn Jahre oder so) bin ich immer noch gegen Mensaessen immun.
Jaja, in der IT muss man immer schnell Neues lernen und Altes vergessen. Beim Essen ist es manchmal besser Altbewährtes beizubehalten. Zumindest so lange man es irgendwie gesundheitlich hinbekommt…
Hinter mir in der Reihe steht Günther, einer unser Marketingmenschen. Wir kommen so ins Gespräch:
“Hi Roland, na wo verpulverst du gerade unser Geld?”
“Ich darf im Moment mit Hanne und Fred, die fachlichen Anwendungsfälle zu erstellen für ein Newssystem erstellen.”
Günter schaut mich mit leuchtenden Augen an.
“Ah, ihr habt also schon ein Projekt gestartet. Das klingt ja super interessant.”
“Nein nein, wir haben noch kein Projekt, wir sind in der Vorstudie. Der Boss hat uns dafür zwei Monate Zeit gegeben.”
Da eine zweimonatige Vorstudie mit drei Analysten eine relativ ungewöhnlich großzügige Investition ist, bin ich im Moment extrem begeistert.
Günther und ich sammeln unser Essen ein und setzen uns ans Fenster. Die Frühlingssonne ist schon richtig warm, die Bäume schlagen um sich (oder aus) und die Welt ist schön.
Ich sage zu Günther:
“Es ist echt eine super Sache, dass wir so viel Zeit für unsere Vorstudie bekommen und wir wirklich fundiert den Rahmen unseres Projektes festlegen können. DANKE BOSS! Du bist ein Held!”
Günther schiebt sich eine Bratkartoffel in den Mund und grübelt ein wenig.
“Um was geht es denn in eurer Vorstudie genau?”
“Wir wollen ein neues Newssystem erstellen mit dem die Redakteure parallel über der ganzen Welt verstreut neue News eintragen können. Die Oberfläche wird deutlich einfacher und effizienter zu bedienen sein wie die Vorgänger. Überall, wo Daten aktualisiert werden, werden diese direkt auf dem Webclient angezeigt. Du brauchst also keinen Refreshbutton mehr zu drücken.
Auf für den Endanwender wird es deutlich interaktiver. Falls sich im Betrieb eine News ändert, wird dies sofort angezeigt.”
Günther ist begeistert und wirft fast seinen Teller vom Tablett.
“Das ist ja toll! Mit so einem System können wir unsere großen Kunden ausstatten und rennen der Konkurrenz davon! Super!”
“Naja, wenn wir das System fertig haben, kann es gut werden. Aber lass uns erst einmal die Vorstudie abwarten. Wir müssen erst einmal herausfinden ob es so klappen kann.”
Günther nickt und wir reden über ein paar andere Dinge, wie z.B. die Aktivitäten am nächsten Wochenende.
Ich geh zurück zu meiner Vorstudie und denke mir nichts böses.

Drei Tage später

Wir haben am Eingang der Firma einen großen Monitor der die aktuellen Trends und Aktivitäten der Firma anzeigt.
Weiterhin haben wir einen Ständer mit Flyern, bei denen sich unsere Kunden bedienen können.
Ich staune nicht schlecht, dort auf dem Bildschirm zu sehen, dass unsere Firma ein Newssystem mit verbesserter Interaktion erstellt hat.
Die Flyer beschreiben ein System, dass dem aus unserer Vorstudie sehr nahekommt.
Ich geh zu meinem Boss und frag ihn:
“Sag mal, gibt es schon ein Projekt, dass ein Newssystem erstellt?”
Der Boss schüttelt den Kopf.
“Irgend so ein Schwachkopf hat mit unserem Marketing gesprochen. Die haben Geld gewittert und haben eine große Kampagne gestartet. Wir sitzen ziemlich tief im Mist.
Unsere Geschäftsleitung möchte, dass wir unser Newssystem jetzt schnell erstellen. Die Vorstudie muss beendet werden. In drei Monaten muss ein Produkt auf der Straße verteilt werden.”

Oh Schreck!

Da war sie, die Vorstudie.
Und ich kenne den Schwachkopf auch ziemlich gut.
An dem Tag wusste ich, was mein BWL-Prof damit gemeint hat, man soll nie blauäugig ins Business gehen. Ich habe blaue Augen und mein loses Mundwerk hat mich und mein Team um die Vorstudie gebracht.

Fazit

Erstelle immer eine Stakeholder Liste. Schau genau mit wem du redest. Leute, wie Marketingmenschen, sind sehr gefährlich.
Sie können sehr einfach falsche Schlüsse ziehen und damit dein Projekt gefährden oder gar vernichten.
In Firmen ist die Gerüchteküche normalerweise schneller als die Lichtgeschwindigkeit. Wenn du sie auch noch anheizt, dann kollabiert das System sehr schnell.

Ähnliche Beiträge

Wie habe ich mir die Projektleitergeschichte vorgestellt?

Ich möchte zu verschiedenen Problemstellungen, wie Beispielsweise das Leiten eines Workshops oder Kommunikation im Projekt, jeweils eine kurze und hoffentlich lustige Geschichte schreiben.
Immer am Ende der Geschichte gibt es dann ein Fazit, bei dem ich auf die nicht so perfekt gelaufenen Einzelheiten eingehe.
Falls einige der Geschichten weit hergeholt klingen, ich habe sie wirklich in verschiedenen Projekten exakt so erlebt.
Hoffentlich macht euch das Lesen ein wenig Spaß und ihr könnt mit den Fazits der einzelnen Artikel etwas anfangen!

Ähnliche Beiträge