Quicklinks
[b][/b]
[i][/i]
[u][/u]
Sonderzeichen
± ÷ ² ³ ¼ ½ ¾
µ £
® ©
[ ] { }
Textformatierung
[left][/left]
[center][/center]
[right][/right]
[justify][/justify]
[space]
[s][/s]
[small][/small]
[big][/big]
[hr]
[sub][/sub]
[sup][/sup]
[style={{name}}][/style]
[code][/code]
[spoiler2=Thema][/spoiler2]
[url][/url]
[img][/img]
[video][/video]
Email-Adresse spamsicher anzeigen
[pre][/pre]
Farben
[rot][/rot]
[blau][/blau]
[gruen][/gruen]
[orange][/orange]
[lila][/lila]
[weiss][/weiss]
[schwarz][/schwarz]

Smileys
smile
zunge
wink
grin
hmm
shocked
rose
devil
sick
heart
blush
mad
sad
frown
laugh
cool
nerd
clap
kiss
top
flop
engel
idee
smokin
Smileys allgemein
Herz
Grinsen
Idee
Frage
Achtung
Hm
Top
Idiot
Müde
Müde
Suchen
Fragen
Error
Achtung
Ah!
Wissen
Doc
Es gibt Ärger!
Ärger
Hallo
Error
Hm
Hi Hi
Hi Hi
Ja Ja
Frieden
SOS
Hurra
Hallo
Hallo
Große Smiley
1tys-27[1]
1tys-ak[1]
1tys-aa[1]
1tys-24[1]
1tys-1w[1]
1tys-2b[1]
1tys-29[1]
1tys-2c[1]
1tys-64[1]
1tys-ab[1]
Top
1tys-28[1]
1tys-65[1]
1tys-1x[1]
1tys-ad[1]
1tys-21[1]
1tys-9x[1]
1tys-al[1]
1tys-23[1]
1tys-9y[1]
Schilder Smiley
1tys-60[1]
1tys-ag[1]
1tys-ah[1]
Hallo
1tys-5s[1]
1tys-ai[1]
Excellent
1tys-am[1]
1tys-62[1]
1tys-ae[1]
1tys-fi[1]
Herzlich Willkommen
1tys-9t[1]
1tys-5v[1]
1tys-5y[1]
1tys-5x[1]
1tys-9u[1]
1tys-5w[1]
1tys-5u[1]
1tys-fe[1]
1tys-5q[1]
Danke
78q-2i[1]
Willkommen
1tys-a1[1]
1tys-5r[1]
1tys-63[1]
1tys-61[1]
78q-5m[1]
   
