Verteiltes Team und Überstunden – Zwei heikle Themen für Scrum

Stefan Roock hat in seinem Blog zwei heikle (da umstrittene) Themen aufgegriffen. Viele Scrum-Abhängige ;-) bekommen schon bei einem der Themen graue Haare; Stefan hat zu beiden  interessante Posts geschrieben.

Überstunden

Mehrarbeit wird in der Agile Community stets als etwas schlechtes angesehen. Das Team soll keine Überstunden leisten (“sustainable pace”). Manchmal wirkt dies etwas absonderlich, wenn man als Projektleiter selbst Überstunden leistet, vor dem Team kommt, nach dem Team geht und dann auch nicht das geliefert bekommt, was man eigentlich im Projekt braucht (Argumentation: “Haben keine Zeit / zu wenig Leute / …”). Dies führt zu noch mehr Überstunden, da Diskussionen mit Kunden anstehen oder Notlösungen erdacht/geplant/umgesetzt werden müssen. Natürlich ist dies letztendlich eine Frage der Priorisierung, d.h. vom Top-Management. Es bleibt aber der fahle Beigeschmack, dass manche sehr engagiert arbeiten, anderer – anscheinend – im Modus “Dienst nach Vorschrift” verweilen.

Stefan beschreibt in seinem Blog ein Projekt, in dem das Team Überstunden geleistet hat, um die sehr enge Zeitplanung zu halten. Wichtig dabei: Das Team für sich selbst die Entscheidung getroffen, bewusst und sehr früh Überstunden zu leisten.

Weg von einem “covering my ass” zu einem “winning team” eben.

Hierzu muss das Team natürlich entsprechend motiviert sein (gewinnen muss sich lohnen). Das Engagement muss ausreichend belohnt werden. Wahrscheinlich der entscheidende Knackpunkt bei den meisten Teams bzw. beim Management.

Weitere Links zu dem Thema:

 

Verteiltes Team

In einem anderen Artikel beschreibt er ein stark verteiltes Team und wie dieses erfolgreich Scrum Sprints durchführen konnte. Sehr lesenswert: 13 Leute, 5 Firmen, 3 Standorte. Unmöglich! Oder?

Verteilte agile Entwicklung ist sicherlich eines der wichtigsten Themen in nächster Zeit, da letztendlich jedes größere Projekt auch immer mit einem verteilten Team arbeiten wird.

“All large scale development is distributed development”

… wenn ich mich nicht irre aus “Scaling Software Agility” von Dean Leffingwell – ein sehr empfehlenswertes Buch!

Video erklärt Nearshoring (USA / Mexiko)

Ein sehenswertes Video zum Thema Nearshore-Outsouring aus der Sicht eines US-Unternehmens bzw. eines Anbieters aus Mexiko. Grundlegende Zusammenhänge werden auf unterhaltsame Art und Weise erläutert. Das Ganze ist natürlich Werbung für einen Anbieter aus Mexiko – trotzdem sehenswert.

Nette Erklärung:

Shore 1.0:  onshore -> USA, offshore -> Indien, nearshore -> Kanada

Alles klar, oder? ;-)

Dann folgt eine Erklärung von “Nearshore 2.0″ und warum Mexiko eine bessere Wahl als Indien ist.

Hier das Video:

Scrum Alliance

Einige von euch haben sicherlich bereits mitbekommen, dass es spürbare Veränderungen bei der Scrum Alliance gibt.

Nach außen ist der Rücktritt von Ken Schwaber und der Start von Scrum.org das deutlichste Zeichen für diese Veränderungen. Da ich keine Insider-Informationen habe und mich auch schon vor einiger Zeit ganz bewusst dafür entschieden habe einen gewissen Abstand von der Scrum Alliance zu wahren, möchte ich an dieser Stelle auf Posts von Tobias Mayer und Boris Gloger verweisen. Beide Posts geben die persönliche Meinung des Autors wieder, enthalten jedoch viele interessante Informationen.

Sourcing: Ergebnisse einer Umfrage bei GULP

In der IT-Industrie spielen Nearshore-Outsourcing und Offshore-Outsourcing eine zunehmend wichtige Rolle, da durch die günstigeren Gehaltsstrukturen der Lieferantenländer oft das Potential (!!!) für Kostensenkungen gegeben ist.

