Teamprove

In unserer Blog-Serie "O-TON" plaudern wir über unseren Job und unsere Leidenschaft für Agilität - diesmal mit Ron Jatzkowski, der unsere Kunden seit Februar 2018 bei der digitalen Transformation unterstützt.

Die digitale Transformation bewegt mittelständische Unternehmen aller Größen und Branchen. Doch welche Strategie verspricht Erfolg? Wie lassen sich Prozesse zukunftsorientiert gestalten und was bedeutet Arbeitswelt 4.0? Wenn Sie auf der Suche nach Antworten sind, laden wir Sie herzlich zum kostenlosen Besuch des Digital FUTUREcongress am 1. März in Frankfurt ein. 

In unserer neuen Blog-Serie "O-TON" lernen Sie unser Team besser kennen. Wir erzählen, was uns an unserem Beruf fasziniert und welche Erfahrungen wir mit der agilen Transformation gemacht haben. Den Anfang macht Christoph Dibbern, der uns seit September 2017 als Agile Coach und IT-Berater verstärkt.

Nur noch wenige Tage bis Weihnachten - ein guter Zeitpunkt, um „Danke“ zu sagen für spannende Projekte und die vielen Anregungen und Impulse, die wir aus der Arbeit mit unseren Kunden mitnehmen durften. Wieder liegt ein aufregendes Jahr hinter uns, auf das wir zufrieden zurückblicken (eine kleine Retrospektive samt „Roadmap“ für die Weiterentwicklung von Teamprove hatten wir vor wenigen Wochen zum 5. Firmengeburtstag für Sie zusammengefasst.)

Nun geht unser Team vom 23. Dezember bis zum 7. Januar in die Weihnachtspause. Ab 8. Januar sind wir wieder für Sie da. Wir wünschen Ihnen und Ihren Familien erholsame Festtage und ein Feuerwerk guter Ideen für 2018!

Herzlichst
Ihr Teamprove-Team

Tipp: Agile Techniken können übrigens auch im Weihnachtsendspurt eingesetzt werden! Wenn Sie von Weihnachtsfeiern, Projekt-Deadlines und Geschenkelisten gestresst sind, lohnt sich ein Blick auf den Artikel „Mit 7 Tipps agil durch die Vorweihnachtszeit“ ...

Kennen Sie die Situation: In Meetings erhalten Sie vom Team Aussagen wie „Dieser Task ist so gut wie erledigt“ oder „Die User Story ist eigentlich fast fertig“. Wunderbar, alles „in time“ – doch am Ende des Sprints stellen Sie erstaunt fest, dass nur ein Teil der User Stories lieferbar ist. Das Problem: Ob ein Inkrement fertig ist, wird von verschiedenen Personen sehr unterschiedlich definiert und interpretiert. Woher wissen Sie also, wann eine Aufgabe wirklich abgeschlossen ist? Was erwarten Kollegen oder der Product Owner? Um langwierige Diskussionen und unliebsame Überraschungen zu vermeiden, gibt es in agilen Teams das Artefakt „Definition of Done“ oder kurz „DoD“.

Im Programm einer Entwicklerkonferenz entdeckte ich kürzlich die Session „Hurra, wir werden agil – aber wie?“ Der Titel trifft die Situation in vielen Unternehmen gut: Das Bewusstsein, dass „etwas“ passieren soll, ist da. Aber gleichzeitig herrscht große Unsicherheit, wo und wie angepackt werden soll. Das Thema Agilität brennt vielen Führungskräften auf den Nägeln. Teils, weil genaue Vorstellungen vorhanden sind, was anders bzw. besser werden soll. Teils, weil doch alle anderen auch agil sind und das Management diesen Trend nicht verpassen will. „Wir arbeiten agil“ – das klingt deutlich dynamischer als „Wir entwickeln noch nach Wasserfallmodell“. Und zahlreiche agile Erfolgsstories aus dem Bekanntenkreis und der Fachpresse kennt schließlich auch jeder. Aber wie bildet man agile Teams? Führt man einfach Scrum ein und ist damit automatisch agil? Und wie war das nochmal mit der Unternehmenskultur und den Agile Leaders? Gibt es vielleicht einen 10-Punkte-Plan, der nach und nach abgehakt werden kann?

