Dienstag, 12. Mai 2015

Warm werden mit einer neuen Codebasis

Als ich vor einem halben Jahr die Firma wechselte, kam neben einer neuen Umgebung mit neuen Leuten auch eine riesige, gewachsene Codebasis auf mich zu. Da es sich um ein kommerzielles Produkt handelt gab es immerhin eine Dokumentation und eine Woche Schulung dazu. Um nun aber wirklich schnell produktiv zu werden haben mir dann "Fake it till you made it" und "TDD as if you meant it" geholfen.

Meine Aufgabe war es neue bzw. erweiterte REST Schnittstellen anzubieten. Das Produkt basiert auf Spring und stellt bereits eigene REST Schnittstellen bereit, hat aber genügend Besonderheiten.

Fake it till I made it

Damit die Konsumenten meiner Schnittstellen möglichst schnell diese Anbinden konnten und nicht warten mussten bis ich endlich so weit bin die Schnittstelle bereit zu stellen habe ich zunächst den Controller mit den definierten Methoden geschrieben. Als Rückgabewert gab es dann halt Dummydaten welche nach bestem Wissen aber schon dem erwarteten Format entsprechen.

TDD as if you meant it

Bei TDD as if you meant it wird sowohl der Testcode als auch dessen Erfüllungscode innerhalb der Testmethode geschrieben (und dann heraus refaktored) Details siehe z.B.: hier.
Da ich ja schon wusste wie das Ergebnis aussehen soll aber noch unsicher war wie ich durch die verschiedenen Schichten an die entsprechenden Daten komme und diese transformieren muss, lag es auf der Hand dies erstmal Schrittweise in Integrationstests zu fixieren und mich dann an die API heran zu tasten. Dabei halfen mir die Tests zu wissen wann dann Ziel erreicht ist und wann eine Änderung etwas schon geschaffenes wieder zunichte macht. Des weiteren halfen die Tests beim Experimentieren noch offene ToDos zu fixieren. Musste in einer Schicht mehr Logik entwickelt werden kamen hier dann UnitTests hinzu.

Und Ihr?

Welche Erfahrungen habt ihr mit neuen Codebasen und der Einarbeitung gemacht?
Wie werdet ihr warm und nehmt Fahrt auf?

Mittwoch, 11. Februar 2015

Stolpersteine beim Bootstrapping SCRUM

Ich habe mittlerweile in mehreren Unternehmen miterlebt, wie Scrum quasi via "Bootstrapping" eingeführt wurde. Mit Bootstrapping meine ich, dass innerhalb eines Teams, in dem ein gewissen Scrumwissen vorhanden war Scrum (zumindest intern) verwendet wurde. Ggf. wurde noch ein Buch dazu gelesen, die Rollen verteilt und los geht es mit den Sprints.

Ein Tweet und damit verbundener Link von Patrick Koglin hat mich gerade wieder darauf aufmerksam gemacht:




Leider habe ich bei diesen Vorhaben immer wieder ein paar Stolpersteine entdeckt, welche ich hier mal Auflisten möchte:


  • Missachtung von Shu Ha Ri
    Scrum sieht ein Inspect & Adapt vor. Aber anstatt Scrum erstmal anzuwenden und später zu Anpssungen zu kommen wird als erstes das Rahmenwerk destabilisiert (angepasst) weil "bei uns ist das alles anders". Die Gefahr besteht hier da drin, dass ein Unerfahrenes Team (ohne Coach) nicht überblicken kann was die Auswirkungen sind und so Scrum und dessen Sinn hier unterläuft.
  • Teilzeit ScrumMaster
    Die Rolle des ScrumMasters wird von einem Teammitglied z.B. Entwickler übernommen welcher seine "alte" Rolle in Teilen beibehält. Oft beschränkt sich das Verständnis der ScrumMaster Rolle auf Prozessüberwachung. Also nutzt er seine Zeit um die Termine zu erstellen, Charts zu malen etc. Für seine Aufgabe, die Teamperformance zu verbessern hat er keine Zeit, sie beschränkt sich auf Retrospektiven oder auch einfach keine Ermächtigung.
  • Scrum wird als Prozess gesehen
    Weil die Organisation seit jeher Prozessorientiert ist sieht sie Scrum auch nur als weiteren Prozess. Dass es um eine ganz andere Transformation geht bleibt ein blinder Punkt.
  • Inspect & Adapt ist Contextsensitiv
    Die Anpassungen und funktionierenden Tools und Methoden sind Contextsensitiv. D.h. was für das eine Team / Projekt / Unternehmen Sinn macht kann wo anders ganz daneben sein. Trozdem wird immer wieder versucht diese einfache zu Übernehmen. (Was auch in Teilen zu Verbesserungen führen kann) Ein gutes Beispiel dafür ist, dass viele Methoden, welche in agilen Umfeldern erfolgreich war als agile Methoden / -Tools bezeichnet werden.
  • Scrum ist nicht agile
    Oft wird Scrum als Synonym für agile gesehen. Aber Scrum ist ein Framework welches auf einem agilen Weg helfen kann kein agiles Ziel. Man kann Scrum auch ganz ohne agile einsetzen. (siehe auch nächsten Punkt)
    Scrum ohne agiles Manifest
    Oft habe ich erlebt, dass bei einer Scrum Einführung das agile Manifest keinmal erwähnt wird. Dabei gilt: agile ist wenn man die Werte und Prinzipien! des agilen Manifests einhält. (Hab dazu auch mal einen Tweet oder Blog von einem der Unterzeichner des Manifests gesehen - kann mir da wer mit der Quelle helfen?)
  • Fehlendes Management Support
    Das ganze Vorhaben wird am Management vorbei gemacht. So sind die Rollen nicht richtig Ermächtigt um ihre Aufgaben zu erfüllen. Wenn das Management davon Kenntnis hat, wird es "Geduldet" und wenn es "funktioniert" hat das Management zwar noch keine Ahnung aber freut sich nun auch agile zu sein. - Wozu nun noch mehr investieren?
  • Iterativer Wasserfall
    Nun gibt es zwar Sprints und die neuen Meetings aber das StandUp ist eher Reporting als Micromanagement in Crossfunktionalen Teams und das Backlog ist auch nur ein Projektplan in anderem Format.
  • ScrumMaster Ausbildung
    Obwohl die ScrumMaster oder ProductOwner Zertifizierungsvorbereitung in der Regel nur 2 Tage dauert (im Gegensatz z.B. zum PMP) wird sie als Ausbildung angesehen. Hier fängt das lernen aber eigentlich erst an.
Grundsätzlich spricht natürlich nichts gegen ein "Bootstrapping" aber es gibt halt einige (sicher noch mehr als mir gerade eingefallen sind) Stolpersteine welche zu beachten sind. Ein erfahrener Coach kann da sicher helfen.

Mittwoch, 4. Februar 2015

agile Karriere???

Durch zwei Tweets von Svenja Hofert bin ich wieder zu einer Fragestellung gekommen, welche mich immer mal wieder beschäftigt: "Was ist Karriere und will ich das?"

Diese Tweets waren:



und


In dem Ersten geht es um Karriereschritte und Möglichkeiten auch mal Rückwärtsschritte zu machen. In dem Zweiten um die vertikale Welt des Management und die horizontale agile Welt.

Für mich war Karriere immer verknüpft mit der horizontalen Welt und damit auch irgendwie mit dem Peter-Prinzip. In der Softwareentwicklung war Karriere (für mich) definiert über Junior (Entwickler), Entwickler, Senior (Entwickler) wobei der Senior Titel auch oft aus "Verkaufsgründen" und nicht nach Wissen vergeben wurde. Davon ab sind die verschiedenen Stufen in jedem Unternehmen anders definiert oder gar nicht vorhanden. Aber danach führten die Schritte unweigerlich weg von der Softwareentwicklung hin zu Projekt-Manager, Teamleiter oder mit etwas Glück gab es auch fachliche Wege hin zum Architekten.

Dabei entwickel ich Software aus Leidenschaft. Wenn mich Karriere davon weg führt dann will ich das nicht. Aber Stillstand fühlt sich in dieser Welt auch komisch an. In der "vertikalen" Welt ist es dann auch nicht nur schwer Schritte zurück zu machen sondern auch einfach keinen Schritt machen zu wollen.Zumindest wenn man sich dabei doch noch weiter entwickeln will und nicht auf dem Abstellgleis landen.

Nun gibt es ja noch die horizontale agile Welt. Hier fühle ich mich wohl. Aber Karriere scheint hier überhaupt nicht definiert zu sein. Was hier zählt ist Kompetenz und diese kann man weiter entwickeln ohne sich von seiner Leidenschaft entfernen zu müssen. Es gibt hier keine Positionen nur Rollen und diese kann man in agilen Unternehmen einnehmen wenn die eigene Kompetenz gerade gefordert ist. So wird man z.B. Leader für einen bestimmten Themenbereich für ein paar Stunden oder Tage und danach wieder Follower.
(Klar gibt es auch noch Unternehmen welche versuchen das in Positionen zu quetschen - aber das klammer ich hier mal aus)

Nur wie sieht in so einem Umfeld nun Karriere aus? Gibt es das überhaupt oder ist Karriere ein Relikt ohne Ersatz?

