TopMenue

Die zwölf Prinzipien des agilen Manifests

scrum.that.runs

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen   ^

Was ist damit gemeint?

Generell gilt in den agilen Prozessen: Der Kunde / Auftraggeber ist nicht nur König und der Entwickler (das Projektteam) ist nicht nur Lieferant, sondern beide Seiten sind Partner, die ein gemeinsames Ziel verfolgen: die erfolgreiche Realisation eines (Software-) Produktes in einer durch Vertrauen geprägten Zusammenarbeit auf gleicher Augenhöhe.

Aus diesem Grund heraus müssen die Entwickler dem Auftraggeber frühzeitig das Gefühl vermitteln, dass das Projekt bei ihnen in guten Händen ist und das beweisen sie ihm (immer wieder), indem sie dem Auftraggeber frühzeitig und kontinuierlich ein lauffähiges und für ihn wertvolles Produktinkrement liefern. Der Auftraggeber kann es „anfassen“, er kann es ausprobieren und sehen, in welcher Form die Entwickler die aktuell realisierten Anforderung verstanden haben; der Auftraggeber bekommt quasi in regelmäßigen Abständen einen funktionsfähigen Prototypen der Software in der aktuellen Ausbaustufe.

Wichtig dabei ist, dass im auszuliefernden Produktinkrement nicht alle Features ein bisschen realisiert wurden, sondern dass die enthaltenen Features vollständig implementiert wurden und es in sich lauffähig ist, also dass sich die realisierten Features nicht in einem Zustand teilweiser Fertigstellung (wie will man diesen Zustand auch realistisch quantifizieren?) befinden, sondern fertig, abgeschlossen und bereit zur Abnahme. Zwar kann sich auf diese Weise zeigen, dass in dem Produktinkrement noch nicht alle Features realisiert wurden (was sich im Gegensatz zu Obigem sehr einfach und sicher quantifizieren lässt) und die fehlenden Features in den nächsten Realisationsabschnitt (z.B. Sprint) verschoben werden müssen; die Enthaltenen sind dafür jedoch fertig realisiert.

Der Auftraggeber erhält auf diese Weise bereits sehr früh im Projekt ein funktionsfähiges Produktinkrement, dass er nun anfassen, ausprobieren, testen, und — sofern es für ihn Sinn macht — sogar im Rahmen der bereits implentierten Anforderungen produktiv einsetzen kann, um z.B. bereits zu einem frühen Zeitpunkt einen Geschäftswert zu erzeugen oder, um sich eine Meinung über das Produkt, das Projekt und seine Geschäftspartner zu bilden, um (zumindest fachliche) Fehlentwicklungen erkennen und gegensteuern zu können, sowie wertvolles Feedback in das Projekt zurückzuliefern. Er kann damit — wenn er will — feststellen, dass er mit dem besten Dienstleiter der Welt zusammenarbeitet, oder dem Gegenteil davon.

Was ist damit nicht gemeint?

Das Ziel soll nicht sein, auf die Entwickler einen künstlichen Druck aufzubauen, noch schneller als möglich fertig zu werden, Überstundenrekorde zu brechen, den Code mit der ganz heißen Nadel zu stricken, oder zu versuchen, ein 12-Monats-Projekt in 10, nein, besser in 6 Monaten oder gar wenigen Wochen fertigzustellen.

Jeder kennt diese Projekte (oder jemanden, der jemanden kennt …): das Projekt hat — realistisch betrachtet — Arbeit für 10 Monate, der Vertrieb bietet es für 8 Monate an (so gewinnt man Ausschreibungen), aber der Auftraggeber will damit in 6, besser in 4 Monaten fertig sein. Das Ende vom Lied ist, dass alle Beteiligten aufgrund des Drucks schon während des Projektes überlastet und ausgebrannt sind, die Entwicklung erst nach 12 Monaten „abgeschlossen“ (aber noch nicht fertig) ist und sich danach eine mühsame Phase der Stabilisierung und damit der eigentliche Ärger mit dem Auftraggeber beginnt, der (aus seiner Sicht völlig zu recht) darauf drängen wird, das alles „Fehlende“ selbstverständlich (kostenfrei) nachzuliefern ist.