Niklas
Beiträge: 15 | Punkte: 27 | Zuletzt Online: 08.05.2019
Name
Niklas
Registriert am:
16.04.2019
Geschlecht
männlich
    • Niklas hat einen neuen Beitrag "Skalierung von Scrum" geschrieben. 08.05.2019

      Zitat von Coach F. im Beitrag #7
      Das ist für erfolgreich agiles Arbeiten aber eben Grundvoraussetzung. Alles andere ist Geld- und Zeitverschwendung. Ich sehe das ähnlich. Wer es mal verstanden hat, hat mit dem Skalieren auch keine Probleme.


      Ich gebe dir vollkommen recht, dass dies für (erfolgreich) agile Arbeiten Grundvoraussetzung ist. Aber ich sehe dies zusätzlich als meine Aufgabe, meine Kunden diese Grundvoraussetzung zu erklären und dabei zu unterstützen, diese zu schaffen. Ich sehe mich weniger als jemanden, der nur dorthin geht, wo eh schon alles funktioniert und nur ein Moderator für bestimmte Events gesucht wird.

    • Niklas hat einen neuen Beitrag "Skalierung von Scrum" geschrieben. 02.05.2019

      Zitat von Nina im Beitrag #5
      Wenn das gedanklich in den Köpfen drin ist, ist der Rest gar nicht so schwer.


      Da gebe ich dir vollkommen Recht... aber wie häufig finden wir das vor, speziell in großen, alten Unternehmen?

    • Niklas hat einen neuen Beitrag "Kultur folgt Struktur? - Larman'sche Gesetze" geschrieben. 02.05.2019

      Zitat von Nina im Beitrag #2

      Womit ich mich nicht identifizieren kann, ist Punkt 4. Ich habe es nie erlebt, dass Kultur irgendetwas folgt. Meine Erfahrung ist eher die, dass Kultur die Basis für Alles ist.



      Ich meinte auch nicht, dass Kultur automatisch der Struktur folgt. Mein Gedanke ist der, dass wenn eine Organisation zu starr ist (und das sind die meisten großen Unternehmen), dann können die dortigen Machtstrukturen und bürokratischen Prozesse eine Veränderung der Kultur verhindern.

      2 Beispiele:
      Prinzip: Technische Exzellenz --> Haben Organisationen übergreifend einen Wasserfall/Releaseplan und die Einhaltung dessen ist das oberste Ziel, dann habe ich schon oft erlebt, dass die Technische Exzellenz und die Entscheidungshoheit darüber den Teams genommen wurde und damit die Kultur gestört/zerstört wurde.
      Tägliche Zusammenarbeit von Fachspezialisten und Entwicklern --> Fachspezialisten sind zum Teil rar und haben wenig Zeit und dann wird erwartet, dass es einem reicht, wenn der Produt Owner 1x die Woche Zeit hat. Auch das zerstört die Kultur denn es ist keine Zusammenarbeit mehr und der Fachspezialist (so meine Erfahrung) wird dann häufig erwarten, dass alle seine Wünsche vom letzten Mal verstanden und 1:1 umgesetzt haben. Dass es an ihm liegen könnte, da er keine Zeit hat sich um seine Pflicht zu kümmern, dass das Verständnis der Anforderungen bei allen im Team gleich ist, daran denkt er dann nicht und das verhindert die Veränderung der Kultur.

    • Niklas hat einen neuen Beitrag "Skalierung von Scrum" geschrieben. 24.04.2019

      Zitat von LaberKachelSülz im Beitrag #3
      Hm, ich werde nicht warm damit. Es ist mir vieles zu unkonkret. Beispiele:

      Angenommen ich habe ein Scrumteam für ein Produkt, zuerst mit 5 Leuten, nun sind es 8. Nun sollen noch vier Leute dazu kommen. Für orginal Scrum ist das zuviel. Was soll an der Frage falsch sein wie man Scrum skaliert?

      "Find a Product Owner that understands the market, has an entrepreneur mentality and give her the funding to lead the product lifecycle." - das ist doch Scrum. Aber wie soll EIN PO das alles schaffen?

      "Develop teams that can produce end-to-end customer features (a.k.a. Scrum Teams) and use them as your main organisational building block." - auch das ist doch Scrum.

      "Organise your teams, that work on 1 product, to work in a single iteration..." - dito

      "Move to cross functional line managers" - und wie sollen die konkret arbeiten? Was ist deren Ziel, die hängen die mt Scrummaster PO und Entwickler zusammen?

      "Introduce a Human Operations system" - den Begriff habe ich noch nie gehört.



      Ich versuche es mal mit einem Beispiel zu verdeutlichen, wie ich den von mir zitierten Blogartikel interpretiere.

      Beispiel für ein Unternehmen:
      Geschäftsführung --> Fachbereiche A, B, C --> IT-Abteilungen 1, 2, 3 / Betrieb / Datawarehouse
      Zum "Ausprobieren" von Scrum sagt das Unternehmen nun IT-Abteilung 1, dass sie aus ihren Mitgliedern doch mal ein Scrum Team bilden sollen und die Scrum Events, Rollen und Artefakte benutzen wollen. Nun läuft es gut, das Team ist motiviert und glücklich und das Unternehmen glaubt, dass es agiler werden muss, weil die Anforderungen von außen sich häufiger und schneller ändern.

      Frage: Wie geht man nun vor?

      Was ich am häufigsten sehe ist, dass man in den vorhandenen Silos (einzelne Fachbereiche, einzelne IT-Abteilungen, Betrieb, Datawarehouse, ...) nun Scrum einführt bzw. mehrere Teams mit Scrum arbeiten lässt und glaubt/hofft, dass dadurch das ganze Unternehmen agiler wird. Das Problem daran ist, dass es nicht funktioniert. Denn die ganze Steuerung (z.B. durch Fachbereiche) ist Silo/Hierarchie getrieben. Die Teams arbeiten zwar ein bisschen nach Scrum, doch der Product Owner soll eher feste Anforderungen umsetzen und hat eigentlich nichts zu entscheiden (der Fachbereich entscheidet den Scope Monate vorher). Er kann auch nicht wirklich spontan die Software produktiv schalten, da sie zu viele Abhängigkeiten zu anderen Produkten des selben Unternehmens hat.

      Ich persönlich habe langjährige Erfahrung damit, dass dies nicht funktioniert. Wenn das Unternehmen agiler werden will, dann muss es die Organisation verändern. Dann muss es in Frage stellen, ob die Silo-Struktur und damit das Silo-Denken mit der Anforderung der Agilität vereinbar ist. Dann muss die Organisation überlegen, ob sie nach jedem Sprint etwas in Produktion liefern kann, nur weil eine IT-Abteilung in Scrum Teams arbeitet oder ob nicht doch die Abhängigkeiten zu anderen Anwendungen, zum Betrieb und zu DataWarehouse das verhindern. So interpretiere ich den Artikel und deswegen stimme ich dem inhaltlich zu.

    • Niklas hat das Thema "Skalierung von Scrum" erstellt. 24.04.2019

    • Niklas hat einen neuen Beitrag "Ausbildung zum Scrum Master" geschrieben. 17.04.2019

      Ich habe folgende Meinung, was man nach einer Zertifizierung zum Scrum Master kann:
      Man kann das Scrum Framework beschreiben.

      Was allerdings NICHT Teil des Scrum Guides oder der Zertifizierungskurse ist, sind die Methoden, welche man verwenden kann, wenn der IST-Zustand der Organisation/Projekt/... eben nicht dem Scrum Framework entspricht.
      Man bekommt also keine Coaching Ausbildung, man diskutiert keine Techniken, wie eine Retrospektive ablaufen kann, man bekommt keine Idee davon was man tun muss, wenn der Product Owner sich wie ein Teamlead verhält oder keine Zeit für das Team hat, und und und...

      Ich halte es für richtig und wichtig, dass ein Scrum Master die Theorie kennt und dafür ist es notwendig, dass man sich immer wieder mit ihr beschäftigt.
      Aber alles andere, der eigentliche Alltag eines Scrum Masters, fängt dann erst an.

      Und genau da ist natürlich auch die Schwierigkeit für Personalentscheidungen im agilen Umfeld, welche oft von Personen getätigt werden, die weder wissen was das ist noch ein agiles Mindset haben. Hier zählen dann oft nur Zertifizierungen und Anzahl Berufsjahre in der Rolle und der Rest wird nach Bauchgefühl entschieden (also danach, wie sehr man den Charakter mag oder auch nicht). Und diese Scrum Master werden dann oft ungefragt über Teams gestülpt, welche sich dann denken... "Oh Backe!"

    • Niklas hat einen neuen Beitrag "Ergebnisse messen" geschrieben. 17.04.2019

      Ja, ich kenne diese Fragen.

      "Wie kann ich messen, ob ich mit agilen Arbeitsweisen effizienter werde?"
      Wenn ich eine veränderte Arbeitsweise messen will, dann muss ich ja wissen, warum ich Agile eingeführt habe - was wollte ich ursprünglich verbessern? Dann muss ich >geeignete< Vergleichsmetriken haben, um zu dieser Frage eine Aussage treffen zu können.
      Wollte ich die Lead Time verbessern von Fachbereich beauftragt etwas dringendes bis Software ist in Produktion? Das kann man messen.
      Wollte ich die Qualität verbessern z.B. durch Testautomatisierung? Hier könnte ich Defects/Bugs vergleichen... ist nicht leicht, da Einstufung oder allein die Frage ob es ein Defect oder eine neue Anforderung ist, nicht einfach zu beantworten ist.
      Wollte ich den Aufwand für Umsetzungen verringern (also den schnelleren Wasserfall machen)? Hier kann man meist gar nichts messen. Man hat aus der Vergangenheit grob die Anzahl an Personentagen, meist vermischt mit Meetings, Defect Fixing und anderen Nebentätigkeiten. Die gleiche Anforderung unter den gleichen Umständen mit der gleichen Software in der gleichen Größe und der gleichen Mannschaft wird man nicht mehr als einmal durchführen können.
      Wollte ich den Overhead verbessern der entsteht, wenn Fachkonzeption an Entwicklung, die an Test übergibt und sich dann alle treffen und merken, dass Fachkonzeption etwas anderes wollte? Hier hat man meist keine Zahlen aus der Vergangenheit und selbst wenn, was genau will man messen? Die Anzahl/Zeit der Absprachemeetings? Die Anzahl/Zeit der nachträglichen Korrekturen? Selbst wenn man das vergleichen würde, würde man immer noch berücksichtigen müssen, ob man den gleichen Mehrwert erzeugt hat. Auch nicht leicht. Aber man kann natürlich die Teams fragen durch grobe Umfragen (dazu müsste man die gleichen allerdings auch vorher gemacht haben).

      "Werden mir mit Scrum besser?"
      Hier würde ich mit der Gegenfrage antworten, warum Scrum denn eingeführt wurde (s.o.) und dann überlegen, ob man das bestätigen oder widerlegen kann.

      Aus meiner Erfahrung ist der IST-Stand bei vielen Unternehmen so, dass sie für die Vergangenheit ganz grob sagen können, welche Beauftragung wie viel Aufwand verursacht hat (ganz grob, weil meist Wartung durch eine Mischkalkulation abgedeckt wird etc.). Ich kenne kein Unternehmen was behauptet, dass sie pro Beauftragung sagen können, welche teuer/günstig war oder wo effizienzt/verschwenderisch gearbeitet wurde, da diese Systeme darauf getrimmt sein, Planungen einzuhalten (also lieber länger zu brauchen, damit man nicht den Vorwurf bekommt, absichtlich zu klein zu schätzen).
      Die Erwartung, dass man nun etwas messen und mit früher vergleichen kann, was man noch niemals zuvor messen konnte, hat meiner Erfahrung/Meinung eher etwas mit einem 'mittleren Management' zu tun, was sich nicht ändern möchte und mit diesen Fragen eine (weitere) Veränderung blockieren möchte und es oft leider auch schafft.

    • Niklas hat einen neuen Beitrag "Ergebnisse messen" geschrieben. 17.04.2019

      Für mich ist hier eine interessante Frage, was man denn an einem "Ergebnis" wissen/messen will! Will ich nur den Aufwand wissen, dann reicht meist ein Blick in den Stundenzettel. Der sagt mir aber nicht, ob ich gut/schnell/effizient gearbeitet habe, ob meine Testabdeckung/Qualität gut ist oder ob ich es vermieden habe, technische Schulden aufzubauen und er sagt mir erst recht nicht, was denn die Arbeit Wert ist oder wer der bessere Mitarbeiter ist.

      Verfolgt der Product Owner mit seinen Features Mehrwert, der gemessen werden kann, dann ist das die viel spannendere Fragen... also wieviel Personen wandern auf meine Website... wieviele Kunden verwenden eine neue Funktionalität... wie lange braucht ein Kunde im Schnitt, um einen Bestellvorgang abzuschließen... das wären für mich viel sinnvollere Messwerte, die dem Product Owner Rückmeldung geben können, ob die umgesetzten Features sinnvoll waren.

    • Niklas hat einen neuen Beitrag "Empfehlenswerte Literatur?" geschrieben. 17.04.2019

      Weitere Literatur (aus "Large Scale Scrum - More with LeSS"):
      - "Leading Teams" - Richard Hackman (30 Jahre Teamforschung über das Bilden selbstverwalteter Teams)
      - "The Skilled Facilitator" - Roger Schwarz (Moderationstechniken)
      - "Co-Active Coaching" - Kimsey-House (Coaching)
      - "Die 5 Dysfunktionen eines Teams" (Geschichte wie Teams (nicht) funktionieren)
      - "Humble Inquiry" - Edgar Schein (Erfahrung aus 50 Jahre Organisationsentwicklung und Coaching von Organisationen)

    • Niklas hat einen neuen Beitrag "Ergebnisse messen" geschrieben. 17.04.2019

      Ich habe viel Story Points verwendet, allerdings nicht zum "Messen" sondern nur zum Schätzen. Ich finde die Einheit sehr gut, um relativ schnell in einem Team zu einer Schätzung zu kommen und die Fibonacci-Reihenfolge stellt meiner Erfahrung nach gut dar, wie die Ungenauigkeit steigt bei zunehmender Größe/Komplexität/Unsicherheit.

      Falls Story Points für das Messen von Leistung verwendet werden, dann gibt es unsägliche Diskussionen, denn natürlich passen Schätzungen nicht immer zum tatsächlichen Aufwand. Und dann? Schätzungen nachträglich verändern, damit die Velocity nicht fällt?? Immer größer Schätzen, damit die Velocity nicht fällt?? Meine Erfahrung ist, dass je größer der Druck in diese Richtung geht, desto mehr wird an den Zahlen manipuliert, nur um sich nicht rechtfertigen zu müssen und dann werden es in 'agile Kartons' verpackte Aufwandsschätzungen mit viel Puffer.

      Man muss sich also entscheiden, denke ich. Entweder es ist eine Schätzgröße, um zukünftige Sprints mit wenig Schätzaufwand grob vorausplanen zu können (in der Form, dass ein Product Owner sagen kann: "Nach der Schätzung meines Teams müssten wir in knapp 2 Sprints mit dem Feature fertig sein. Wenn ich dem Kunden 3-4 Sprints verspreche, müsste ich definitiv auf der sicheren Seite."), oder es ist nur ein anderer Name für Personentage (PT) und ein Teil eines Wasserfall-Arbeitsplans."

      Falls die Ergebnisse/Velocitys zu stark schwanken oder sich sehr stark verändern, wäre das für mich definitiv ein Punkt für die Retrospektive. Zum einen könnten hinter diesen Änderungen Probleme des Teams stecken, mit welchen sich das Team befassen oder sie zumindest kennen sollte oder der Product Owner bekommt Probleme mit seinen Versprechen/Vorhersagen an die Außenwelt und es muss eine Unterstützung für den Product Owner gefunden werden, dass er realistischere Aussagen nach außen hin treffen kann.

    • Niklas hat das Thema "Experimente/Übungen um Pull vs Push darzustellen" erstellt. 17.04.2019

    • Niklas hat einen neuen Beitrag "Die richtige Struktur für Scrum Master/Agile Coaches" geschrieben. 16.04.2019

      Ich kenne aktuell auch kein Unternehmen, bei denen die Agile Coaches unter der Geschäftsführung hängen und genau da sehe ich schon ein Problem. Je nach Befugnis des Coaches, wird global optimiert oder lokal. Ist er Teil der Entwicklungsabteilung, so kann er hier viele agile Strukturen schaffen, die das Gesamtunternehmen aber kaum agiler machen, da alle anderen Bereiche (wie z.B. Fachabteilungen) in ihren eigenen Silos ihr eigenes Ding weiter machen.
      Je höher ein Coach Gehör findet, desto globaler kann eine Veränderung und damit hoffentlich Verbesserung erfolgen.

    • Niklas hat einen neuen Beitrag "Agile Coach - Scrum Master" geschrieben. 16.04.2019

      Ich erlebe immer noch regelmäßig, dass Unternehmen keine Vorstellung davon haben, was ein Scrum Master oder Agile Coach ist. Wenn ich mir die Stellenbeschreibungen anschaue, dann könnte dies 1:1 eine Stellenausschreibung zum Teamlead oder Projektmanager mit nur ein paar Wortersetzungen sein.
      Wenn ich in Unternehmen sowohl Agile Coach als auch Scrum Master Rollen sehe, dann meist in der Form, dass der Agile Coach die Führungsebene zur Veränderung coachen soll/darf, während der Scrum Master bitte nur sein Team (evtl. auch exkl. Product Owner) coacht und den Rest der Organisation bitte in Ruhe lässt.

      Die Frage, was Karriere in einer 'agilen Organisation' bedeutet, finde ich schwierig. Das alte Modell sieht ja vor, dass man immer mal wieder seine Rolle komplett verändert - nicht weil man es will oder Interesse in der Richtung hat, sondern weil es mehr Geld bringt. So landen die falschen Leute in den falschen Positionen.
      Meiner Meinung nach sollten agile Organisationen andere Karrierepfade haben, die es einem erlauben im gleichen Bereich zu bleiben und trotzdem mehr Verantwortung, Weiterbildung und mehr Lohn zu bekommen.

      Aktuell ist wohl das lukrativste die Zertifikatstreppen hochzuklettern und offizielle Kurse für die großen Zertifikatsvertreiber zu halten. Je nach Organisation kann aber auch ein Product Owner (oft im Fachbereich angesiedelt) eine sehr gut verdienende Rolle sein.

    • Niklas hat das Thema "Verstehen vs. Verinnerlichen" erstellt. 16.04.2019

Empfänger
Niklas
Betreff:


Text:
{[userbook_noactive]}


disconnected Foren-Chat Mitglieder Online 0
Xobor Xobor Community Software
Datenschutz