In wenigen Tagen ist Weihnachten und wieder geht ein ereignisreiches Jahr zu Ende. Die wichtigsten Milestones der letzten Monate hatten wir bereits in unserem Artikel zum 4. Teamprove-Geburtstag zusammengefasst. Anfang Dezember haben wir nun auch unsere Münchner Niederlassung eröffnet und freuen uns auf interessante Neukunden aus dem süddeutschen Raum. So bleibt es auch 2017 garantiert spannend!

Liebe Leser, Kunden, Geschäftspartner und Freunde, wir wünschen Ihnen und Ihren Familien frohe Weihnachten, erholsame Urlaubstage und einen guten Rutsch! Ab 9. Januar sind wir wieder für Sie da.

Herzlichst
Ihr Teamprove-Team

Wie können wir neue Ideen schneller umsetzen? Wie reagieren wir flexibler auf Kundenwünsche und Marktveränderungen? Und wie stellen wir trotz kürzerer Innovationszyklen stabile und fehlerfreie Software sicher? Um in dynamischen Märkten wettbewerbsfähig zu bleiben, muss moderne IT hohen Anforderungen gerecht werden. In diesem Zusammenhang ist immer häufiger von „DevOps“ die Rede - eine Philosophie, die auf ein engeres Zusammenrücken der konkurrierenden Bereiche Softwareentwicklung (Development) und IT-Betrieb (Operations) setzt. Aber was genau ist der Grundgedanke der Bewegung, die bei Unternehmen wie Netflix, Walmart, Amazon oder Facebook bereits erfolgreich im Einsatz ist?

Peinlich, peinlich … wir haben Ende Juli unseren eigenen Geburtstag vergessen! Tatsächlich ist unser „Baby“ Teamprove mittlerweile schon über 4 Jahre alt – fast bin ich versucht zu sagen: „Mensch, bist du aber groß geworden!“ Vier Jahre voll gepackt mit interessanten Projekten, tollen Kunden und spannenden Herausforderungen.

Was haben Dropbox, AirBnB und Adobe gemeinsam? Diese Unternehmen haben auf dem Weg zum Erfolg viele Frösche geküsst – und mussten vermutlich auch die eine oder andere Kröte schlucken. Und doch zählen sie heute in ihrem jeweiligen Segment zu den Marktführern.

Nach ihren Erfolgsgeheimnissen gefragt, taucht bei allen drei Unternehmen das Zauberwort „Lean Startup“ auf.

Klar, getestet wird Software schon immer. Auch bei klassischen Vorgehensmodellen ist Testen ein entscheidender Bestandteil des Qualitätsmanagements, denn mangelhafte Testprozesse sind nicht nur eine der Hauptursachen für Fehlfunktionen im Live-Betrieb, sondern auch für Effizienz-Einbußen: Die Wahrscheinlichkeit ist hoch, dass spät entdeckte Bugs die Arbeit des Entwicklerteams im Projektverlauf behindern.

Was aber macht agiles Testen so anders, dass ganze Bücher darüber geschrieben werden? Wie ändert sich das Selbstverständnis des Testers und welche Rolle spielt die Testautomatisierung?

Haben Sie heute schon einen Kaffee getrunken? Dann haben Sie vermutlich ein iterativ entwickeltes Produkt benutzt, vielleicht eines der Nespresso-Modelle EN166, EN266, EN520 oder EN550 - je nachdem in welcher Iteration Sie Ihre Maschine gekauft haben. Ob Kaffeemaschine, Smartphone, Computer, Fotoapparat oder Software: Sehr viele Produkte werden iterativ entwickelt, d.h. es wird eine vorläufige Version vorgestellt, anschließend sofort hinterfragt und auf Basis des Feedbacks weiter verbessert, bis das gewünschte Ergebnis erreicht ist.

---

Oder wissenschaftlich ausgedrückt:
„Iteration (von lat. iterare ,wiederholen‘) beschreibt allgemein einen Prozess mehrfachen Wiederholens gleicher oder ähnlicher Handlungen zur Annäherung an eine Lösung oder ein bestimmtes Ziel.“ (Quelle: Wikipedia)

Spannend an der iterativen Herangehensweise ist, dass sich die Ergebnisdefinition (in unserem Beispiel "die perfekte Kapsel-Kaffeemaschine") im Projektverlauf jederzeit ändern kann und ändern darf!

Iterativ: vom Vorläufigen zum Perfekten

