PM mit Scrum – Video vom #fucamp

Nach einigen Monaten ist das Video zum Vortrag “PM mit Scrum” online:

image

Zusammen mit Martin Fache habe ich spontan ein Vortrag gebastelt und in einer Session auf dem FuCamp in Furtwangen vorgestellt. Leider ist der Ton nicht sonderlich gelungen – und man merkt, dass ich nicht besonders viel Erfahrungen mit spontanen Vorträgen habe. Insgesamt scheint die Session aber einigen etwas gebracht zu haben, vgl. Kommentare hier.

Update:
Hier das Video in einem schönen Player:

KADEV09: Entwicklertag: Zusammenfassung Agile Day

Nach dem VKSI Day und dem Conference Day war der Agile Day der dritte Tag mit interessanten Veranstaltungen.

Anmerkung: Jetzt ist es schon August und es sind immer noch keine Fotos online ;-(

Getting done your non-functional Requirements


Thomas Starz von IBM stellte in seinem Vortrag (Folien) vor, wie sich Scrum, XP und GTD kombinieren lassen.
Das Problem, dass ständig irgendwas dazwischen kommt, kennt wohl jeder. So kommt es schnell dazu, dass obwohl das Team viel arbeitet keine sichtbaren Ergebnisse erzeugt werden.
Kurze Diskussionen gab es um die Definition von “Nicht-funktionalen Anforderungen” (NFA), Thomas bezeichnete abhängige Anforderungen als NFAs:

  • neue Entwicklungsumgebung
  • neue Server
  • Performance
  • Usability

Nicht jeder im Publikum wollte diese Definition teilen.

Nach Meinung von Thomas legt der Product Owner (PO) seinen Fokus auf die Funktionen, dem sollte als Gegenüber ein Architekt auf die NFAs achten.

Für die Planung im Rahmen von Scrum gab es folgende Tipps:

  • Puffer für unvorhergesehene Arbeiten
  • NFA als Story im Backlog
  • PO (Funktion) soll sich intensiv abstimmen mit Architekt (NFA)
  • alles erfassen, was erledigt werden muss -> wirklich ALLES ins Backlog
  • Backlog ist Grundlage für Entscheidung

Hierbei sollte die Erfahrung berücksichtigt werden, dass viele POs zu häufig NFA nicht ausreichend berücksichtigen. Zudem wird man früher oder später wohl immer mit einem Verweis auf das Vorgehen nach Wasserfall bekommen: “Wir hätten nur die Spezifikation (besser) schreiben müssen!”

Scrum bei der BASF IT Services

Irene Kuhn von der BASI IT Services und Fahd Al-Fatish von andrena objects stellten ein Einführungsprojekt von Scrum bei der BASF IT vor.

Folien

Ziel des Projektes war der Relaunch des Internetauftritts (www.basf.com) von BASF.

Für dieses Projekt wurde ein erfahrenes Kernteam von sechs Entwickler um sechs weitere Mitarbeiter aufgestockt. Das Kernteam hatte in dem Bereich bereits viel Erfahrung mit Intra- und Internetauftritten (Portale, CMS, Redaktionssysteme)

Neben dem Relaunch von basf.com war ein weiteres Ziel die Vorgehensweise nach Scrum zu etablieren und Know-how-Träger als Scrum Master auszubilden.

Herausforderungen und Vorbehalte

Wie in Großunternehmen nicht unüblich stoßen Veränderungen schnell auf Vorbehalte. Gerade die Transparenz, die mit Scrum möglich ist, wird nicht immer nur positiv gesehen. Zudem wird bei der Einführung von Scrum auch oft kritisiert, dass die Methode zu viele Meetings mit sich bringt. Angesprochen wurde auch die Herausforderung, die sich daraus ergibt, dass trotzdem noch das klassische Reporting befriedigt werden muss. Weiterer Punkt war die Definition der Rolle des Projektleiters. Im konkreten Fall wurde der PL zum Scrum Master ernannt.

Vorbereitung

Um das Projekt richtig aufzusetzen und das Team auf Scrum vorzubereiten wurde in eine gute Vorbereitung investiert. Zuerst wurde mittels Einzelgespräche und Teambefragung der Ist-Zustand analysiert (Retrospektive). Es wurde geklärt, welche Probleme existieren und wo die Stärken des Teams liegen. Im nächsten Schritt wurde über Ziele gesprochen und diskutiert, was beibehalten werden kann und was sich ändern soll.

Durch diese Vorbereitungsphase war klar, auf was während der Einführungsphase geachtet werden musste.

Einführungsphase

Um das Team zu stärken (Teamfindung) und Vertrauen in Scrum zu schaffen wurden vier Sprints als “Probezeit” angesetzt. In diesen vier Sprints wurden die Mechanismen und Rollen eingeführt sowie ein erstes Product Backlog (PBL) geschrieben. Durch die Abarbeitung des Stories aus dem PBL war es möglich, eine Team-Velocity zu ermitteln.

Planung

Die Vorplanung für die Sprints erfolgte in mehreren Schritten: Zunächst eine Vorausplanung in einer kleinen Gruppe (Anmerkung: IMHO wichtige Methode, nicht bei jedem Estimation muss 90% des Teams anwesend sein!), gefolgt durch das Planungsmeeting mit dem gesamten Team am Folgetag.

Für die Vorausplanung wurde die Sprint-Kapazität abnehmend festgelegt: 1. Sprint 100%, 2. Sprint 80%, 3. Sprint: 75%. Durch die abnehmende Kapazität wurde der Unsicherheit Rechnung getragen.

Das PBL wurde durch ein “Product Owner-Team” bestehend aus PO & Chief Architect & Technical Architect geschrieben. Damit wurden sichergestellt, dass sowohl Funktionen als auch NFAs berücksichtigt werden. Die Schätzung des Aufwands erfolgte in Ideal-Tagen, zur Ermittlung kam die Planning-Poker Methode zum Einsatz.

Herausforderungen und Zusammenfassung

Im Rahmen des Projektes war es nötig eine Brücke von Scrum zum klassisches Reporting zu etablieren. Der klassische Projektleiter war jedoch eher als übergeordneten Stakeholder eingebunden. Hierbei spielt es eine Rolle, dass Projektleiter häufig zu viele Projekte gleichzeitig betreuen, deshalb beschränkte sich das “Management” hauptsächlich auf die Review-Meetings.

Sehr gut funktioniert hat das Team-Building und sehr effektiv war auch, dass der ProductOwner aus dem Team (!!) verantwortlich für das Management des PBLs war.

Auf die Einführung von komplexen Softwarelösungen wurde bewusst verzichtet. Als Tools kamen lediglich Excel und ein Task-Board zu Einsatz.

Durch die Restschätzung des PBL und Abgleich mit der Restschätzung Budget wurde eine sehr  gute Transparenz erreicht.

Fazit: Das Projekt war ein Erfolg und Scrum wird bei BASF IT Services immer häufiger eingesetzt.

Making Scrum stick – Transforming the Enterprise

Christoph Mathis (ScrumCenter) beschäftigte sich in seinem Vortrag (Folien) damit, wie Scrum nachhaltig im Unternehmen verankert werden kann.

Jeder von uns kennt es – unter Druck fallen wir schnell zurück in alte Verhaltensweisen und vergessen das neue. Hierbei spielt es oft auch eine Rolle, dass konservative Kollegen nichts mit den neuen Ansätzen anfangen können und dagegen opponieren. Auch Manager, die zu viel Transparenz fürchten, sorgen oft für einen gewissen Druck, wieder zurück zur alten Vorgehensweise zu wechseln. Ein kritischer Moment ist dann gekommen, wenn der Sponsor von Scrum die Firma verlässt.

Wie lassen sich solche Rückschläge vermeiden?

Christoph schlägt als erfolgsversprechendes Herangehen vor, dass Scrum vollständig praktiziert werden soll und damit letztendlich Scrum in der DNA der Firma verankert wird.

Er bezieht sich auf grundlegene Praktikern und Ideen von Scrum:

  • ask the team
  • inspect & adapt
  • deliver every 30 days
  • treat people as adults

Ergänzt werden sollen diese durch den konsequenten Einsatz von Engineering Praktiken.

Immer wieder soll die Frage gestellt werden, was getan werden muss, damit Scrum maximale Produktivität bringt?

Sein Vorschlag ist der Einsatz eines Verbesserungs-Backlog. Dieses wird in der Diskussion in Gruppen zu 2-3 Teilnehmern erstellt. Zentrale Fragestellung hierbei: Was braucht es, damit unsere Scrum-Praxis wirklich exzellent wird?

Um Scrum in der DNA des Unternehmens verankern zu können, muss die Kultur des Unternehmen berücksichtigt werden. Beispiele für die Kultur in einem Unternehmen sind:

Geschichten (worüber geredet wird)

  • welche Geschichten im Unternehmen (Held, Armleuchter, Erfolge, Misserfolge)
  • welche Geschichten sollen erzählt werden?
  • Was soll nächstes Jahr über das Projekt und das Team erzählt werden?

Symbole

  • wer hat welches Büro und welchen Dienstwagen?
  • wie ist die Kleiderordnung?
  • wer ist “Anzugträger”?

Organisationsstrukturen

  • wie ist die Organisation?
  • formal / informell

Kontrolle

  • wer fördert wen?
  • was bedeutet es Scrum Master zu sein für die Karriere?

Rituale & Routine

  • was für Veranstaltungen werden gemacht?
  • wie tut man Dinge?
  • wie initiiert man einen Vorschlag bei seinem Chef?
  • “das macht man bei uns so!” – nicht rational

Macht (Beeinflussung)

  • wer kann welche Vorgaben machen?
  • Methodenabteilung – hat diese Macht?
  • wer hört auf wen?

Durch sorgfältige Analyse können die einflussreichen Personen identifiziert und überzeugt werden. Nur mit der Unterstützung der Schlüsselpersonen, kann es gelingen Scrum dauerhaft im Unternehmen zu verankern.

Wichtig ist es, dass nach Identifikation des bzw. der Sponsoren Hilfe von außen geholt wird.

Hilfe von außen holen:

  • Hilfe von außen
  • Leuchtfeuer
  • Professionalisierung (Kompetenzzentrum)
  • Fördern
  • Diversifizieren
  • Etablieren
  • Konsolidieren
  • Integrieren

1) Scrum gut machen: Verbesserungs-Backlog
2) Scrum in Unternehmens-DNA einbauen: Transition-Backlog