Es handelt sich jedoch nicht um eine automatische Reduktion der Gesamtkosten, wenn die Lohnkosten bei einem Lieferanten beispielsweise 50% niedriger ausfallen als die internen Kosten und eine Fokussierung auf den Kostenaspekt greift in den meisten Fällen auch zu kurz. Trotzdem ist Nearshoring und Offshoring ein heißes Thema und viele Unternehmen wollen ihre Aktivitäten in diesem Bereich weiter intensivieren.

Mit diesem Themenkomplex hat sich auch eine Umfrage bei GULP beschäftigt, deren Ergebnisse jetzt verfügbar sind.

Einerseits lässt sich eine gewisse Ernüchterung erkennen, so spricht ein SAP-Experte davon, dass aktuell 120 IT-Experten in Bratsilava für Aufgaben eingesetzt werden, die auch 30-40 gut ausgebildete IT-Experte vor Ort erledigen könnten. In solchen Szenarien relativiert sich der Lohnkostenvorteil natürlich sehr schnell und es bleibt eine größere Komplexität – dies es natürlich zu managen gilt.

Andererseits ist Nearshoring/Offshoring Realität und tägliches Geschäft in vielen Unternehmen, so sind 59% der Befragten der Meinung, dass sich der Trend zum Off- und Nearshoring durchgesetzt hat. Bei 56% wird Nearshoring/Offshoring aktiv eingesetzt und 82% stimmen zu, dass der Kostendruck dazu führt, dass dieser Ansatz vermehrt eingesetzt werden wird. Es sind jedoch 62% der Meinung, dass ein Nearshoing-Anbieter nicht das gleiche Leistungsspektrum abdecken kann wie ein lokaler Anbieter, die oft viel Know-how in Bereichen aufbauen, die unternehmens- oder anwendungsspezifisch sind. Anbieter von Nearshoring und Offshoring konzentrieren sich hauptsächlich auf Know-how im Bereich Technologie und Standardthemen.

image

Aus meiner Sicht wird es spannend, wenn es gelingt Nearshoring-Kapazität im Rahmen von agilen Prozessen zu nutzen und mit den existierenden Strukturen zu verbinden.

SLM: Henrik’s Scrum Checklist 2.0

Henrik ist bekannt für sein pragmatisches Scrum-Buch “Scrum and XP from the Trenches”, welches mittlerweile in sehr viele Sprachen übersetzt wurde (de). Begonnen als PDF ist es mittlerweile als “echtes” Buch sehr beliebt.

image

In seinem sehr interessanten Blog finden sich immer wieder interessante Artikel. Jetzt hat er dort die “Scrum Checklist 2.0” veröffentlich. Ähnlich wie beim Nokia Test werden wichtige Kriterien einer Scrum-Umsetzung abgeprüft, was dabei helfen kann Optimierungspotential zu erkennen.

Ein Beispiel, wie die Checkliste NICHT eingesetzt werden sollte, wird gleich mitgeliefert ;-)

Big Boss: "Well it says here that you should do it, so don’t let me catch you cheating again, or I’ll call in the Scrum Police!"

http://www.crisp.se/scrum/checklist

Entwicklung und Betrieb – Zusammenarbeit bei Flickr

Wer kennt die meist problematische Beziehung zwischen Entwicklung und Betrieb nicht?

Die Entwicklung entwickelt, der Betrieb betreibt. Dabei geht einiges schief und schnell ist die Stimmung im Keller und es kommt zu gegenseitige Anschuldigungen:

  • “Die Entwicklung liefert immer nur Mist!” sagt der genervte Admin, der durch einen Alarm letzte Nacht aus dem Bett geworfen wurde. “Die sind einfach zu fault & doof richtig zu testen!”.
  • “Ich kann ja gar nicht richtig testen, es fallen immer wieder drei beliebige Bits im Loadbalancer um. Natürlich nur in Produktion! Und die Logfiles bekomme ich auch nur nach ewigen Diskussionen. Wie soll ich da testen?” erwiedert der empörte Entwickler.
  • “Das kann doch nicht sein! Ich dreh langsam durch – muss das immer in meinen Projekten passieren?” jammert der Projektleiter (= ich).

Das sich diese traurige Szene nicht immer wiederholen muss zeigt das Beispiel Flickr: Mit oft mehr als 10 Neuinstallationen auf den Serverfarmen im laufenden Betrieb scheint Flickr einen Modus Operandi gefunden zu haben, in dem produktiv gearbeitet werden kann.