Auch in der agilen Softwareentwicklung ist iteratives Arbeiten eine Grundvoraussetzung. Alle Projektbeteiligten akzeptieren, dass es unwahrscheinlich ist, das Produkt gleich beim ersten Versuch perfekt abzuliefern. Stattdessen wird ein Prototyp entwickelt und Feedback eingeholt, das sofort in eine Nachfolgeversion einfließt. Diese Feedbackschleifen (Iterationen) werden so oft wiederholt, bis der Auftraggeber zufrieden ist.

Wichtig: Es wird nicht einfach willkürlich an irgendwelchen Ecken "herumverbessert", sondern jede Iteration geht zurück zum Start, d.h. hinterfragt in einer Analyse den aktuellen Status Quo, macht sich erneut Überlegungen zum Design und führt nach der Implementierung wieder Tests durch. Im klassischen Wasserfallmodell hingegen wird das komplette Projekt zuerst analysiert, dann designed, implementiert und erst zum Schluss getestet.

Der Nachteil: Ein isolierter iterativer Ansatz führt dazu, dass erst recht spät ein marktfähiges Produkt vorliegt. Also vielleicht doch lieber inkrementell?

Inkrementell: vom Kleinen zum Großen

In inkrementellen Prozessen wird nicht am Gesamtsystem gearbeitet, sondern festgelegte Teilbereiche („Inkremente“) peu à peu fertiggestellt. So erhält der Auftraggeber sehr früh einzelne voll funktionsfähige Bausteine, allerdings fehlt im Gegensatz zur iterativen Arbeitsweise der Blick für „das große Ganze“ - Sie sehen den Wald vor lauter Bäumen nicht mehr.

Beispiel Straßenbau: Stellen Sie sich vor, Sie erhalten den Auftrag, eine neue Straße durch unwegsames Gelände zu bauen. Arbeiten Sie iterativ, roden Sie zuerst einen schmalen Trampelpfad für Fußgänger frei und testen die Wegeführung. Vielleicht korrigieren Sie noch einzelne Wegabschnitte, bevor Sie anfangen die Straße zu verbreitern, zu teeren, Leitplanken anzubringen, eine Ampelanlage zu bauen usw. Jede Straßenversion ist ein Stück ausgereifter, aber grundsätzlich kommen Sie bereits ab der ersten Iteration von A nach B.

Entscheiden Sie sich hingegen für eine inkrementelle Arbeitsweise, bauen Sie die Straße abschnittsweise – Sie kennen das vom klassischen Autobahnbau. Zwar ist jeder Teilbereich für sich früh bis ins kleinste Detail perfekt und nutzbar, aber mit dem Auto von A nach B fahren können Sie erst, wenn alle Etappen fertig sind.

Iterativ-inkrementell: Veränderung als Vorteil

Sie ahnen es bereits: Erst in Kombination entfalten beide Arbeitsweisen ihr volles Potenzial, insbesondere wenn es sich um komplexe Projekte handelt. So gegensätzlich die beiden Ansätze auf den ersten Blick wirken – sie ergänzen sich wunderbar. Scrum beispielsweise ist ein typisches iterativ-inkrementelles Framework.

Vereinfacht dargestellt wird die Gesamtaufgabe in kleinere Einheiten eingeteilt, die wiederum iterativ realisiert werden, d.h. die Teilbereiche werden basierend auf dem Feedback des Auftraggebers überarbeitet, bis sie den gewünschten Reifegrad erreicht haben. Dabei werden nicht wahllos Inkremente herausgepickt oder in einer sturen Reihenfolge abgearbeitet, sondern eine sinnvolle Priorisierung führt zu früh voll funktionsfähigen Key-Features, die ggf. sogar als marktfähige Prototypen eingesetzt werden können.

Tipp: Falls Sie noch mehr über den Unterschied zwischen inkrementell und iterativ wissen möchten - eines der anschaulichsten und meistzitierten Beispiele ist der „Mona-Lisa-Vergleich“ von Jeff Patton.

Und was bringt iterativ-inkrementelle Softwareentwicklung?