Solch ein Verlauf ist zu vermeiden. Das Ziel muss sein, dem Auftraggeber eine realistische Sicht auf seine Anforderungen, das sich daraus ergebende Projekt mit seinen Rahmenbedingungen, sowie das im Projekt zu entwicklende Produkt und seinen Entstehungsprozess zu vermitteln, um das Vorhaben in gegenseitigem Vertrauen und in einem realistischen Rahmen zu einem erfolgreichen Abschluss bringen zu können.

2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden   ^

Was ist damit gemeint?

Es ist außerordentlich unwahrscheinlich, dass die anfangs zusammengestellten Anforderungen auch den endgültigen Stand widerspiegeln. Es ist im Gegenteil nahezu immer so, dass sich die Anforderungen im Laufe des Projektes aus den unterschiedlichsten Beweggründen heraus ändern. Das bedeutet nicht, dass dabei am Ende ein anderes Produkt als ursprünglich geplant herauskommt, sondern lediglich, dass der Auftraggeber im Laufe der fortschreitenden Entwicklung neue Ideen entwickelt und formuliert hat, die entweder alte Ideen ersetzen, ergänzen, oder einfach nur verändern. Der Auftraggeber lernt und beginnt oftmals erst im Laufe der Entwicklung zu verstehen, was wirklich nötig und möglich ist und was nicht.

Der Entwickler als kompetenter Partner des Auftraggeber sollte die Bereitschaft des Auftraggebers, sich mit dem Produkt auseinanderzusetzen (die man für selbstverständlich halten könnte, was sie aber leider viel zu oft nicht ist) stets begrüßen und ihm offen und ehrlich sagen, was möglich und sinnvoll ist, was nicht und was das für den zu leistenden Aufwand, die sich daraus ergebenden Kosten und den sich ggf. verändernden Zeitbedarf bedeutet.

So hat der Auftraggeber die Möglichkeit, zu entscheiden, was er wann in welcher Form haben möchte. Haben sich die Beteiligten darauf verständigen können, dass sie als gleichberechtigte Partner auf Augenhöhe handeln, sollte die Handhabung dieser Situation kein wesentliches Problem darstellen.

Was ist damit nicht gemeint?

Damit soll nicht einem Feature-Rausch des Auftraggeber oder des Beraters Vorschub geleistet werden, oder -– wie bereits gesagt — das Prinzip der Veränderung des Planes als Kernprinzip agiler Softwareentwicklung zum Selbstzweck werden. Trotzdem muss es möglich sein, auch ganz am Ende des Projektes — unter Beachtung und Berücksichtigung aller sich daraus ergebender Chancen, Risiken und Konsequenzen — noch Änderungen in das Projekt einbringen zu können.

3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne   ^

Was ist damit gemeint?

Etwas überspitzt gesagt, wird in den klassischen Softwareentwicklungsprozessen zunächst geplant, dann gebaut und am Ende ausgeliefert und das, wenn möglich, nur ein einziges mal. Der Auftraggeber muss daher, etwas überspitzt gesagt, zu Beginn des Projektes einmal festlegen, was er gerne hätte, sich dann in Geduld fassen und am Ende damit vorlieb nehmen, was er bekommt.

Das ist in den agilen Prozessen anders. Die Anforderungsanalyse ist eine permanenter, das ganze Projekt über andauernder Prozess, der Auftraggeber wird in das Projekt mit eingebunden, hat also sozusagen seinen Finger immer am Puls des Projektes und bekommt am Ende nicht dass, was er zu Beginn des Projektes zu brauchen glaubte, sondern dass, was sich im Laufe des Projektes als sein wirklicher Bedarf herausgestellt hat; also das, was der Auftraggeber eigentlich gemeint hatte.

