Enthusiasm for Software
and IT Projects

Unsere Expertise

Tel.: +49 (0) 89 / 456 89 222
E-mail: info@gesapro.de

Mit Theorie allein lässt sich kein Projekt stemmen

Ein Zertifikat ist schnell mal eben abgelegt. Via Google gesucht, finden sich zumeist mehrere Anbieter, die an ein oder zwei Tagen die Theorie zu einer Methode vermitteln und an Literatur gibt es eine Vielzahl an Büchern zu nahezu jedem Thema. Wer nur die Theorie kennt, wird sich in der „Wildnis“ des tatsächlichen Projektgeschehens nicht leicht zurechtfinden. Es wird eher zu Verwirrung führen, wenn man versucht Theorie und Praxis miteinander in Einklang zu bringen.

Praktische Erfahrung lässt sich durch nichts ersetzen, außer …

… durch noch mehr Erfahrung.

Wer versucht dem tatsächliche Projektgeschehen die Schablone Theorie aufzuzwingen, wird erfahrungsgemäß Schiffbruch erleiden. Man darf aber auch nicht der irrigen Annahme unterliegen, dass Erfahrung ausschließlich darauf basiert etwas über längere Zeit hinweg getan zu haben.

Experte ist NICHT, wer etwas schon lange macht oder gemacht hat. Experte ist, wer in einem Themengebiet über längere Zeit hinweg verschiedene Herangehensweisen erfahren durfte und aus den zweifelsohne gemachten Fehlern gelernt hat.

Unwägbarkeiten im Projektgeschehen, …

… sind wie die Winde und die Strömungen auf hoher See, zumeist unvorhersehbar. Mit theoretischem Wissen allein kann man dem Unvorhersehbaren nicht erfolgreich begegnen. Es bedarf der praktischen Erfahrung um schnell und gekonnt reagieren zu können.

  • Was tun, wenn ein kritischer Fehler in der Anwendung den Sprint-Plan durcheinander bringt?
  • Wann hat eine Velocity Aussagekraft und wann ist sie eine Kennzahl, mit der man besser nicht arbeitet?
  • Welchen Anforderungen müssen sogenannte Referenz-Stories gerecht werden, damit sie für die Aufwandsschätzung herangezogen werden können?
  • Wie beeinflusst die Softwarearchitektur das Testgeschehen?
  • Was beeinflusst die Qualität von Aufwandsschätzungen?
  • Wie bringt man Methode und die zum Einsatz kommenden Tools in optimaler Art und Weise zueinander?

Solche und andere Fragen, werden von einem Zertifikat nicht beantwortet. Auf solche Fragen und Herausforderungen trifft aber ein Scrum Master in Regelmäßigkeit.

Dependency Board

Dependencies are a Bugaboo

For many agilists – scrum masters, RTEs, etc. – a Dependency Board is „just“ part of PI planning. A Dependency Board is „only“ part of a PI planning, but they do not think much about what is behind it. They don’t question what it entails when teams have to deal with many dependencies on a regular basis. They do not ask themselves what could possibly be the reason for many dependencies.

Dependency Board

Dependencies sind ein Bugaboo

Für viele Agilisten – Scrum Master, RTEs, etc. – ist ein Dependency Board “nur” Bestandteil eines PI Plannings, sie machen sich aber nicht viel Gedanken darüber, was dahinter steckt. Sie hinterfragen nicht was es mit sich bringt, wenn die Teams regelmäßig mit vielen Dependencies umgehen müssen. Sie fragen sich nicht, was möglicherweise der Grund für viele Dependencies sein könnte.

Menü