Insgesamt wurden einige wichtige Hinweise gegeben, wie eine Einführung und Verankerung von Scrum im Unternehmen gelingen kann. Aus den Hinweis, dass es wichtig ist, Hilfe von außen zu holen durfte natürlich nicht verzichtet werden ;-)

Fazit Agile Day

Jetzt hat es doch wirklich mehr als einen Monat gedauert bis ich meine Notizen endlich überarbeitet habe. Nunja, zumindest bin ich mit der Zusammenfassung fertig bevor Fotos erscheinen ;-)

Insgesamt war der Agile Day sehr interessant – nicht nur wegen den Vorträgen! Die sehr spannende Podiumsdiskussion zum Thema “Clash of Cultures – Agilität und hergebrachte Arbeitsmodelle – Beobachtungen aus USA, Europa, Naher Osten und Asien – Unterschiede und Gemeinsamkeiten.” bekomme ich jetzt nicht mehr zusammen, dazu sind meine Notizen einfach zu wirr ;-)

Nun, es scheint ich tauge nicht zum Konferenz-Blogger. Na, wieder einmal etwas gelernt ;-)

JFS2009: Zusammenfassung Java Forum Stuttgart 2009

Das Java Forum Stuttgart ist seit Jahren immer eine gute Möglichkeit sich über aktuelle Trends in und um die Java-Welt zu orientieren. Auch dieses Jahr gab es viele interessante Vorträge. Im Vergleich zu den letzten Jahren mit deutlich weniger Vorträgen zu Entwicklungsprozessen und einem stärkeren Schwerpunkt auf neue Tools und Entwicklungsansätze.