Um dem Auftraggeber diesen persönlichen Entwicklungsprozess zu ermöglichen, ist es nicht nur notwendig, dass er aktiv am Projekt teilnimmt, sondern, dass er kontinuierlich in kurzen, verlässlichen Abständen Prozessergebnisse — in diesem Fall Produktinkremente — erhält, an denen er seine Erfahrungen bereichern und die Sicht auf seine Bedürfnisse schärfen kann.

Was ist damit nicht gemeint?

Es sollte vermieden werden, den Auftraggeber mit Produktinkremente zu überhäufen, die für ihn keinen Mehrwert gegenüber der Vorversion aufweisen oder vielleicht sogar einen Rückschritt bedeuten. In diesem Falle wird der Auftraggeber mit hoher Wahrscheinlichkeit das Interesse am Begutachten und Testen der Software verlieren und in der Folge kein inhaltliches Feedback liefern können und wollen.

4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten   ^

Was ist damit gemeint?

Wenn es in einem Projekt, agil oder nicht, hakt, dann hakt es sehr oft an genau dieser Stelle, der Zusammenarbeit zwischen dem Auftraggeber und dem Projektteam. Die Mitarbeiter des Auftraggebers kennen ihre fachliche Domäne, das Projektteam die jeweilig technische. Um die für die aktuelle Problemstellung wertvollste Lösung zu finden und zu realisieren, ist es daher sowohl für den Auftraggeber, als auch für das Projektteam von grundlegender Bedeutung, effizient und in kurzen Abständen miteinander zu kommunizieren, einander zu vertrauen und effektiv zusammenzuarbeiten. Beide Seiten sollten aus diesem Grund die jeweiligen Bedürfnisse der anderen Seite nicht nur einfach entgegennehmen, sondern sich darüber hinaus auch noch darum bemühen, sie zu verstehen, um sie auf jeder Seite in den entsprechenden Prozess hinein und als Ergebnis oder Feedback zum jeweiligen Gegenüber wieder zurückfließen zu lassen.

Was ist damit nicht gemeint?

Steige Zusammenarbeit bedeutet nicht, sich permanent in einem das ganze Projekt über andauerndem Meeting gegenüber sitzen zu müssen, oder, dass ein Entwickler jeweils einen festen Partner aus der Fachabteilung hat, die dann, siamesischen Zwillingen gleich, nur noch gemeinsam arbeiten können.

5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen   ^

Was ist damit gemeint?

Programmierung ist zumeist ein von Kreativität und Inspiration geprägter Prozess, der seine Potentiale umso besser ausspielen kann, umso günstiger das ihn umgebende Umfeld ist.

Zu diesem günstigen Umfeld gehören nicht nur Mitarbeiter, die dazu leistungsbereit und motiviert sind, die ihnen jeweils gestellte Aufgabe bestmöglich auszuführen, sondern auch, dass jeder für sich und gemeinsam im Team den Raum und die Möglichkeit hat, kreative Lösungen zu finden und sie konzentriert realisieren zu können. Werden die Räume und Möglichkeiten jedoch beschränkt, engt man gleichzeitig jeden einzelnen und damit auch das Team insgesamt in der jeweiligen Handlungs- und Leistungsfähigkeit ein und gibt damit wertvolle Vorteile aus der Hand.

Nicht nur, dass unmotivierte Mitarbeiter, bzw. unmotivierte Teams schon aus sich heraus kaum zu Höchstleistungen bereit oder in der Lage sind, da sich der Motivationsmangel negativ auf Arbeitsleistung, Kreativität, Intuition und Inspiration auswirkt, darüber hinaus baut ein ungünstiges Umfeld (schlechte Rahmenbedingungen, verstreut arbeitende Mitarbeiter, etc.) auch noch weitere Hürden auf, die sich negativ z.B. auf Kommunikation, Konzentration und Leistungsfähigkeit der beteiligten Personen auswirken.

Gestaltet man die äußeren und inneren Umstände jedoch günstig (was für unterschiedliche Teams etwas Unterschiedliches bedeuten kann) und sind die Teammitglieder gut motiviert und leistungsbereit, kann man ihm Vertrauen entgegenbringen und das Team wird zusammen mit dem Input des Auftraggeber eine optimale Lösung für die gegebene Problemstellung finden.