Schwierig wird es damit aber auch irgendwie beim Jobwechsel wo z.B. Gehalt ja irgendwie auch mit Positionen verknüpft ist. Muss ich da doch "Karriere" machen um nicht irgendwann als Entwickler auf der Strecke zu bleiben?

Ich denke das muss sich mit der Zeit noch zeigen.
Wie geht Ihr damit um? Wie sehen eure Gedanken dazu aus?

Montag, 16. Juni 2014

Mit dem Rücken am Tellerrand

Es ist gut auch mal über den Tellerrand zu schauen. Manchmal sind wir so in "unserer Welt" gefangen, dass wir den Rest gar nicht mehr wahr nehmen.
Zum Beispiel muss ich mich immer wieder daran erinnern, dass nicht alle Menschen mindestens ein Smartphone haben. Oder das agile noch lange nicht Mainstream ist.
Nur weil wir uns in einem Umfeld bewegen, in dem die Dinge so scheinen wie sie sind, heißt das noch lange nicht, dass dem auch so ist. Ein Typisches Beispiel für den Unterschied von Realität und Wahrnehmung der Realität. Aber auch um neuen Ideen eine Chance zu geben, welche scheinbar nicht funktionieren können, weil sie nicht in unsere Gedankenwelt passen ist es sinnvoll ab und an über den Tellerrand zu schauen.

Heute habe ich noch einen Tweet, welcher darauf hinweist gesehen:


Wenn uns das einmal bewusst geworden ist, dann neigen wir (oder zumindest geht es mir so) dazu möglichst oft über diesen Tellerrand zu schauen.

Dabei kann es aber passieren, dass wir so sehr damit beschäftigt sind, unseren Horizont zu erweitern, dass wir gar nicht merken, dass wir mit dem Rücken bereits am Tellerrand stehen und nicht mehr wahrnehmen was direkt vor uns im Teller ist.

So passiert es mir immer wieder, dass ich sehe was ich alles (noch) nicht weiß oder kann, dass ich dabei vergesse, welcher Weg bereits hinter mir liegt und was ich bereits alles kann. Dadurch unterschätze ich mich regelmäßig. Oder ich übersehe Chancen welche sich in der aktuellen Situation ergeben.
Auch wird es schwierig daran zu denken alle anderen mitzunehmen, wenn man sie aus den Augen verliert.

Also auch mal die eigene Suppe betrachten!

Montag, 26. Mai 2014

Arbeit und Leistung muss neu definiert werden


In der Physik ist Arbeit definiert als Kraft (zum Bewegen einer Masse) mal Weg und Leistung Arbeit durch Zeit.
In unserer Arbeitswelt war es über Jahrzehnte oder Jahrhunderte hinweg möglich daran angelehnt die erbrachte Leistung eines Arbeitnehmers (oder auch Auftragnehmers) in Zeit zu messen.

So erbrachte ein Arbeiter am Fließband eine gewisse Leistung messbar in gefertigten Teilen in einer gewissen Zeit.

In dem Zusammenhang ist es auch nachvollziehbar die dem Arbeitgeber (Auftraggeber) vertraglich geschuldete Arbeit in Zeiteinheiten z.B. Wochenstunden zu definieren. Diese Arbeit kann auch dann direkt gesehen werden. Steht der Arbeiter am Fließband und geht seiner Tätigkeit nach so erbringt er die geschuldete Arbeit. Tut er was anderes so erbringt er sie nicht. (Natürlich vereinfacht gesehen)

Aktuell findet ein Wandel in der Art der Arbeit statt. Es gibt immer mehr sogenannte "Wissensarbeit". Dabei ist wie z.B. in der Softwareentwicklung das Ergebnis der erbrachten "Arbeit" gar nicht mehr so greifbar und vor allem ist die Tätigkeit, welche zu dem Ergebnis führt nicht mehr so einfach definierbar. Eine "fertige" Software ist nicht das reine Ergebnis von physischer Tätigkeiten wie z.B. dem Tippen von Tasten. Sondern vielmehr von angewendetem und richtig kombiniertem Wissen. Das Tippen der Codezeilen ist nur noch die Nutzbarmachung der bereits erbrachten Arbeit. Dies ist mittlerweile auch so weit akzeptiert das wohl die wenigsten die Leistung ihrer Softwareentwickler in geschriebenen Codezeilen messen. (Was auch Kontraproduktiv für ein gutes Ergebnis sein kann).

Wenn die "Arbeit" nun aus dem aufbauen, anwenden und verknüpfen von Wissen also lernen, Kreativität, Problemlösen und kombinieren von Wissen, kurz denken und Kommunizieren besteht, dann fühlt sich das erfassen der "Arbeit" oder der erbrachten "Leistung" in Zeiteinheiten falsch an.