Ist das Jira Board nicht eine Umsetzung von einem Kanban Board?
Das nutze ich aktuell nur extern in einem Projekt und bin damit mehr oder weniger zufrieden.
Würde sonst nie den Überblick behalten was noch gemacht werden muss etc.
[…]
Jein. Jira ist für Scrum und Kanban geeignet. Das eine ist mit Sprints, das andere mit Durchflussmessung.
Die Software ist auch okay, allerdings ärgere ich mich, dass Youtrack von Jetbrains noch keine volle Alternative ist, weil Atlassian einfach richtig teuer ist.
Eine Sache, die ich von Leuten auf der Business Seite schon oft gehört habe, ist, dass es über die Zeit halt allen Druck von den Devs nimmt.
Item braucht halt so lange es braucht. Muss ja richtig gemacht werden. Backlog kann hin und her geschoben werden, ohne Time Estimates ist das aber auch schwierig und dem Entwickler ists eh egal und er arbeitet eins nach dem anderen ab. Mal schauen wie lange es dauert.
Das ist sicher kein Problem, wenn Motivation und Kompetenz voll da ist, aber wie geht Ihr damit um, wenn ihr mals Gefühl habt, bestimmte Entwickler sind nicht voll am performen? In Scrum wird das schön in den Sprint Reviews thematisiert, in Kanban wiederum verschwindet es einfach im stetigen Fluss, oder habt ihr da andere Instrumente für?
Das ist auch mit Scrum nicht besser. Habe da grad so ein Projekt wo ein Teil der Entwickler rumpimmeln weil sie genau wissen, dass die Firma sie braucht. Da kannst Du im Review und in der Retro sagen was Du willst. Gerade wenn es sich um Legacy-Systeme handelt, die man mit etwas halbwegs zeitgenössischen ersetzen will, was nicht nur einer der alten Entwickler beherrscht. Da wird sich mit Händen und Füßen gegen jedes strukturierte Vorgehen gewehrt, was das geheime Herrschaftswissen in Gefahr bringen könnte. Immer ist dann alles ganz schwierig und muss 10x getestet und recherchiert werden. Zeitschätzungen sind imo Schwachsinn (aber vom Management gewollt) und für Komplexitätsschätzungen sind die meisten zu doof. Am Ende wird es dann ein "Hupsi, alles viel aufwendiger als gedacht. Konnte ja keiner ahnen." Gerade bei Projekten wo man viel neues macht, was noch nie einer in der Firma gemacht hat, wird es mit dem Schätzen noch sinnloser, weil man sich irgendeine Zahl aus dem Arsch ziehen muss (weil das Management es so will).
Und weil der Arbeitsmarkt so ist wie er ist … kommen die Entwickler am Ende mit ihrer Verweigerungshaltung auch noch durch. Da vergiftet auch ein "Alter" ohne Bock, problemlos die Attitüde eines ganzen Teams indem er ständig wegen jedem Mist rumheult und es schon als Sklaventreiberei bezeichnet wenn man mal fragt was er eigentlich die letzten Wochen so gemacht hat. (Und wenn man ihm sagt, dass er gerade das Rad neuerfunden hat, und es für Problem X schon eine fertige Spezifikation gab (die ich mit dem Team mehrfach diskutiert hatte), dann beschwert er sich, dass ich ihm in seine Kompetenz als Entwickler reinreden will, indem ich Implementierungsdetails vorgebe. Buhuuu no shit Sherlock, wir haben es gemeinsam ausgemacht ich hab es definiert und dann habt ihr es euch trotz mehrfacher Aufforderung nie angeschaut.)
Ich habe da zero Mitleid mit solchen Entwicklern und wünsche mir einen Arbeitsmarkt zurück in dem nicht selbst das dümste Fallobst noch einen Job hinterhergeschmissen bekommt. Diese Menschen leben am Ende vom Einsatz ihrer motivierten und teamorientierten Kollegen.
Im aktuellen Kontext, muss man solchen Leuten signalisieren, dass man nicht mehr mit ihnen plant, und dass sie sich was neues suchen sollen … auf die Gefahr hin, dass man sie 3 Monate lang freistellen muss (vorausgesetzt man kann sie ersetzen). Rausekeln ist auch asi, aber leider ist es quasi unmöglich jemanden wirklich loszuwerden. Wer charakterlich scheiße ist lässt sich nämlich, meiner Erfahrung nach, auch nicht mehr richtig einnorden nach einem gewissen Alter. Die geben dann einfach ficks und ziehen die Leistung runter.
Ja, ok, wenn Du in der Rahmenkonstruktion Fixpreis gegen ne Spez hast, ist das ja eh nen Wasserfall/agiler Hybrid. Da versteh ich, dass man innendrin den Admin Aufwand einfach so klein wie moglich halten will und dazu gehört sicher nicht Sprints zu planen, durchzuführen und zu reviewen. Dank Fixpreis kann Dir Performance auch egal sein.
Ja, das haben sie bei uns auch noch nicht kapiert und glauben, dass ein paar Fresszettel mit groben Ideen ausreichend für große Projekte sind … und, dass man bei agilen Projekten auch vorher sowohl Kosten, Zeit als auch Qualität festlegt und dann den köpft der darauf hinweist, dass es nicht funktionieren konnte. (Wenn man gleich zu Beginn darauf hinweist wird man einfach ignoriert … "man muss sich einfach nur anstrengen und es richtig wollen.")
Mhh, gute Frage. Also ich sehe das natürlich aus Perspektive des Entwicklers. Meiner Erfahrung nach finden PMs Meetings total toll, darum sitzen PMs über kurz oder lang in jedem regelmäßigen Meeting und damit wird jedes Meeting über kurz oder lang ein PM Meeting für das sich hauptsächlich der PM interessiert.
Und so sitzt man dann in der VK und spielt für den PM Augsburger Puppenkiste, während parallel dazu ein Gruppenchat offen ist in dem man sich über die Entwicklung unterhält. Das kann doch so nicht im Sinne des Erfinders gewesen sein
Ist bei uns nicht so schlimm, sondern anders schlimm. Wir spielen eher das Spiel
"Der PM wünscht sich etwas, weigert sich seine Anforderungen ordentlich aufzuschreiben. Beschwert sich, dass die Schätzungen so hoch sind, eskaliert zum Vorstand bis die Schätzungen das sind was man hören wollte, und ignoriert die die sagen, dass es so nicht funktionieren kann. Das Ignorieren jeglicher technischer Details die Showstopper sind gehört natürlich dazu 'Ich bin nicht für Technik zuständig!'"
Und es mündet dann in
"Das ist ganz anders als ich es wollte. Hättet ihr mir mal richtig zugehört, dann wäre klar gewesen, dass mein Dreizeiler für ein 100 PT+-Projekt ganz anders interpretiert werden musste. Ihr müsst nachbessern aber ich sage euch nicht wie, sondern entscheide erst wenn ich fertig bin ob es mir gefällt und was ich eigentlich wollte."
Am Ende sind die Entwicklungsteams schuld weil sie nicht Gedankenlesen konnten. PM natürlich Engel.
Meine 2c: PMs die nicht selbst aus der Technikecke kommen oder dafür Verständnis aufbringen kann man direkt im Moor versenken. Unsere PMs sind bis auf eine Ausnahme Vollidioten die sich vor allem durch Skill im Blame Game ausweisen … und, um zum Thema zurückzukommen: Die sich auch jedem Bisschen strukturierter Arbeit in Jira und Confluence verweigern. Das ist nämlich so Nerdkram für die Kellerkinder. Diese Leute möchte man jedes Mal mit dem Knüppel verarzten wenn man ihre Scheiße sieht.
Macht Sinn für mich. Frage mich nur wie das bei reinem Kanban ganz ohne Aufwandsschätzungen, Spez oder fixe Vereinbarungen läuft. Zieht das hier jemand konsequent durch?
Für mein eines Team ist es eine Art Scrumban (weil Jira einen durch adv Roadmaps zu Scrum zwingt). Da machen wir den Sprint voll und es wird fertig was fertig wird. Dadurch, dass das Projekt viel Neues enthält was nicht einschätzbar ist, sparen wir uns die Schätzungen und arbeiten im Endeffekt Schritt für Schritt.
Das Problem ist imo, dass Schätzungen genau nur dann funktionieren, wenn man einigermaßen abschätzen kann wie viel Aufwand etwas ist. Und das ist eben nur dann gegeben, wenn ein Team etwas macht, was es vorher schon einmal in anderer/ähnlicher Form getan hat. Leider zeichnet sich einiges bei uns dadurch aus, dass entweder die Leute zu juniorig sind, um diese Erfahrung zu haben, oder der Kram ist einfach Neu.
Entsprechend erfinde ich in Absprache mit dem Team irgendwelche Zahlen die halbwegs plausibel erscheinen, weil es so gefordert wird … und hoffe, dass das Team nicht zu sehr rumpimmelt. Zsfg.: Ich möchte mit kompetenteren Leuten arbeiten :/