Was ist damit nicht gemeint?

Damit ist nicht gemeint, dass es reicht, eine Anzahl motivierter Entwickler zusammenzustellen, sie machen zu lassen und am Ende darauf zu vertrauen, dass sie alles richtig gemacht haben. Das erstellte Produktinkrement muss auf jeden Fall zum einen teamintern getestet und abgenommen, sowie zum anderen selbstverständlich auch vom Auftraggeber ausprobiert und begutachtet werden.

6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht   ^

Was ist damit gemeint?

Softwareentwicklung im Team bedeutet permanente Abstimmung und permanente Abstimmung bedeutet ständigen Austausch von Informationen. Umso aufwändiger sich dieser Austausch gestaltet, umso mehr Zeit nimmt diese Kommunikation in Anspruch. Zudem ist menschliche Kommunikation so gut wie nie vollständig eindeutig, sondern enthält immer Unschärfen, die Interpretationsspielräume bieten. Das wiederum führt zu Unsicherheiten, die durch weitere Kommunikation ausgeräumt werden müssen.

Sind in einer solchen Situation die (Kommunikations-) Wege weit, langsam oder stehen nicht permanent oder nur in schlechter Qualität zur Verfügung, kommt es leicht entweder zu starken Verzögerungen oder zu Fehlinterpretationen (oder zu beidem), was im Endeffekt vielleicht die Auslastung der einzelnen Entwickler stark erhöhen kann, ihre Produktivität jedoch stark drosseln wird.

Selbstverständlich kostet jede Kommunikation Zeit, aber wir sind im Team auf Kommunikation angewiesen und die effektivste Form von Kommunikation ist die direkte, „face to face“, da wir in diesem Fall nicht nur die Worte und Gesten des Gegenüber wahrnehmen, sondern auch das gesamte Spektrum nonverbalen Aussagen, die sich in verbaler Sprache, Mimik und Körpersprache ausdrücken.

Scrumcess legt daher äußerst großen Wert auf direkte und unmittelbare Kommunikation zwischen den beteiligten Personen und den unterschiedlichen Gruppen, die sie idealer Weise in unmittelbarer Nähe zueinander praktizieren können.

Was ist damit nicht gemeint?

Damit ist nicht gemeint, dass sich zu jeder Abstimmung alle beteiligten Personen in einem Raum zusammenfinden müssen. Es gibt heute gute, sichere und schnelle Wege, auch über große Entfernungen miteinander zu kommunizieren, effizienter ist jedoch die direkte Kommunikation vor Ort zwischen Mensch und Mensch.

7. Funktionierende Software ist das wichtigste Fortschrittsmaß   ^

Was ist damit gemeint?

Ein Softwareentwicklungsteam entwickelt Softwareprodukte, die für den Auftraggeber einen (den größtmöglichen) Geschäftswert darstellen oder ihn erbringen. Das Ziel ist daher, in möglichst kurzer Zeit ein möglichst wertvolles Produkt zu produzieren. Wie weit das Projekt fortgeschritten ist, kann man an vielerlei Parametern festmachen: wieviel Zeit von der Projektlaufzeit verstrichen ist, wieviel des Budgets verbraucht ist, wieviel Projektfortschritt durch das Reporting „nachgewiesen“ wird, wie weit man eigentlich schon ist, auch wenn es vielleicht nicht so aussieht, usw., usf. …

Das ultimative Maß des Projektfortschritts jedoch ist letztlich, was von den Anforderungen wirklich und vollständig umgesetzt wurde und einwandfrei funktioniert, denn am Ende zählt nur die funktionierende Software.

Was ist damit nicht gemeint?

Damit soll auf keinen Fall ausgedrückt werden, dass nur die Lauffähigkeit des Produktes zählt und es für das Fortschrittsmaß bedeutungslos ist, wenn die Software nicht oder nur schwer wartbar oder erweiterbar ist, weil der Code völlig undokumentiert und unlesbar geschrieben oder „zusammengefrickelt“ wurde und/oder wenn keine Unit-Tests geschrieben wurden, die den Code absichern und dokumentieren würden.