• Höhere Kundenzufriedenheit: Durch die kontinuierliche Einbeziehung des Auftraggebers erhält der Kunde exakt das, was er benötigt und wann er es benötigt. Er arbeitet von Stunde Null an intensiv mit und versteht so auch die Komplexität des Projekts und die Qualität des Produkts besser. Durch die Kombination erhält der Auftraggeber sehr schnell sowohl einen ersten Eindruck vom kompletten Ergebnis als auch einzelne fertig ausgearbeitete Teilbereiche, die genutzt (oder vermarktet) werden können. Anhand des Straßenbeispiels: Von Beginn an wird am gesamten Straßenverlauf gearbeitet, aber vielleicht wird eine von vier geplanten Fahrbahnspuren schon zu einem frühen Zeitpunkt so weit ausgebaut, dass sie von Autos befahren werden kann. Die Erkenntnisse aus der Nutzung dieser Spur fließen dann wiederum in die weitere Bauplanung ein.
• Geringere Kosten: Der Weg zum Ziel ist direkter, es wird nur entwickelt, was wirklich benötigt wird. Anforderungen, die sich als überflüssig oder unbrauchbar herausstellen, werden früh entdeckt und ggf. durch wichtigere, wertvollere Ideen ersetzt. Auf das Straßenbaubeispiel übertragen: Vielleicht stellt der Auftraggeber bei der Nutzung der ersten Spur fest, dass der Verkehr weniger dicht ist als geplant und dass statt einer vierspurigen Straße zwei Spuren völlig ausreichen (und das gesparte Geld besser in ein Stauwarnsystem investiert wird.)
• Kontinuierliches Lernen: Zwar wird in jeder Art von Prozess gelernt – egal ob Wasserfall oder iterativ. Beim iterativen Vorgehen kommt das Gelernte aber den noch anstehenden Entscheidungen zu Gute. Beim Wasserfall werden bereits zu Projektbeginn die Weichen gestellt, d.h. die im Projektverlauf gewonnenen Erkenntnisse können nicht mehr mit einfließen. Das verursacht nicht nur mehr Arbeit und Kosten, sondern auch Frust.
• Bessere Planbarkeit: Grundsätzlich wird nur das geschätzt, was zum jeweiligen Zeitpunkt Sinn macht. Während des Projekts wird die Geschwindigkeit des Entwicklungsteams gemessen, so dass die Schätzungen für künftige Projektabschnitte immer zuverlässiger werden.

Auch Scrum betrachtet die Unsicherheiten zu Projektbeginn nicht als Nachteil, sondern nutzt Veränderlichkeit aus, um innovative, an den Kundenbedarf angepasste Produkte zu schaffen. Was der iterativ-inkrementelle Ansatz mit Scrum-Sprints zu tun hat, werden wir demnächst in einem eigenen Artikel ausführlich vorstellen.

So, und jetzt hole ich mir einen Kaffee aus meiner (fast) perfekten Kaffeemaschine ...

Bildnachweis: anyaivanova / 123RF

Aufwandsschätzung ist sinnvoll. So unser Fazit nach Teil 1 und Teil 2 unserer Serie. Auch die Begriffe „Story Points“ und „Velocity“ konnten wir (hoffentlich) verständlich erklären. Aber jetzt ab in die Praxis: Wie läuft das konkret in den Entwicklerteams und welche Schätzmethoden haben sich bewährt? Wir werden in diesem Artikel einen kurzen Überblick über die unterschiedlichen Herangehensweisen geben und dann im Detail vor allem auf agile Schätzspiele wie den „Planning Poker“ eingehen.

---

agil = undiszipliniert?

Dieses Prinzip wird häufig von den Teams, aber auch von Kunden falsch interpretiert: „Wir arbeiten eben agil“ ist keine Ausrede für Projekte, deren Zeitplan oder Budget aus dem Ruder läuft oder bei denen Augenwischerei betrieben wurde, um den Aufwand zu Projektbeginn möglichst kleinzureden! Ganz im Gegenteil ist es das Ziel agiler Methoden, zielführender und damit wirtschaftlicher zu arbeiten, indem individuell entschieden wird, wieviel Dokumentation und Planung zum jeweiligen Projektzeitpunkt wirklich nötig sind.

„So wenig wie möglich, so viel wie nötig“: Vor dem Hintergrund, dass die Schätzkosten im Schnitt satte 3 Prozent der Projektkosten ausmachen, eine absolut sinnvolle Vorgehensweise!

Es gibt nicht „die“ Schätzmethode!

Um die verschiedenen Methoden besser in den Gesamtkontext einordnen zu können, holen wir etwas aus – wirklich nur kurz, versprochen! Grob eingeteilt gibt es zwei Ansätze, um Schätzungen durchzuführen:

Eine algorithmische Schätzung berechnet den Aufwand mit Hilfe mathematischer Formeln aus historischem Datenmaterial, statistischen Analysen und der Bewertung bereits vorliegender Größen. Entscheidend für ein präzises Ergebnis ist die Kalibrierung, d.h. die Parameter der Formel müssen firmenspezifisch angepasst werden (z.B. die Erfahrung der Mitarbeiter). Zwei der bekanntesten algorithmischen Methoden sind COCOMO und das Function-Point-Verfahren  – vergleichsweise aufwändig, aber bei gutem Datenmaterial in der Regel sehr präzise.

Eine empirische Schätzung basiert auf Erfahrungswerten von Fachleuten und/oder früherer, vergleichbarer Projekte. Am gängigsten sind hier Expertenschätzungen, zu denen u.a. beispielsweise der auf der Delphi-Methode basierende „Planning Poker“ und die Schätzklausur zählen.

Auch wenn es gerade für kühle Rechner im Controlling verlockend erscheint, eine Formel mit Zahlen zu füttern und so den Aufwand berechnen zu können: Die Erfahrung zeigt, dass empirische Methoden hinsichtlich der Präzision locker mithalten können. Da in agilen Teams außerdem großer Wert darauf gelegt wird, dass die Schätzmethode von allen Beteiligten ohne großen Erklärungsaufwand angewendet werden kann, kommen die hochkomplexen algorithmischen Modelle im agilen Umfeld kaum zum Einsatz bzw. in adaptierter Form (z.B. „Agile COCOMO“).

Am weitesten verbreitet ist die Expertenschätzung – laut Umfragen in rund 80 Prozent der Unternehmen die Methode der Wahl. Die Qualität der Schätzung hängt nicht nur von der Erfahrung der Schätzenden ab, sondern auch von der Anzahl durchgeführter vergleichbarer Projekte. Grobe Abweichungen können beispielsweise entstehen, wenn Erfahrungen aus kleinen Projekten 1:1 auf große Projekte skaliert werden.

In Scrum-Projekten ist eine realistische Aufwandsschätzung unter anderem nötig, um zu entscheiden, wie viele User Stories in einen Sprint gepackt werden können. Wir stellen hier drei Schätzvarianten vor, die sich in agilen Teams bewährt haben – nicht zuletzt aufgrund ihres spielerischen Charakters: das beliebte „Planning Poker“ nach Mike Cohn, „Magic Estimation“ nach Lowel Lindstorms und das „Team Estimation Game“ nach Steve Bockman.

Planning Poker

Populär wurde Schätzpoker in den letzten 10 Jahren durch Mike Cohn’s Buch „Agile Estimating and Planning“. Vorteil: Es handelt sich um ein transparentes, konsensorientiertes Verfahren, d.h. das Team versucht gemeinsam zu einer möglichst realistischen Schätzung des Entwicklungsaufwands zu kommen – perfekt für agile Teams, um deren gewünschte Selbststeuerung zu unterstützen.

Moderiert wird der Schätzvorgang durch den Scrum Master, optimalerweise steht auch der Product Owner für Verständnisfragen zur Verfügung. Zu Beginn wird eine möglichst kleine und einfach zu schätzende User-Story als Referenz festgelegt, zum Beispiel ein Formular. Jedes Teammitglied erhält nun einen Satz Schätzpoker-Karten. Die gängigen Kartensätze arbeiten mit der Fibonacci-Zahlenreihe 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, „?“ (kann nicht geschätzt werden) und „Pause“ (z.B. eine Kaffeetasse).

Nun stellt der Scrum Master die einzelnen zu schätzenden User Stories vor. Wichtig ist, bei der Beschreibung Wertungen wie „einfach“ oder „kompliziert“ zu vermeiden, um das Team nicht zu beeinflussen.

Anschließend kommen die Karten ins Spiel: Jedes Teammitglied legt für die betreffende Story verdeckt (!) eine Karte mit dem geschätzten Story-Points-Wert auf den Tisch. Die Zahlen auf den Karten sind eine Maßeinheit für die Komplexität in Bezug auf die anfangs festgelegte Referenzstory.

