Scrum Teams – No Part Time!

Last week a attendee of a CSM training was upset that I said that I do not like part time team members in my teams.

She said this is ridiculous. Scrum would be so extremely hard on rules. All the benefits that people got during the last years: part time, working from home, going into the office when you want does not get valued by Scrum.

My answer was: “That is not what I said — I said: I do not like the idea of part time people in my teams. I tried to explain for two days that Scrum-Teams can do what ever they want, as long as they are getting more productive!”

People still believe that being flexible and not committed to the team, means: “I am more important than the team success”, is a useful work ethos.

Is is not! A football team goes together on the field! A surgery team works together, a delta force team works together.

A team based framework (Scrum, Scrum Alliance Websites) has as prerequisite: A Team!

A bunch of individuals who go to work — is not a team, they are only a bunch of workers!

Kanban or Scrum? – First Generation Agile Methods

I found again some very interesting wrong interpretations about how Scrum works.

Kenji Hiranabe and I discussed this point over a year ago before his second Kanban articlefor InfoQ. I argued and I believe Kenji concurred that Agile methods like Scrum are really small batch transfer push processes. There is no explicit pull system within a Sprint and it’s a stretch to suggest that the batch transfer at the beginning of a Sprint – the selection of the backlog – is a truly “pull” process. It is never described this way. It is described as a negotiation where the team estimate a set of stories that the product owner wants done. They compare the estimate with the previously achieved velocity and decide what can be fitted into the available time in the Sprint. If it were truly a pull system then there wouldn’t be any negotiation. The product owner would have a prioritized backlog and the team would simply pull the top (however many) stories from it and start work. (more …)

I do not want to argue about, if Scrum is a pull system or not – because everybody who does Scrum correctly knows it is a pure pull system and if you understand to what every Scrum teams evolves it practices than you will see that there is absolutely no difference between Kanban ideas and what Scrum does. The real point is:

They are both on different levels. Henrik Kniberg, has written an excellent article about Scrum and Kanban and does a really interesting mistake in this article:

Scrum and Kanban are both process tools

Tool means “anything used as a means of accomplishing a task or purpose” (dictionary.com). Process means how you work. Scrum and Kanban are process tools in that they help you work more effectively by telling you what to do. Java is a tool, it gives you a simpler way to programming a computer. A toothbrush is a also a tool, it helps you reach your teeth so you could clean them. (Henrik Kniberg, Kanban vs Scrum -A practical guide)

Although Ken always refer Scrum as a framework:

Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory*. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Within each iteration, Scrum employs self-organizing, crossfunctional Teams to optimize flexibility and productivity (Scrum Guide, Scrum Alliance)

Scrum is much more than a tool. And Scrum is definitely not “only” a tool. Scrum is a mindset, in the same sense as the Toyota Production System was always a mindset a philosophy and not only a tool:

What is the secret of Toyota’s success? The incredible consistency of Toyota’s performance is direct result of operational excellence. Toyota has turned operational excellence into a strategic weapon. This operational excellence is based in part in tools and quality improvement methods made famous by Toyota in the manufacturing world, such as just-in-time, kaizen, one-piece flow, jidoka, and jeijunka. These techniques helped spawn the “lean manufacturing” revolution. But tools and techniques are no secret weapon for transforming a business. Toyota’s continued success at  implementing these tools stems from a deeper business philosophy based on its understanding of people and human motivation. Its success is ultimately based on its ability to cultivate leadership, teams, and culture, to devise strategy, to build supplier relationships, and to maintain a learning organization. (The Toyota Way, Liker, p. 6)

You can translate / rewrite this whole paragraph for Scrum:

What is the secret of Scrum enforcing companies. …. This operational excellence is based in part in tools and quality improvements made famous by the agile software development movement: test driven development, continuous integration, pair programming, one-story-at the time, the task board …. the continuous success steems from a deeper business philosophy that is embedded in Scrum: we value transparency, honesty and  courage and we believe in people are adults, they can make decisions, they want to achieve things and  a lot of more things.

People who want to see Scrum as a tool, do not see that all these tool thinking leads again and again back to the idea that Scrum is a silver bullet or a methodology or a process tool. It is NOT!

The second thought I want to make clear here:

Scrum like all early (first generation) Agile methods really do not change the project management paradigm very much. They still use projects as the frame of reference and still have the triple-constraint (iron triangle) of scope-schedule-resources as an underpinning. (more …)