Es ist gewiss eine projektspezifische Definitionsfrage, aber i.A. ist eine Software, deren Code nicht dem Styleguide genügt und/oder nicht die „definition of done“ erfüllt und/oder nicht in einem akzeptablen Maß durch Unit-Tests abgesichert ist, definitiv nicht fertig und ihr Fortschrittsmaß nicht bestimmbar, da nach „Abschluss“ des Projektes weitere Phasen der Nachbearbeitung nur schwer vorhersagbarer Größe drohen.

8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können   ^

Was ist damit gemeint?

Nachhaltigkeit bedeutet, Vorgänge in einer Art zu gestalten, dass die angestrebten Ergebnisse nicht nur kurzfristig Bestand haben, sondern möglichst dauerhaft bestehen bleiben.

Ein Beispiel hierfür ist die sogenannte „grüne Welle“.

Nachhaltigkeit in der Softwareentwicklung bedeutet z.B. für den Auftraggeber, dass das zu erstellende Produkt später im produktiven Betrieb nicht nur eine kurze Zeit nutzbar sein wird, sondern für den Auftraggeber einen möglichst hohen und langfristigen Geschäftswert darstellt.

Für die in das Projekt involvierten Personen bedeutet das, dass im Projekt Produktivität und Auslastung auf eine solche Weise gestaltet wird, dass starke Schwankungen in Form von Leerlaufphasen mit Langeweile, denen dann wieder zyklische Auslastungsspitzen bis hin zur Überbelastung aller oder einzelner Mitglieder folgen, vermieden werden sollten.

Ausgeglichenheit, Konstanz und Verlässlichkeit sind bedeutende Faktoren für jedes Team. Konstantes Tempo bei hoher Qualität schafft in hohem Maß Vorhersehbarkeit, Vertrauen und Leistungsbereitschaft für nachhaltige Erfolgswerte.

Was ist damit nicht gemeint?

Damit ist nicht gemeint, sich auf den kleinsten gemeinsamen Nenner zu beschränken, will sagen, sich am langsamsten Faktor zu orientieren, diese Geschwindigkeit dann aber endlos durchhalten zu können.

Das Ziel muss sein, über eine stetige persönliche, aber auch team- und prozessorientierte Weiterentwicklung und Erfahrungsbereicherung die Produktionsgeschwindigkeit auf einen höchstmöglichen UND gleichmäßigen, dauerhaft erzielbaren Wert zu bringen.

9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität   ^

Was ist damit gemeint?

Man sollte in agilen Projekten darauf Wert legen, ausschließlich mit Personen zusammen zu arbeiten, die uneingeschränkt teamfähig sind, die das für das Projekt benötigte Spektrum an Fähigkeiten und Kenntnissen besitzen und die darüber hinaus bereit sind, ihren technischen und fachlichen Horizont permanent zu erweitern. Es sollte für sie selbstverständlich sein, die zu realisierenden Anforderungen vor der Umsetzung gut zu durchdenken und ihr Code sollte selbsterklärend, offen für Veränderungen und damit zukunftsorientiert, sowie gut les-, wart- und testbar sein.

Teams mit solchen Mitgliedern profitieren maximal vom agilen Ansatz und bringen sich und ihn gleichermaßen voran.

Was ist damit nicht gemeint?

Es reicht nicht aus, ein Projekt mit einem Trupp kompetenten Entwickler zu besetzen und ihnen zu sagen „seid agil“. Sie müssen von sich aus bereit sein, uneingeschränkt im Team zu arbeiten, man muss sie an den Prozess heranführen und sie müssen in der Lage und bereit sein, sich auf den Prozess vorbehaltlos einzulassen und ihn „zu leben“.

10. Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell   ^

Was ist damit gemeint?