Weichen nach dem Umdrehen der Karten die einzelnen Bewertungen erheblich voneinander ab, begründen die Schätzer des größten und kleinsten Werts ihre Entscheidung. Die anderen Teilnehmer und der Product Owner können an der Diskussion teilnehmen. Dann wird die Schätzung wiederholt, bis es zu einem Konsens kommt. Wichtig ist es, dass es sich dabei nicht um einen „faulen Kompromiss“ handelt, sondern um einen Schätzwert, hinter dem jedes einzelne Teammitglied steht – sowohl die konservativen als auch die optimistischen Schätzer.

Teams mit ungeübten Schätzern verzichten häufig auch auf die Karten mit den Werten 20, 40 und 100 und brechen die User-Stories lieber auf mehrere kleinere, weniger komplexe Teileinheiten herunter. Sinnvoll ist es außerdem, eine Pokerrunde auf maximal 90 Minuten zu begrenzen – wenn die Konzentration nachlässt, ist es Zeit, die „Pause“-Karte auszuspielen.

Magic Estimation

Bei großen Projekten kann es zum Start sinnvoll sein, die einzelnen User Stories nicht nacheinander zu schätzen, sondern auf „magische“ Weise zu einem schnelleren Ergebnis zu kommen:  Wie beim Schätzpoker wird eine Referenzstory festgelegt und der Scrum Master stellt (bei Bedarf unterstützt vom Product Owner) die einzelnen User Stories vor. Anschließend verteilt er die Karten mit den User Stories unter den Teammitgliedern. Auf dem Boden wird (z.B. mit Schätzpoker-Karten) die Fibonacci-Reihe ausgelegt.

Nun läuft die Stoppuhr: Jeder hat nun 10 Minuten Zeit, seine Karten entlang der Skala gemäß seiner Komplexitätsschätzung zu platzieren UND auch Karten anderer Teammitglieder zu verschieben. So entsteht sehr zügig ein erstes Bild, wie die Teammitglieder die Aufwände der einzelnen User Stories im Vergleich zueinander sowie zur Referenzstory einschätzen. Gleichzeitig wird schnell klar, bei welchen Karten sich die Teammitglieder uneinig sind – diese werden zur Seite gelegt und später gemeinsam diskutiert. Bei „Magic Estimation“ geht es noch nicht so sehr um Präzision, sondern um Relation und eine erste grobe Einschätzung.

Team Estimation Game

Haben Sie ein Team, dessen Schätzungen regelmäßig in lange technische Diskussionen über das „Wie“ ausufern? Dann ist das Team Estimation Game vielleicht die richtige Schätzmethode für Sie: Auch hier moderiert der Scrum Master das Meeting und der Product Owner beantwortet Fragen. Alle User Stories liegen verdeckt auf einem Kartenstapel.

Das erste Teammitglied zieht eine User Story aus dem Stapel und platziert sie in der Mitte des Whiteboards.

Das zweite Teammitglied zieht eine weitere User Story und hat nun drei Möglichkeiten, diese in Relation zur ersten User Story zu setzen:

• neben der ersten Karte: ähnliche Komplexität
• unter der ersten Karte: größere Komplexität
• über der ersten Karte: niedrigere Komplexität

Die nächsten Teammitglieder haben nun jeweils zwei Möglichkeiten:

• Sie ziehen eine neue Karte und platzieren diese entsprechend.
• Sie verändern die Position einer bereits gepinnten User Story, weil sie mit der bisherigen Komplexitätseinschätzung nicht einverstanden sind.

So geht es reihum, bis alle User Stories ausgespielt und platziert sind. Üblicherweise bilden sich „Cluster“, die am Ende des Spiels noch mit konkreten Story Points versehen werden können (z.B. indem das Team den Clustern Zahlenkarten aus dem Planning-Poker-Set zuordnet).

Unbedingt sinnvoll ist es, die Umpositionierung von Karten zu vermerken, z.B. durch Klebepunkte, und Karten ab 3 Klebepunkten später gemeinsam zu diskutieren.

Übung macht den Meister

Egal ob Planning Poker, Team Estimation Game oder eine ganz andere Methode: Wichtig für möglichst gute Expertenschätzungen ist üben, üben, üben. Jeder Entwickler hat eine individuelle Zeitspanne, die er realistisch abschätzen kann und die noch dazu je nach Schwierigkeitsgrad der Aufgabe variiert. Die Einteilung des Projekts in User Stories sollte deshalb auf das Schätzvermögen Ihres Teams zugeschnitten sein.

