Escape the Feature Factory

Wenn der Vorgesetzte darauf hinweist, dass "wir eine große Familie sind", geht es meist nicht um ein bevorstehendes Fest.

Regeln, Prozesse und Vorschriften im Unternehmen sind einzuhalten, oder? Doch warum ist dann "Dienst nach Vorschrift" etwas Schlechtes?

Neben Diversität in unserer Gesellschaft ist auch immer öfter von Teamdiversität die Rede. Was ist gemeint und ist es in der Softwareentwicklung sinnvoll?

Wie treffen Teams Entscheidungen? Und wie kann man das sichtbar machen, um die Mitsprachemöglichkeit für alle Mitglieder zu verbessern?

Wenn in Konzernen interne Politik und Machtreviere eine Rolle spielen, können Offenheit und Transparenz einer positiven Selbstdarstellung weichen.

Was tun, wenn man als Entwickler in der Feature Factory sitzt und nur einen Ausschnitt aus dem gesamten Entwicklungsprozess sieht?

Manche Firmen wissen genau, was sie nicht machen. Aber nicht so genau, was sie machen.

Maßnahmen zur Fortbildung einzelner Personen sind in vielen Firmen anzutreffen. Ein strukturierter Ansatz für ganze Teams fehlt oft.

Ein Product Backlog ist der zentrale Dreh- und Angelpunkt in der Produktentwicklung. Wer darf eigentlich hineinsehen?

Eine oberste Direktive gibt es nicht nur für Mitglieder der Sternenflotte, sondern auch für Softwareteams. Wie setzt man sie operativ um?

Als Developer reden wir oft mit Nicht-Entwicklern, darunter User, Stakeholder oder Chef. Dabei ist es manchmal gut, nicht viel zu sprechen, sondern aufzustehen.

Wenn ein Team in alten Best Practices verharrt, ist es Zeit für einen Frühjahrsputz. Stellt Eure Working Agreements auf den Prüfstand!

Führung ist nicht immer mit der Führungsposition gleichzusetzen. Die Silent Leaders im Team sind wichtig.

Softwareentwickler sind nicht gerade als die großen Kommunikatoren bekannt. Doch was heißt schon groß? Vielleicht legt man hier die falschen Maßstäbe an.

Wer MS Teams, Slack und ähnliche Werkzeuge nur für den Chat nutzt, verschenkt das Potenzial der Tools für die Teamarbeit.

Agiles Arbeiten mit zu spätem beziehungsweise ohne Story Splitting bringt zahlreiche Nachteile durch zu große Arbeitsaspekte mit sich.

Wenn Entwicklerteams den Sinn einer Aufgabe nicht verstehen, wurde die User Story vielleicht zu früh gesplittet.

User Story Splitting heißt nicht, ein Ticket in Implementierungsschritte zu zerlegen. Aber was denn dann?

Wie man Story Splitting betreibt, ist ein guter Indikator für das ein oder andere Verbesserungspotenzial im Entwicklungsprozess.

Ein Sprint ist erst dann fertig geplant, wenn alle zu mindestens 100 % ausgelastet sind. Oder?