That is wonderful: The whole idea is incredible: Scrum is a first generation agile method! That is b….t

Scrum is now the de facto agile software development standard as it has evolved from the idea from managing a project to managing whole enterprises using Scrum. Scrum always talked about value adding, Scrum brought the whole flow idea into the agile community. Lean is a subset of all this – as we learn in Likers, Toyota Way that Lean is only a subset of the Toyota Way.

So comparing Scrum with Lean is nonsense as Scrum is lean by definition.

To enhance practices of people that try to develop software within Scrum by using some more clever ideas how to use a taskboard (btw, it was invented by the XP people and then transformed in the de facto work standard by Tobias Mayer and me) for Scrum teams are fully embraced by all Scrum people.

Because — Scrum teams use what works to make them more successful. They want to become truly knowledge based teams using all ideas about how to establish a the learning organization (Senge).

Nächstes Deutsches CSM Training | 8.+9. Juni in Wien

090426_postcard_scrum-starts-here-011CSM Training in München nächste Woche ausgebucht!

Die nächste Gelegenheit für ein
deutsches ScrumMaster Training gibts am 8. und 9. Juni in Wien!

Natürlich – weil in Wien – inkl. dem famosen ScrumCooking und Jürgen Margetich!
Umgehend für das Training registrieren! https://scrum4you.wordpress.com/trainings4you/ 
Nur ScrumCooking? Für eine Einzelbuchung des Kochevents inkl. Gast zum Essen am 8.6. ab 17.00Uhr kontaktieren Sie uns bitte direkt unter office(at)borisgloger.com. Preis € 250€ inkl.

Schon aktiver SrumMaster und immer Mühe mit Ihrem PO? Leben Sie Scrum – remove an impediment – und kümmern sich um die Weiterbildung in Ihrem Team – wäre das ein Verbesserungsvorschlag?!

Certified Product Owner Training
13/14. Juli   CSPO (deutsch) in Berlin 


Scrum — eine Revolution (6)

Scrum in Organisationen
Die Ideen die Scrum-Consultants über das Führen von Organisationen und großen Teams erarbeitet haben,  sind in den letzten beiden Jahren vermehrt, auch in deutschen Unternehmen angewandt und dabei erfolgreich eingesetzt worden. Einige Beispiele:

Da gibt es ein Unternehmen, dass ein „Programm“ durchführt in dem alle Entwickler, alle Business Analysts, einfach alle an einem Produkt arbeiten. Insgesamt mehr als 120 Mitarbeiter. Hier habe ich erfolgreich die Sprint Planning Meeting mit allen 120 Teammitgliedern in einem Raum durchgeführt. Bereits nach dem ersten Mal, waren alle Beteiligten mit dem Ergebnis so zufrieden, dass sich die Stimmung im Projekt verbesserte und das Meeting in dieser Form bis heute weiter geführt worden ist.
Nach ersten Schwierigkeiten, die bei der Größe dieses Projektes unweigerlich sind, ist dort auch das Konzept des Product-Owner Teams erfolgreich eingesetzt worden. Es hatte bei der Größe und Problematik des Projektes einige Zeit gedauert und viel Überzeugungsarbeit seitens des Managements, aber am Ende würde deutlich, dass dieses Team und das Product Owner Daily Scrum, die beste Form zum Managen dieses riesigen Projektes darstellte. Besonders gefreut hat mich, vor ein paar Wochen zu erfahren, dass man mittlerweile auf die zuvor eingeführten elektronischen Tools verzichtet: Das Storyboard liefert alle Informationen, die benötigt werden.

Ein anderes Unternehmen hat sich auf die radikale Umgestaltung des Software Lieferprozesses eingelassen. Wir haben in nur zwei Wochen Vorbereitungszeit ein Produkt Backlog für die gesamte Organisation erstellt. Nach etwa zwei Stunden gemeinsames Arbeiten wurden circa 160 Backlog Items identifiziert. Diese wurden dann in zwei weiteren Sitzungen á 1 Stunde priorisiert und geschätzt. Das Top-Management nahm danach noch einmal  Einfluss darauf und der erste Sprint wurde on-time um 09:00 Uhr morgens mit 6 cross-funktionalen Teams, 6 Product Owner und circa 40 eingebrachten Backlog Items gestartet. Das Sprint Planning dauerte genau 2 x 3 Stunden und alle gingen hoch motiviert in ihren ersten Sprint. Dieser war dann so erfolgreich, wie ich es erwartet hatte: Es gab keine offenen „Defects“, alles Vereinbarte wurde geliefert und ausnahmslos alle im Unternehmen waren zufrieden.