Von Traktoren …

Begrüsst wurde man beim 12. Java Forum Stuttgart nicht durch Hightech und Anzugträger, sondern zunächst durch handfestes: Dicke Traktoren von Fendt. Ja, das sind schon beeindruckende Maschinen mit denen unsere Landwirte hantieren können ;-)
traktor

… und Bären

Einer der letzten Vorträge hat dann die Thematik dahingehend aufgegriffen, dass der Einsatz von Bären in Java-Projekten demonstriert wurde.

Butler und Baumeister – Kontinuierliche Integration mit Hudson

Der Vortrag “Butler und Baumeister” von Simon Wiest war für mich (und andere auch) das Highlight des diesjährigen Java Forums. Selten habe ich einen so guten Vortrag erlebt: Inhaltlich stimmig und lehrreich, dabei sehr unterhaltsam und motivierend. Wirklich gute (“hand made”) Folien und natürlich die drei Build-Bären. Noch während des Vortrags habe ich begonnen Hudson herunter zu laden.

Jeder, der nicht in diesem Vortrag war hat etwas verpasst! Danke Simon, das hat wirklich Spaß gemacht!

Hintergrundinformationen:

baeren

Allgemeine Stimmung

Das Java Forum Stuttgart bietet auch stets Gelegenheit sich mit alten Freunden und Bekannten zu treffen. Dieses Jahr war die aktuelle wirtschaftliche Situation und die Auswirkungen auf das Projektgeschäft natürlich ein heißes Thema.