Credo:
Ops who think like devs. Devs who think like ops. Mit dem Hinweis, dass es nicht der Job des Betriebs ist, die Applikationen stabil und sicher zu betreiben – sondern den Geschäftsbetrieb zu ermöglichen bzw. das Geschäft zu ermöglichen. Ist übrigens auch Aufgabe der Entwicklung!

Mehr dazu in einer schönen Präsentation:

Zu den vorgestellten Ansätzen/Werkzeugen gehören:

  • Automatisierte Infrastruktur
  • Versionskontrolle (shared)
  • Einstufiger Build-Prozess
  • Einstufiger Build- und Deploy-Prozess
  • Feature Flags – es gibt nur den Trunk!
  • Gemeinsame Metriken
  • IRC und IM Robots (“Dev, Ops & robots having a conversation”)

Hervorgehoben wird jedoch die Rolle der Kultur, der Umgangsformen:

  • Respekt
  • Vertrauen
  • Gesunde Einstellung hinsichtlich Fehlschlägen (Fehler passieren)
  • Keine Schuldzuweisungen

Viel Spass beim anschauen!

KADEV09: Entwicklertag 2009: Agile Nearshoring

Agile Nearshoring

Achim Maier, POET AG
Prof. Dr. Khaled Nagi, Universität Alexandria, POET Egypt LLC

Angekündigt wurde der Vortrag unter dem Titel “Agile Offshoring”, vorgetragen letztendlich als “Agile Nearshoring”. Nearshoring passt auch eher, schließlich zählt Agypten aus Sicht Deutschlands zu den Near-Shore-Destinationen. Überrascht war ich etwas, dass der Saal nicht einmal halb voll war. Für mich sind die Themen “Agile Methoden” und “Sourcing” für die kommenden Jahre von sehr großer Bedeutung (“hot topics”), die Gründe muss ich hier nicht noch einmal erläutern. Wenn man schließlich Agile und Sourcing verbinden möchte, dann bietet Nearshoring – also Agile Nearshoring – interessante Möglichkeiten. Genau um diese Möglichkeiten ging es auch in dem Vortrag.

Nach der obligatorischen Vorstellung des beteiligten Unternehmens (POET) mit seinen drei Standorten in Karlsruhe, Hamburg und Alexandra (Ägypten) wurde kurz die Ausgangssituation erläutert.

Ausgangssituation: Wasserfall

  • Phasen nach Wasserfall
  • Quality Gates, intene Verrechnung, abgegrenzte Verantwortungsbreiche
  • umfangreiche Anforderungen
  • Umsetzung der Anforderungen in Ägypten, keine Feedbackschleifen
  • lediglich 1 Release pro Jahr des Kernproduktes

Seit einger Zeit nutzt nun POET bereits agiles Nearshoring, um die Wettbewerbsfähigkeit zu stärken.

Es folgte eine kurze Erläuterung zu den agilen Methoden:

  • short cycles
  • continuous integration
  • acceptance

Und zum Nearshoring:

  • Zeitzone -> wenig Unterschied (im Vergleich zum Offshoring)
  • Resource planning (Entwicklerkapazität besser skalierbar)
  • lower daily costs (Tagessätze geringer)
  • Internationalization (Internationalisierung quasi nebenbei, da eh durch Nearshoring benötigt)
  • culture (kulturelle Nähe, v.a. im Vergleich zur asiatischen Mentalität)
  • level of domain know-how (ok, das dürfte firmenspezifisch sein)
  • IT Infrastructure
  • stability of team (Fluktuation muss gering gehalten werden, gelingt aber besser als bsp. in Indien)

Auch Herausforderungen - gerade im Managementbereich – wurden nicht ausgespart, u.a. wurde die Wichtigkeit von Kommunikation, vor allem auch direkte Kommunikation (face to face) hervorgehoben. Immer wieder wurde darauf hingewiesen, dass Team-Building bzw. ein “Team-Gefühl” ebenfalls von immenser Bedeutung ist. Team-Feeling: 3 Standorte, 1 Team!

  • software development = people business (deshalb: Management auf der persönlichen Ebene ist wichtig)
  • viele gegenseitige Besuche nötig, um Vertrauen aufzubauen
  • Reisekosten: Besuch Karlsruhe -> Alexandria: 450 EUR Flug + 3,5h Flugzeit + 1000 EUR Hotel & per diem => überschaubare Kosten
  • Aufwand für Spezifikation kann durch enge Interaktion jedoch reduziert werden