Aber damit war die Arbeit nicht abgeschlossen. Mit den Product Ownern zum Beispiel daran gearbeitet, dass die Product Backlog Items sprechender werden. Wir wollten erreichen, dass die Teams in Zukunft mit  User Stories konfrontiert werden. Wir wollten die Funktionalität als solche darstellen und jegliche Designaspekte herauslassen.

Daneben, war hier die Aufgabe, das Top-Management und das Mittlere Management so auf ihre neuen Aufgaben vorzubereiten und deren Tätigkeiten umzudefinieren, dass sie die Teams optimal unterstützen.
So wurde u.a. Aus den Teamleitern „Domainleads.“ Eine Namenskonvention, die ich von einem anderen Kunden übernommen hatte. Die Domainleads haben einerseits die Aufgabe die „Domain“ zu betreuen, also für die technologische Richtung der Firma zu sorgen und sie sind andererseits fachliche Führungskräfte, die die Karriere ihrer Mitarbeiter fördern. Sie sind fachliche Führungskräfte, ohne Managementaufgabe auf der täglichen Ebene. Sie steuern die strategische Ausrichtung des Unternehmens und sie stellen sicher, dass „ihre“ Mitarbeiter die notwendigen Skills haben oder entwickeln. Zusammen mit den ScrumMaster, die die Teams betreuen und sich darum kümmern, dass die Teams ihre Arbeit optimal bewältigen können, bilden die Domainleads den mittleren Management Level.
Die ScrumMaster organisieren sich als Team und die Domainleads selbst sind ebenfalls als Team organisiert. Die Produkte und Produktlinien werden durch die Product Owner vorangebracht und weiterentwickelt. Auch diese sind in einem Team, dem Product Owner Team organisiert.

Der Beweis ist also auch in Deutschland mittlerweile erbracht: Ganze Organisationen lassen sich nach den Prinzipien von Scrum steuern. Der Umbau zu einer Scrum-Organisaton ist jedoch nicht einfach, oder nebenbei zu erledigen. Sie benötigen tatsächlich Mitarbeiter, die sich diesem Ziel verschreiben und sie benötigen die Erfahrung eines Menschen, der das schon einmal gemacht hat. Meine Praxis zeigt mir immer wieder, dass vollkommen unnötige Fehler bei der Umgestaltung von Abteilungen oder Firmenbereichen gemacht werden.

Meist liegt es dann daran, dass nicht an die Möglichkeiten geglaubt werden, die entstehen, wenn man die Menschen einfach nur machen lässt:

Scrum ist nur ein Weg, der einem hilft einem Weg zu finden, die Dinge richtiger zu machen.

Scrum User Groups in Deutschland

Ich habe auf der Scrum Alliance Website nur diese User Group in Deutschland gefunden:

About This Group

German user group dedicated to Scrum since 2006. Past events include:

– June 2006 (Frankfurt, organised and sponsored by Joseph Pelrine)
– July 2007 (Munich, organised and sponsored by Christoph Mathis)
– December 2007 (Walldorf, organised by Chrisitan Schnidkonz and Christoph Mathis, @ and sponsored by SAP)
– July 2008 (Munich, organised by Simon Roberts and Chistoph Mathis, @ and sponsored by Allianz)

Wie wäre es, wenn alle anderen User Groups sich auch registrieren? — Boris

Scrum — eine Revolution (5)

Fortsetzung von Scrum — eine Revolution (4)

Sind die ScrumMaster an allen scheiternden Implementierungen schuld?

Obwohl ich der Meinung bin, dass eine gute Scrum Implementierung mit guten ScrumMastern steht oder fällt, ist es natürlich falsch, den ScrumMastern die Schuld am versagen der Scrum Implementierungen zu zu schreiben.