Viele Bekannte berichten davon, dass aktuell eine große Anspannung herrscht. Die meisten haben noch Aufträge. Einige mussten aber auch schon erleben, wie in kürzester Zeit (innerhalb weniger Stunden) Projekte beendet und Projektteams aufgelöst wurden. Dadurch, dass jetzt zunehmend Kapazität verfügbar wird auf dem Markt steigt natürlich der Druck auf die Stundensätze. Andererseits sind viele laufenden Projekte weiterhin gut aufgestellt und für die beteiligten Freiberufler ertragreich. Die Frage ist hier: Wie lange wird dies noch andauern und was passiert, wenn noch weitere Projekte eingestellt werden. Ein verlustreicher Preiskampf kündigt sich an.
Interessant hierbei ist auch, dass Freiberufler sich starken Druck durch Betriebsräte ausgesetzt sehen. Firmen setzen Freiberufler frei, obwohl sie eigentlich auf deren Expertise angewiesen sind. Hier bin ich gespannt, was passiert wenn sich der Markt wieder dreht.

Weitere interessante Vorträge

Weitere interessante Vorträge waren für mich:

Kampf dem Fehlerteufel

Der Vortrag (Folien) von Jürgen Nicolai beschäftigte sich mit der statischen Codeanalyse zur Sicherung der Softwarequalität. Vorgestellt und verglichen wurden die freien Werkzeuge Checkstyle, FindBugs und PMD. Um zu veranschaulichen, dass es immer noch nicht Standard ist, diese Werkzeuge zu nutzen, wurden Beispiele aus prominenten Produkten/Projekten (JDK, Tomcat, JBoss) vorgestellt. Lehrreich!

Konzepte und Werkzeuge für die Vorprojektphasen – Feedback Lösungslabor

Thomas Avieny, Marco Klemm und Michael Jerger stellten in ihrem Vortrag (Folien) ihren interessanten Ansatz vor, sehr schnell zu einem lauffähigen Programm mit dem fachlichen Kern zu kommen. Ein “schwammiges Pflichtenheft” soll vermieden werden.