Interessant war die Ergänzung der Scrum-Rolle “Product Owner” um einen “Project Owner”. Der Product Owner führt in diesem Modell die Anforderungsanalyse durch, der Project Owner fokussiert sich auf die Prozessmodellierung. In unserem Multi-Project-Scrum haben wir ebenfalls die Rolle des Product Owners und die der Projektleiter – dies ist ein praktikabler Kompromiss, schwächt aber die Entscheidungskompetenz des Product Owners und sollte IMHO soweit als möglich vermieden werden.

Durch das Nearshoring gewinnt die Infrastruktur und der Werkzeugkasten an Bedeutung: Nur mit einem guten Tool-Set ist verteilte Entwicklung mit geringen Reibungsverlusten möglich.

Eingesetzte Methoden und Werkzeuge umfassen:

  • continuous integration & tests
  • Quellcode jederzeit verfügbar
  • Performance Tests: Web Load
  • Jira:
  • – Issue tracking
  • – Sprint-Planning
  • – Estimation Soll/Ist => Transparenz
  • – Aufwandserfassung
  • – Burn down charts werden aus Jira generiert
  • – Reporting aus Jira
  • – alle Kollegen (egal welcher Standort) arbeiten an Issues
  • – Verlinkung Issue <-> SVN
  • Kommunikation: VoIP + Jabba (selbst gehostet) -> schnell und günstig
  • Netviewer (Screen-Sharing / Online-Collaboration)

Die Ergebnisse des Agile-Nearshoring wurden insgesamt als sehr positiv beschrieben. Die Kundenzufriedenheit ist deutlich gestiegen, kein Projekt hat bisher den Budgetrahmen oder die zeitlichen Vorgaben gesprengt:

Customer Satisfaction

  • on time & in budget
  • no major bug fixes required after release
  • 23% weniger Support

Software Quality

  • average bug count 180 -> 25
  • kein “won’t fix” weil so dokumentiert

Team Performance

  • bug fixing & maintenance time 45% -> 34% (target 25%)
  • customer related implementation 9% -> 25%
  • time for implementing roadmap innovative enhancements 38% -> 43%
  • more room for innovation in cooperation with research partners

Gerade der wieder zurückgewonnene Handlungsspielraum läßt raum für neue strategische Optionen erahnen.

In der Zusammenfassung wurde nochmals auf die wichtigsten Punkte hingewiesen:

  • organisatorische Anpassung nötig
  • Offenheit & Flexibilität als Grundlage der Zusammenarbeit
  • Verbesserte Termintreue als Resultat
  • Kunden bekommen bessere Lösung
  • bessere Qualität der Software
  • Reisekosten erhöhen sich definitiv
  • DailyScrum in Egypt
  • Weekly: Steuerung auf PO/PL Ebene -> wöchentlich

Ingesamt war dies ein sehr interessanter Vortrag über ein spannendes Thema, welches in den kommenden Jahren an Bedeutung gewinnen wird.

Verträge für agile Softwareentwicklung

Als angestellter Projektleiter und Product Owner hatte ich es bisher in den meisten Projekten mit Festpreis-Verträgen zu tun: Fester Lieferumfang, fester Funktionsumfang und meist recht fixe Qualitätsanforderungen.

Dies hat stets verhindert, dass die agilen Methoden ihre voll Wirkung entfalten konnten. In vielen Fällen ist es im Projektverlauf zu heftigen Diskussionen über (kostenpflichtige) Änderungswünsche gekommen. Das übliche Problem bei Festpreisverträgen in Projekten mit einem gewissen Innovationsgrad.

Wenn man sich nun die “agilen Werte” bzw. die “Scrum Values” in Erinnerung ruft, so wird klar, dass Festverträge ein erhebliches Konfliktpotential zu diesen Werten aktivierten können. Vor diesem Hintergrund gehen viele Vordenker der agilen Bewegung in prinzipielle Opposition zu Festpreiskontrakten. Scott Ambler bezeichnet solche Verträge beispielsweise als unethisch.

Trotzdem sind Festpreisverträge die Norm, Verträge nach Aufwand selten und Mischformen kommen kaum vor.

Peter Stevens hat sich vor diesem Hintergrund mit der Problematik der Vertragsgestaltung näher beschäftigt:

In seinem Artikel Contracting for Agile Software Projects, Part 1 beschreibt er zunächst die Zielsetzung eines Vertrages, was ein Vertrag enthalten sollte und wie Vertragsformen verglichen werden können. In seinem lesenswerten Beitrag 10 Contracts for your next Agile Software Project vergleicht er schließlich die verschiedenen Vertragsformen und ihre “Kompatibilität” mit Scrum:

This week, let’s look at a number of possible contracts, and see how they work with agile and Scrum development projects:

  1. the “Sprint Contract”
  2. Fixed Price / Fixed Scope
  3. Time and Materials
  4. Time and Materials with Fixed Scope and a Cost Ceiling
  5. Time and Materials with Variable Scope and Cost Ceiling
  6. Phased Development
  7. Bonus / Penalty Clauses
  8. Fixed Profit
  9. “Money for Nothing, Changes for Free”
  10. Joint Ventures

Quelle

Ein wirklich wichtiger Beitrag, auch wenn man nicht jedem Argument zustimmen möchte.

UPDATE:

Der Vollständigkeit halber noch der Hinweis auf einen Artikel von Bernd Oestereich: “Der agile Festpreis und andere Preis- und Vertragsmodelle, Objekt-Spektrum, 01/2006, 4 Seiten, Seite 30“. Bernd beschreibt dort Preismodelle wie:

  • Festpreis
  • Aufwandspreis
  • Aufwand mit Obergrenze
  • Mehrstufiger Festpreis
  • Anforderungseinheitspreis
  • Agiler Festpreis

und vergleich diese unter Berücksichtgung verschiedener Aspekte (z.B. Budgetsicherheit, Kalkulationstransparenz, Verhandlungsaufwand, etc.). Obwohl der Artikel mittlerweile einige Jahre alt ist (2006) immer noch lesenswert.

Veranstaltung: Treffen Fachgruppe IT-Projektmanagement Stuttgart – Ziele & Randbedingungen

Am Freitag (24.04.2009) fand in Stuttgart wieder ein Treffen der regionalen Fachgruppe IT-Projektmanagement Stuttgart mit fast 30 Anwesenden statt.

Ziele

1. Vortrag: Die Magie der Ziele (Markus Maier, comundus GmbH)
Die Definition von guten Zielen wurden als der Erfolgssfaktor #1 benannt (Projekterfolgsfaktoren aus GPM „Der Projektmanager“), auf Ziele als Führungsinstrument wurden kurz eingegangen (Peter Drucker, Management by Objectives).
Die bekannte SMART-Formel wurde um SAP ergänzt: sinnvoll, attraktiv, positiv formuliert (nicht verneinend, da Gehirn dies nicht kann).

Ein passendes Zitat in diesem Zusammenhang:

„Sobald der Geist auf ein Ziel gerichtet ist, kommt ihm vieles entgegen.“

Johann Wolfgang von Goethe

Es wurde herausgestellt, dass Ziele immer erklärbar und begründbar sein müssen. Es ist wichtig Ziele zu hinterfragen, in der Diskussion die sich daraus ergibt, kommt es auf beiden Seiten (Fragender, Erklärender) oft zu wichtigem Erkenntnisgewinn.

Die dann folgende Diskussion war zu erwarten: Was passiert, wenn der Projektleiter Ziele vorgegeben bekommt, die er nicht teilen kann? Kann ein Projektleiter ein Projekt als „Job“ leiten oder muss er hinter den Zielen stehen? Kritische Frage in diesem Zusammenhang: Wenn der Projektleiter nicht für Projekt „brennt“ – wer dann?

Diese Diskussion war gut als Überleitung zum zweiten Vortrag geeignet:

Randbedingungen

Um richtige Randbedingungen kämpfen – Erfolgsfaktor für IT-Projekte (Dr. Karsten Hoffmann, Steinbeis-Transferzentrum IT-Projektmanagement)

vortrag

Karsten Hoffmann, erfahrener Projektleiter und Trainer/Berater für Projektmanagement konnte einiges über die erste Phase in einem Projekt erzählen: Die Übergabe eines Projektes (einer Projektidee) an einen Projektleiter. Bei der Übergabe muss der PL sehr genau prüfen, ob er das Projekt übernehmen kann (es realistisch ist). Es müssen sofort viele Fragen gestellt werden. Der PL muss sich innerhalb Minuten(!)/Stunden einen Überblick über das Projekt verschaffen.

Sofort bei der Übergabe muss der PL für das Projekt kämpfen. Diesen Kampf (um Zeit, Budget, Ressourcen, Zusagen) auf später zu verschieben funktioniert nie. In einem Projekt ist meist das 1. Zehntel entscheidend. Hier werden die wichtigen Weichen gestellt. Der PL muss die Forderungen demnach gleich zu Beginn stellen. Falls auf später verwiesen wird, sofort nach haken.