Tipp: Notieren Sie VOR jedem Projekt Ihre Schätzungen und gleichen Sie NACH der Umsetzung ganz ehrlich ab, wie viel Zeit tatsächlich benötigt wurde. So trainieren Sie Ihre Wahrnehmung – bis sich im Idealfall Soll und Ist irgendwann decken.

Sie haben Fragen zu bestimmten Schätzverfahren oder benötigen Unterstützung bei der Auswahl einer für Sie geeigneten Methode? Gerne coachen wir Ihre Teams bei der Durchführung von Schätzmeetings!

Menschen machen Fehler. Auch Softwareentwickler. Und je komplexer das Projekt, desto höher die Fehlerquote. Die gute Nachricht: Wir können aus Fehlern lernen. Klar, hinterher ist man immer schlauer. Aber der Anglizismus „Lessons Learned“ bringt es auf den Punkt - wir müssen dieselben Fehler nicht zweimal machen. Genau deshalb ist es auch pragmatisch, mit der Nabelschau eines Projekts nicht bis zum Ende zu warten, sondern bereits projektbegleitend zu lernen und sich kontinuierlich zu verbessern. In agilen Projekten sind die sogenannten Retrospektiven Pflichtbestandteil des Projektablaufs, um Qualität und Effizienz zu erhöhen und das Team zu stärken. Aber wie läuft das genau?

In Teil 1 unserer Serie haben wir uns mit der Frage beschäftigt, warum Aufwandsschätzungen in der Softwareentwicklung so schwierig sind. Obwohl es bei komplexen Projekten praktisch unmöglich ist, soll meist bereits zu Beginn prognostiziert werden, bis wann und mit welchem Aufwand ein Ergebnis geliefert wird, das noch gar nicht exakt definiert werden kann. Entwickler sehen in dieser Forderung der Auftraggeber unsinnige „Erbsenzählerei“, die dem Projekt mehr schadet als nützt - die Auftraggeber hingegen ärgern sich über nicht eingehaltene Deadlines und Budget-Überschreitungen. Sogenanntes „abstraktes Schätzen“ kann dazu beitragen, diese unterschiedlichen Erwartungshaltungen auf einen Nenner zu bringen. Aber was unterscheidet die Methoden rund um „Story Points“ und „Velocity“ von der klassischen Aufwandskalkulation? Und kann man sich im agilen Umfeld diese ganze Schätzerei nicht sowieso sparen?

Sie möchten Ihre Softwareentwicklung verbessern - wissen aber noch nicht genau wie. Scrum ist in aller Munde – aber trotzdem können Sie sich zu den erforderlichen Veränderungen in Ihrem Unternehmen nicht so recht durchringen. Wenn Sie sich in dieser Beschreibung wiederfinden, sollten Sie über Software-Kanban nachdenken!

Wer hat an der Uhr gedreht… Drei Jahre sind Matthias Pauers und ich nun schon als „Entwicklungshelfer in Sachen Software“ unterwegs. Vielen Dank an alle Kunden, die Teamprove ihr Vertrauen geschenkt haben!

Wie alles begann...

Alle Welt spricht von „Agiler Software-Entwicklung“, von Methoden wie Scrum, Kanban und Extreme Programming - aber woher kommt die agile Bewegung eigentlich? Ein wichtiger Eckpfeiler für das Verständnis von Agilität ist das „Agile Manifest“, dem wir deshalb einen eigenen Glossar-Beitrag widmen.

Kann man über Code einen Roman schreiben? Man kann. Sogar so, dass es sich so spannend liest wie ein Buch, das man nicht mehr weglegen möchte. Paul Ford hat es bewiesen: In seinem fast 40.000 Wörter langen Essay in der Bloomberg BusinessWeek schreibt der amerikanische Programmierer und Autor so enthusiastisch und fesselnd über Code, dass man fast ein wenig traurig ist, wenn die letzten Zeilen gelesen sind.

„Sehr geehrte Scrum-Day-Interessenten, leider ist der Scrum Day 2015 ausgebucht!“ Diese Meldung auf der Website des Veranstalters wird viele enttäuschen, die sich dieser Tage noch für den kleinen, aber feinen Fachkongress in Stuttgart akkreditieren möchten. Die große Resonanz überrascht uns nicht, denn als Coaches für Softwareentwicklung werden wir täglich mit dem Boom agiler Projektmanagement-Methoden konfrontiert.