Zunächst wurden die Vorprojektphasen kategorisiert als Phasen die voll Unsicherheiten und Hindernisse sind und im Allgemeinen einfach zu lange dauern. Die These von Thomas, Marco und Michael ist, dass konkretes, schnelles und offenes Feedback das Ergebnis deutlich verbessert.

Die rhetorische Frage, ob konkretes oder abstraktes Feedback gewünscht wurde damit beantwortet, dass abstrakten Feedback reduziert werden sollte. Konkret wurde vorgeschlagen statt hunderte Seiten Spezifikation lediglich ein kurzes Überblicksdokument zu erstellen. Details sollen nicht im Dokument stehen, sondern so schnell wie möglich als umgesetzte Anforderung für eine Bewertung durch den Kunden bereitgestellt werden. Durch die Umsetzung können Annahmen viel besser validiert werden und Risiken werden früher erkannt. Wichtig hierbei ist, dass das Feedback zur Verfügung stehen muss, wenn die Entscheidung ansteht.

Um dies zu ermöglichen sind verschiedene Punkte zu beachten:
Anforderungen sollten in einer Form spezifiziert werden, die eine automatische Auswertung erlaubt. Dies spricht für den Einsatz von Fitness zur Spezifikation von Anforderungen.

Eine schnelle und flexible Umsetzung wird durch gute Vorbereitung (Infrastruktur, Schablonen/Patterns etc) und eine Standard-Visualisierung sowie die Konzentration auf das Wesentliche erreicht. So ist es laut den Vortragenden nicht unüblich, dass es 1-2 Iterationen pro Woche gibt, in denen das Domändenmodell überarbeitet wird.

Um zu guten Ergenisse zu kommen ist eine offene Diskussion wichtig. Für die schnelle Umsetzung muss das Lösungslabor vor Konfliktpotential geschützt werden:

  • Es werden ausreichende Mittel bereitgestellt: “Chef, ich habe eine Idee” -> Mittel, Leute, Zeit
  • Die Projektgruppe muss geschützt werden, Experimente müssen erlaubt sein. Unnötig Vorgaben müssen vermieden.

Zusammenfassung

Vortragsfolien sind mittlerweile online, Bilder gibt es ebenfalls die ersten. Leider schaffen es die Bilder vom Entwicklertag einfach nicht online zu gehen. Schade, schade!

Was lief gut …

Wie immer eine interessante Veranstaltung mit vielen unterschiedlichen Vorträgen und Themen. Grundsätzlich auch ein wichtiges Event für das Networking. Freies Essen und Trinken sind auch spitze, die Location ist ebenfalls ok – wenn auch nicht so “kuschelig” wie früher im SI-Center.

Was mich gefreut hat: Sehr gute UMTS Verfügbarkeit.

Was könnte verbessert werden

Das JFS könnte einen Touch mehr “Web 2.0″ kompatibel werden ;-) Es fehlt beispielsweise immer noch ein offizielles Twitter-Tag und eine Twitter-Wall an prominenter Stelle. Wer einmal eine funktionierende (= sinnvoll befüllte) Twitter-Wall auf einer Veranstaltung erlebt hat, möchte dies nicht mehr missen: Rapid Feedback!

Schön wäre es auch, wenn es ein Wiki gäbe, in dem man die BOF-Sessions abstimmen könnte.

Wie sieht es eigentlich mit Video-Aufzeichnungen aus?

SUGK: Scrum User Group Karlsruhe – Nächstes Treffen am 5. August

Das nächste Treffen der Scrum User Group Karlsruhe ist wohl für den 5. August ab 20:00 Uhr geplant. Zumindest ist Heiko und die Wiki-Seite der Meinung. Ein Entsprechender Termin bei XING existiert leider noch nicht.

Laut Backlog auf der Wiki-Seite soll dieses Mal das Thema Kanban im Kontext Scrum besprochen werden. Nunja, ein Vorgehen was ich aus der Produktionsplanung in Fabriken kenne inkl. schönen Eingangskörben etc.