Beispiel: Personal wird auf später zugesagt, PL muss sofort nachfragen: Wann, Wer/Namen, Vorgehen, Arbeitsplatz.

Damit signalisiert PL, dass er sich nicht mit leeren Versprechen abspeisen lässt. Austausch mündlich beginnen, dann per E-Mail für Verbindlichkeit sorgen.

Eine typische Falle für junge Projektleiter ist das folgende Vorgehen:

  • Auftraggeber: Fang erst einmal mit dem Projekt an, wir sehen dann weiter.
  • später: Warum bekommst du das nicht hin? Schaffst du das nicht? Bist du ein schlechter Projektleiter?

Wichtige Einschränkung: In Kundensituationen können nicht immer alle Fragen gestellt werden.

Falls der Projektleiter bei der Übergabe des Projekt nicht die Möglichkeit hat zu verhandeln und Forderungen zu stellen, die die Erfolgsaussichten des Projektes verbessern, ist dies eindeutig schlecht. Es ist ein Indiz, dass das Projekt die genannten Ziele nicht erreichen wird. Das Aufzwingen eines Projektes ist die denkbar schlechteste Methode für ein Projekt einen PL zu bekommen.

Der PL erhöht seine Chancen für die Verhandlungen und damit den Projekterfolg stark, wenn es ihm gelingt sehr schnell einen Überblick über ds Projekt zu bekommen. Hier geht es eher um Minuten als um Stunden.

  • schnell verstehen um was es geht
  • Auftraggeber, Umfeld, Stakeholderanalyse
  • Zieldreieck abklopfen, PL muss Chancen auf Erreichbarkeit von über 50% annehmen
  • Projektauftrag
  • Ressourcen prüfen

Wichtig hierbei ist es, sofort Fragen zu existierenden Dokumenten stellen. Dies hilft nicht nur bei der Klärung von inhaltlichen Fragen sondern zeigt auch welche Kommunikationskanäle existieren, Engstellen werden erkannt. Beispiel: Ansprechpartner kann/will keine bindende Aussage treffen.

Bei der Projektübergabe muss der Projektleiter klar machen, dass eine gemeinsame Verantwortung für das Projekt besteht. Nur wenn der Auftraggeber eng mitarbeitet hat das Projekt eine Chance auf Erfolg. Handelt es sich um einen komplizierten Kunden, dann hat dies sofort Auswirkungen auf den Aufwand. Komplizierte Kunden erhöhen den Aufwand stark.

In Diskussionen mit höherem Management muss der PL bedenken, dass diese Manager gewohnt sind mit Stärke&Macht ihren Willen durchzusetzen. Dies erzeugt sehr oft einen starken Druck auf den PL, den dieser aushalten muss. Im Zweifel sollte ein Projektleiter die Übernahme ablehnen und die Konsequenzen tragen statt jahrelang an schlechten Randbedingungen zu scheitern.

Auch im Projektverlauf kommt es immer wieder zu Störungen. Diese müssen mit dem Auftraggeber beseitigt werden. Beispiele hierfür:

Änderungen Scope, fehlende Beistellungen, weniger Ressourcen

  • sofort kommunizieren: Wir haben ein GEMEINSAMES Problem
  • vor schneller Eskalation nicht zurückschrecken
  • darauf drängen gemeinsam zu steuern

Bereitstellungen Kunden fehlen

  • sofort Problem identifizieren und an Kunden melden
  • Auswirkungen auf Funktionsumfang klären: Wir warten, d.h. wir können nicht entwickeln, d.h. wir werden weniger Funktionen liefern. Hart bleiben.

Podiumsdiskussion

Im dritten Teil wurde schließlich eine Podiumsdiskussion durchgeführt.
Ein schönes Zitat verdeutlicht sehr gut die „weiche Seite“ des Projektmanagement:

„Ein großer Teil meiner Arbeit ist Kaffee trinken am Kaffeeautomaten. So komme ich zu einem offenerem Feedback, erhalte viele wichtige Informationen.“

Schließlich wurde über Vertrauen als Basis für eine funktionierende und effektive Zusammenarbeit diskutiert und wie dieses aufgebaut werden kann.

Insgesamt eine sehr interessante und spannende Veranstaltung in Stuttgart.

stuttgart

Stuttgart Fußgängerzone.

Das nächste Mal gerne wieder!