Man sollte die Konzepte so einfach wie möglich — aber auch nicht einfacher — und nur so komplex wie notwendig gestalten. Darüber hinaus sollte nur das wirklich Benötigte und keine unverlangten Extras realisiert werden. Konzept und Code sollten dabei klar strukturiert und flexibel genug sein, um ggf. später erweitert werden zu können, kurz: so einfach wie möglich, so komplex wie nötig.

Den Code, der NICHT geschrieben werden muss, auch NICHT zu schreiben, bedeutet vollständige Einsparung vermeidbaren Aufwands.

Was ist damit nicht gemeint?

Damit ist keine Minimalisierung des notwendigerweise zu treibenden Aufwands gemeint oder das Weglassen notwendigen Codes, um den Code eines bestimmten Sachverhalts vermeintlich „einfacher“ zu gestalten. Auch die Minimalisierung des Codes unter Inkaufnahme der Unverständlichkeit (Zitat: „alles in einer Zeile“) oder das Verhindern / Erschweren zukünftiger (vielleicht bereits bekannter) Erweiterungen, ist damit nicht gemeint.

Den Code, der geschrieben werden MUSS, dann doch NICHT zu schreiben, bedeutet, vermeidbare Risiken einzugehen.

Soweit darf Einfachheit nicht gehen.

11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams   ^

Was ist damit gemeint?

Teams, die die Selbstorganisation als Konzept für sich entdeckt, akzeptiert und adaptiert haben und in (agilen) Projekten einsetzen, können viel freier arbeiten, als Teams, die lediglich die ihnen vorgegebene Anweisungen ausführen. Erstere sind in ihren Möglichkeiten, Lösungen zu erarbeiten, viel unabhängiger, kreativer, innovativer und aufgeschlossener der Veränderung und Weiterentwicklung von Konzepten gegenüber. So sind sie in der Lage, ihre Potenziale voll und frei zu entfalten, um in kurzen Zeiträumen verlässlich hochwertige und innovative Lösungen für den Erfolg des Projektes zu erarbeiten.

Was ist damit nicht gemeint?

Selbstorganisiert zu sein bedeutet nicht — wie von manchen Kritikern immer wieder unterstellt — sich in einem regelfreien Raum zu bewegen und völlig ungesteuert agieren zu können; gilt es doch, die im gemeinsamen Einvernehmen vereinbarten Ziele in möglichst kurzer Zeit und unter Berücksichtigung und Einhaltung der vorgegebenen Regeln und Rahmenbedingungen zu erreichen.

12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an   ^

Was ist damit gemeint?

Ein wesentlicher Aspekt agiler Vorgehensweisen ist die stetige Weiterentwicklung des Teams.

Das Team analysiert teamintern am Ende des jeweils aktuell durchgeführten Projektabschnitts — z.B. am Ende jedes Sprints im Sprint-Retrospektive-Meeting — hierzu den Verlauf und das Ergebnis des Abschnitts, identifiziert Schwachstellen und Verbesserungspotentiale und beschließt sofort konkrete Verbesserungsmaßnahmen, die zeitnah — idealerweise und wenn möglich gleich im nächsten Projektabschnitt — umgesetzt werden sollten.

Auf diese Weise ist es den Beteiligten möglich, weitgehende Erfahrungen mit sich selbst als Mitglied seines Teams, mit seinem Team als solchem und mit dem Prozess zu sammeln, um sich selbst, das Team und den Prozess im spezifischen Kontext immer weiter zu verbessern.

Was ist damit nicht gemeint?

Das bedeutet nicht, dass man sich nur am Ende des Abschnitts um Analyse und Identifikation von Verbesserungspotentialen kümmern darf. Selbstverständlich ist jedes Teammitglied aufgerufen, sich auch im Laufe des Abschnitts Gedanken über eine Optimierung des Ablaufs oder einzelner Schritte oder Verhaltensweisen machen zu dürfen und sei es nur, um sich auf das am Ende des Abschnitts folgende Meeting vorzubereiten.

Sollte es sich jedoch um markante, die Produktivität einschränkende Probleme handeln, sollten diese selbstverständlich kurzfristig im Team zum Thema zu gemacht werden

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503130747DE