Wer sich im Vorfeld etwas informieren möchte kann nachlesen bei Henrik Kniberg, Boris Gloger oder Corey Ladas (Autor des Buches “Scrumban”).

Wer sich also für dieses Thema interessiert oder sich sonst über Scrum austauschen möchte kann gerne kommen:

5. August 2009, 20Uhr im Großen Kurfürsten (Sophienstraße 80, 76135 Karlsruhe), vgl. auch den Termin in Xing.

Map picture

Update 31.07.: Das Thema ist diesmal nicht KANBAN sondern “Produkt Vision und Scrum”!

Java Forum Stuttgart 2009 – Morgen geht es los!

Morgen findet DAS Event für die Java-Community in unserer Region statt: Das 12. Java Forum Stuttgart – kurz JFS2009. Mittlerweile hat sich die durch die Java User Group Stuttgart (JUGS) organisierte Konferenz weltweit einen Ruf als praxisorientiert und spannende Veranstaltung erarbeitet.

Ich bin gespannt, schließlich hat es sich in der Vergangenheit immer gelohnt zum JFS nach Stuttgart zu fahren. Dieses Jahr sind zwar nicht so viele für mich passende Vorträge dabei, aber alleine die Möglichkeit alte Bekannte zu treffen und sich schnell über viele unterschiedliche Themen im Java-Umfeld informieren zu können macht das JFS für mich immer interessant.

Es freut mich vor allem, dass mein ehemaliger Kollege Thomas Avieny mit zwei Partnern (Michael Jerger und Marco Klemm) einen interessanten Vortrag anbietet:  Konzepte und Werkzeuge für Vorprojektphasen – Feedback-Lösungslabor. Ich bin gespannt!

Karlsruher Entwicklertag 2009 – Es hat sich gelohnt!

Die drei Tage “Karlsruher Entwicklertag 2009” sind vorbei, begonnen hat alles am Montag mit demVKSI Day (vgl. Posting), gefolgt vom Conference Day und dem Agile Day.

Trotz der etwas verwirrenden Benennung “Entwicklertag” für drei Tage haben sich alle drei Tage für mich gelohnt. Jede Menge interessante Menschen getroffen und viele gute Vorträge gehört. Erstaunlicherweise hat es mit den Netbook und dem Surf-Stick meist gut funktioniert und der Akku des 1000he hat wirklich den ganzen Tag durchgehalten. Somit ist auch dieses Experiment gelungen. Überrascht hat mich, dass einigen Teilnehmern ArmerKater.de bereits bekannt war!

Über den VKSI Day habe ich bereits etwas geschrieben, die Notizen zu den anderen beiden Tagen muss ich noch aufbereiten. Es ist doch mehr Text geworden als ich zunächst vermutet hätte und ich werde diesen noch sehr stark reduzieren müssen. Die beiden Berichte sollten in den nächsten Tagen fertig werden (=> zum Live-Reporter tauge ich also nicht).

KADEV09: Karlsruher Entwicklertage 2009 – Montag

Entwicklertag in Karlsruhe: 22.06.2009: VKSI Tag

Nach der Ankunft in Esslingen direkt in das freundliche Gebäude der Silverstroke AG. Glücklicherweise funktionierte die Registrierung einfach und schnell. Nach den ersten Minuten dann auch schon die ersten Bekannte getroffen und über die Wehen des Scrum-Prozesses diskutiert.

Im Laufe des Tages konnte ich immer wieder interessante Gespräche führen und mich mit vielen anderen Teilnehmern austauschen.

Sehr interessant war die Keynote von Jens Coldewey und die nachfolgende Podiumsdiskussion.

In seiner Keynotes “Software Engineering Heute” stellt Jens Coldewey 7 Thesen sowie das Ergebnis seiner letzten Umfrag vor.

7 Thesen