In letzter Zeit fragen mich zum Beispiel mehr und mehr Teams und Manager, was denn das Entscheidende bei der Einführung von Scrum sei? Meine Antwort ist immer gewesen: “Am Ende einer Iteration funktionierende Software vorliegen zu haben!” Dieses Grundprinzip muss von allen verstanden werden. Dem Management, den ScrumMastern, und den Teammitgliedern. Ein Management, das von vornherein mitteilt, dass es natürlich nicht möglich sei, innerhalb von 4 Wochen etwas zu liefern, oder das einfach nicht gewillt ist, einmal 2 Wochen auf eine Lieferung zu warten, ist selbstverständlich ein Problem. Denn es steht dem Hauptgrundsatz von Scrum, alle 4 Wochen vollkommen funktionierende Software vorliegen zu haben, vollkommen entgegen. Hier muss ein ScrumMaster in der Regel am härtesten seine Ansichten vertreten. Wenn dieser aber selbst nicht daran glaubt, dass man User Stories funktional so klein schneiden kann, dass man sie in zwei oder vier Wochen liefern kann, dann werden die Teams auch nichts liefern.

Seid dem Scrum Gathering 2009, in Orlando, möchte ich die obige Forderung, dass man am Ende eines Sprints etwas zu liefern hat, gerne anders formulieren und durch zwei weitere Aspekte erweitern:

1)    Deliver every month
2)    Inspect and Adapt
3)    Ask the Team

So klar mir diese drei Aspekte selbst immer waren, es bedurfte einer kleinen Bühnenshow von Alistair Cockburn und Ken Schaber in Orlando, um mir diese drei Aspekte deutlicher ins Bewusstsein zu bringen: Alistair schlug bei der Erwähnung dieser drei Punkte immer verschieden tönende Gläser an, so dass beim Anschlagen der Gläser ein Dreiklang entstand. Eindrucksvoller konnten die beiden nicht verdeutlichen, worum es geht:

Deliver every month
Ken und Alistair machten wieder unmissverständlich klar, dass es bei Scrum um das Liefern von Funktionalität geht. Jeden Monat. Jeden Sprint. Jede Iteration. Wenn es dem Team nicht gelingt, etwas zu liefern, dann muss offen und transparent darüber diskutiert werden. Wir, das Team, oder die Organisation müssen etwas verändern, damit es gelingt, am Ende eines Monats etwas zu liefern. Zur Erreichung dieses Ziels ist dabei alles zu hinterfragen: hat das Team die notwendige Unterstützung, oder wie sieht die technische Ausstattung aus? Was immer geändert werden muss, das muss geändert werden.

Im schlimmsten anzunehmenden Fall, liefern Teams immer wieder nichts. Sie liefern nicht und die Organisation und die Teams werden ungeduldiger und demotiviert. Ausreden, warum diese Teams nichts liefern, gibt es dann sowohl auf der Seite des Teams, als auch auf der Seite des Managements. Alle fühlen sich schuldig, als wäre es ein Versagen und reden sich dann die Situation schön. Dabei ist dieses „Versagen“ keine Katastrophe, sondern eine transparent gemachte Erkenntnis: „Hier läuft etwas nicht so, wie es laufen sollte!“ In diesem Fall ist es tatsächlich angebracht offen darüber zu reden, ob wir das Team nicht verändern und die Teammitglieder auf andere Teams verteilen. Dieses Team ist ja offenbar nicht in der Lage etwas zu liefern. Oft ist es geradezu heilsam, die Teamstruktur dann drastisch zu verändern.

Inspect and Adpat
Läuft es nicht, dann muss etwas geschehen. Darum geht es bei Inspect and Adapt. Wo stehen wir? Was haben wir erreicht? Stehen wir da, wo wir hinwollen? Wollen wir noch dort hin, wohin wir letzen Sprint wollten? Wenn diese Fragen geklärt sind, dann können wir die notwendigen Maßnahmen treffen und die Dinge so verändern, dass wir das nächste Mal unsere Ziele erreichen. Inspect and Adapt heißt nicht, einen Schuldigen zu finden und dann dafür zu sorgen, dass dieser alles richtig macht.  Inspect and Adapt bedeutet, wir sind da, wo wir sind, als nächstes sehen wir zu, was wir tun können, um uns zu verbessern. Dieses Prinzip gilt für jede Wissenschaft, für jeden Prozess, der sich nur durch empirisches Probieren und durch anpassen an die Realtät verbessern lässt.
Ist erst einmal erkannt, dass wir etwas verändern müssen, dann können wir nach Möglichkeiten der Veränderung suchen.

Ask the Team
Aber wie gehen wir dabei am Besten vor? Fragen wir einen Manger oder einen Experten, wie es gehen kann und geben dann diese Dinge dem Team vor? Sagen wir also dem Team, was es zu tun hat? Sicher nicht.

Wir Fragen das Team, was es tun will, um die Veränderungen einzuleiten.  Wieder geben wir die Verantwortung an die Menschen, die die Arbeit tun müssen. An die also, die am besten wissen sollten, wie wir das gesteckte Ziel erreichen. Veränderungen sollten vom Team aus gestartet werden. Sie haben die Aufgabe, den besten Weg zur Zielerreichung zu finden.

Wichtig in diesem Zusammenhang: In Scrum behandeln wir die Menschen als „Erwachsene“. Wir schreiben Ihnen nicht vor, wie sie zu leben haben, wir schreiben ihnen auch nicht vor, wie lange sie zu arbeiten haben. Aber wir entlassen sie nicht aus ihrer Verantwortung, einen Weg zu finden, am Ende eines Sprints zu lieferen, was miteinander vereinbart worden ist. Etwas, was manche Teams erst lernen müssen. Zu schnell wird gesagt: „In Scrum darf man ja das Ziel nicht erreichen, es ging halt nicht!“ Nichts daran stimmt. In Scrum hat ein Team den selbst gesteckten Auftrag auch zu erreichen. Daher wird ein freiwilliges Commitment erarbeitet.

Komplexität und selbstorganisierende Teams

„Der Berater, den wir da hatten, war der Meinung, dass man in Scrum dem Team alles überlässt. Seine Meinung war, dass sich das Team schon selbst organisieren werde. Das war ein Fiasko, wir sind wieder zu einer traditionellen Teamstruktur mit Teamleitern zurück und seitdem funktioniert es einigermaßen.“ So ähnlich war die Geschichte, die mir ein Kunde erzählte. Das ist haarsträubend. Sollten Sie einmal einen Berater da haben, der ähnlich unverantwortlich mit ihren Mitarbeitern umgeht, setzen sie ihn bitte sofort vor die Tür.

Sich ein Team selbst organisieren zu lassen, hat nichts mit Zugucken oder gar Wegschauen zu tun. Gerade das Gegenteil ist der Fall: Selbst-Organisation funktioniert nur, wenn der Rahmen, der Container, in dem sich das Team befindet, klar definiert ist. Dieser Rahmen muss vom ScrumMaster gesteckt und aufrecht erhalten werden. Innerhalb dieses Rahmens, wird dann dafür gesorgt, dass die Selbst-Organisation in Gang kommt. Oft reicht es den Standard, den Scrum und die Tools, wie zum Beispiel das Taskboard, bieten „by the book“ einzuführen, damit die Teams beginnen können, sich selbst zu finden und zu organisieren. Aber – sollte das Entwicklungsteam auch nur den Anschein bieten, dass das Ziel gefährdet ist, dann wird sehr bestimmt und klar, aufgezeigt, dass da ein Ziel zu erreichen ist, und dass die Entwicklungsmannschaft gewisse Zusagen getroffen hatte. Oft reicht es in der Mitte des Sprints noch einmal die Ziele aufzuzeigen, oder ein Meeting einzuberufen, in dem noch einmal klar gestellt wird, um was es geht.

Viel öfter aber funktioniert die Selbst-Organisation deshalb nicht,  weil die Menschen in den Teams nicht mehr gewohnt sind, selbst Entscheidungen zu treffen. Dann, ganz plötzlich in Scrum, sollen sie das tun. Für viele eine Überforderung. Wieder kommt es auf den ScrumMaster an. Er wird in einem solchem Fall das Team enger führen, als es ein scrum-erfahrenes Team benötigt. Er wird dem Team Fragen stellen, es provozieren, Anregungen geben, Gespräche und Diskussionen moderieren und im Notfall auch für das Team Entscheidungen treffen. Eines darf nämlich nicht passieren:  Das Entwicklungsteam darf auf keinen Fall „versagen“, es darf nicht nicht-liefern. Wenn es dabei Hilfe benötigt, dann ist das eben so!

Der ScrumMaster wird über die Zeit hinweg immer und immer weniger eingreifen. Im Idealfall dauert es nur ein paar Sprints, bis er sein Team so weit hat, dass dort weitgehend selbst-organiserend gearbeitet werden kann.

Scrum Gathering Day2



Scrum Gathering Day2 049, originally uploaded by lucianofelixns.

Luciano took a great photo 🙂 It was so much fun to give this presentation about Retrospectives.