1) Softwareentwicklung ist Ingenieurstätigkeit
Definition des VDI ist jedoch problematisch:
- definierte Ausbildung > aber eine Vielzahl unterschiedlicher Angebote
- Stand der Technik > ändert sich jedoch ständig und schnell
- Best Practices > schwierig, wenn sich vieles ständig ändert

2) Softwareentwicklung ist Entwicklung (und keine Produktion)
- Softwareentwicklung ist nicht tyloristisch
- Anforderungen sind fast immer unscharf
- Entwicklung basiert auf Versuch und Irrtum / Experimenten
- Produktionsansätze sind unbrauchbar

3) Software ist komplex
- im Spannungsfeld zwischen deterministischen und chaotischen Systemen
- Verhalten ist oft überraschend und nicht vorhersehbar
- Forderung: Änderung an erzeugten Produkten und eingesetzten Prozessen muss möglich sein.

4) Softwareentwicklung basiert auf einer Kette von Entscheidungen
- Entscheidungen müssen zu einem optimalen Zeitpunkt getroffen werden
- zu früh/spät -> hohe Folgekosten

5) Softwareentwicklung ist iterativ und inkrementell
- seit Garmisch bekannt
- ein Grund: Komplexität und Unsicherheit
- Neues (Änderung Rahmenbedingung) ist nicht die Ausnahme sondern die Regel
- entscheidender Faktor: Architektur des Systems, diese muss Änderungen unterstützen -> wesentliche Forderung: Änderbarkeit

6) Softwareentwicklung ist Kommunikation
- Kommunikation dominiert Softwareentwicklung
- soziales Problem
- organisatorisches Problem
- selten rein technisches Problem
- “leader’s framework for decission making”
- unklare Vorgaben -> selbstorganisierende Teams
- Entwicklungsteam muss Wirtschaftlichkeit bewerten können

7) Softwareentwicklung ist Handwerk
- impliziertes Wissen, basierend auf Erfahrung, nicht beschreibbar
- Code als das Material für den Software-Ingenieur
- lebenslanges Lernen -> jahrelang
- Schüler, Geselle, Meister
- lernen am lebenden System
- lernen und arbeiten in Gruppen

In der darauf folgenden Podiumsdiskussion wurden die These aufgegriffen und kontrovers diskutiert. Interessant auch die Frage, welche Anforderungen heutige Informatik-Absolventen erfüllen sollen und wie die Universitäten dies unterstützen sollen.

Scrum User Group Karlsruhe – Multiprojektmanagement und Scrum

Eine kleine Erinnerung:

Das nächste Treffen der Scrum User Group Karlsruhe findet am 3. Juni im Restaurant Großer Kurfürst (Sophienstraße 80, 76135 Karlsruhe) ab 20:00 Uhr statt.

Diesmal referiert Heiko darüber, wie Multiprojektmanagement und Scrum zusammen passen. Heiko leidet als PO eines zentralen Teams unter extrem vielen (parallelen) Projektanfragen und kann sicherlich den einen oder anderen Tipp geben wie man eine solche Situation übersteht ;-)

Mal sehen, ob ich etwas Zeit habe mich für die Diskussion ordentlich vorzubereiten. Die typische Literatur zu Scrum sagt ja letztendlich “Multiprojektmanagement ist böse”, während der typische Vorgesetzt sagt “das müssen wir unbedingt auch noch machen!”. Beim Multiprojektmanagement spielen auch immer eine Vielzahl von externen Terminen und Projektzwänge eine Rolle und eine Optimierung auf Produktivität hilft nicht immer.

Beispiel aus der Fußballwelt: Dem KSC hat es nicht geholfen in den letzten Spielen schön produktiv gewesen zu sein. Er hätte die Tore besser verteilen müssen – jetzt ist eben 2. Liga angesagt. Wachablösung durch den SC Freiburg klappt aber wenigstens ;-)

Anmeldung wie üblich via Xing, Gäste sind jederzeit willkommen ;-)