How internationally distributed Teams can improve their Sprint Planning 2

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 7)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum
Part 6: How internationally distributed Teams can improve their Sprint Planning 1
Stephanie G.: Having discussed Sprint Planning 1, let us continue with your tipps & tricks for Sprint Planning 2. How would you conduct this design meeting?
Ina K.: I would actually say that it‘s quite similar to Sprint Planning 1, apart from the Product Owner not being present. Sometimes the meeting is off to a slow start. If that‘s the case, the ScrumMaster should get involved and start filming people (see Christof’s answer in How internationally distributed Teams can improve their Sprint Planning 1) as well as make sure that the Team members who document the meeting rotate. Once the Team members properly get going, the ScrumMaster can retreat  and remain in a position of observation. Watch the Team – are they interacting enough? Do they seem to have a common understanding? Is everyone adding to the conversation? It‘s important to keep an eye out for such things, as the DevTeam members usually don‘t. Once they actually start looking out for it by themselves, the ScrumMaster has achieved wonders.
Hélène V.: The most important aspect of Sprint Planning 2 is that the common design solution that the Team has agreed upon is visualized and can be seen by all Team members. Only if this has happened, can the distributing of Tasks on a cross-location basis begin. Some Teams think that they do not need any visualisation … all I can say is that distributed Teams who believe this myth have a much higher chance of forgetting important aspects to their design.
Kristina K.: My Team had this issue. The fact that they typed up the Tasks into an electronic tool didn‘t help either, since it sometimes seemed that only the one who did the typing also did the thinking. The fact that the know-how was so unevenly distributed was an impediment in Sprint Planning 2, too. The lack of drawing meant that there was no real common Team understanding of the design – they didn‘t talk about how to implement the User Stories, but rather talked about what singular steps were necessary to implement them.
Bernd K.: We didn‘t really have what you can call a design session either. Sometimes the Team members used the flip charts for drawing, but then I had to take a picture (since the quality of our webcam was not good enough) and send it to the other Team members. This alone would take 5 minutes, by which time the moment for entering in the design discussion was over.
Generally, I did not enjoy Sprint Planning 2 – it often stretched out over three to four hours, which is two hours longer than a Sprint Planning for a two-week sprint should be. The problem was that our electronic tool did not have a word limit for Tasks, meaning that the Team often spent ages on writing them. This did not help to bridge the geographical gap either: the Team members in Romania were rather pragmatic, while the ones in Germany could be called the „philosophers“ – wishing to specify their Tasks and over-thinking the why what, when and where. While the Team dynamic of a co-located Team would have quickly eliminated this discrepancy with smiles or a nervous look, the Romanians were hidden behind a microphone and nobody knew what they were thinking.
Kristina K.: Oh dear, that sounds quite irritating. What I started implementing after a while was to ask the various locations to prepare several design options and to then challenge each other during Sprint Planning 2. In the end, we used the best idea out of all of them and wrote Tasks for it. This ensured that everyone on the Team had actually thought about the Stories, even if they‘re no expert.
Hélène V.: Yes, that‘s what I would recommend, too. After Sprint Planning 1, the Team should do a short mapping of the areas and topics that need discussing. You could then divide up the topics for each location i.e. location A takes the module on the database approach, location B focusses on another solution etc.
Christof B.: I agree with both of you, but I think that the decision of splitting up a Team for or in preparation of Sprint Planning 2 really depends on the Team constellation. If all roles are represented at all locations, I do think that the Sprint Planning 2 can be conducted as group work – meaning that each location grabs its own User Story, does its own mini-Sprint Planning 2 and then presents it to the rest of the Team after 30 minutes. After reviewing the outcome, the entire Team writes the Tasks together. However, this is only possible if both front-end and back-end are present at all locations. This option is not possible if i.e. testers and developers are in different locations.
Stephanie G.: It is so interesting that you all recommend splitting up the meeting, since I actually used to do the same. Only I did not split it in the way of one Story in each location, but rather one person from each location formed a Team, which would together work on one Story (see Pre-SP2 Design Sessions or How to use your Time during a Sprint Change?).
Christof B.: Sprint Planning 2 should not be underestimated. It is certainly not trivial, as it can be chaotic due to the necessary interaction between the Team members. After all, it is not only a meeting, but a creative process, design thinking, architectural brain-storming etc. A lot happens during SP2. I don‘t believe that its doable over the phone. It‘s even nearly impossible to do via video conference. I really think it‘s best if each location works on its own concept during Sprint Planning 2, which is only interrupted by SoS-like coordination meetings where the whole Team gets together again. For example, a design session for 30-45 minutes, followed by 10-15mins of presentation by each location including feedback.
Deborah W.: Funny. I never had any difficulties with Sprint Planning 2, meaning that I could always really enjoy this meeting. I thought it was one of the simpler ones when dealing with distributed Teams. Maybe it was an exception, but my Team members got really involved – even across locations. It was easier than SP1, since there was always less to show. Yes, we did draw a few diagrams and design the architecture, but not for too long. The topic was pretty clear to everyone, so the meeting was concise and short.
Stephanie G.: I love it when opinions diverge as much as yours right now. So before you all get jealous of Deborah‘s Team, let me quickly sum up the main points of advice:

 

ScrumMaster sind Meister der Effekte und Illusionen (Teil 2) – der Halo-Effekt

Im Psychologiestudium war die Wahrnehmungspsychologie eines meiner Lieblingsfächer. Ich kann mich noch gut daran erinnern, wie mein Professor zwei Fotos zweier Männer mittleren Alters nebeneinander hinlegte: Der eine im teuren Armani-Anzug, frisch rasiert, wie aus dem Ei gepellt. Der andere im Freizeitlook, Drei-Tage-Bart. Der Professor fragte uns: “Bei welchem der beiden Herren würden Sie eher eine Lebensversicherung  kaufen?” Interessanterweise entschieden sich fast alle Studenten für den Anzugträger und wurden damit Opfer des Halo-Effekts (vom Griechischen hàlos = Lichthof). Der Halo-Effekt (oder Hofeffekt) ist einer der am häufigsten auftretenden Beurteilungs- bzw. Wahrnehmungsfehler. Er besagt, dass die Dominanz einzelner Eigenschaften bzw. Attribute den Gesamteindruck einer Person bestimmt und auf diese Weise die Wahrnehmung weiterer Eigenschaften überstrahlt. So können Äußerlichkeiten wie das Aussehen, die Kleidung oder gar die Körpergröße den Ausschlag dafür geben, ob man z.B. kompetent oder freundlich wahrgenommen wird. Das Märchen “Des Kaisers neue Kleider” von Hans Christian Andersen ist ein schönes Beispiel für die kritische Auseinandersetzung mit den Auswirkungen des Halo-Effekts.
Ein ScrumMaster sollte daher stets auf der Hut sein. Er sollte zumindest um den Halo-Effekt wissen und nicht nur sich, sondern auch sein Team vor seinen Fallen schützen. Denn es ist gerade das System “Team”, das den Sirenen des Halo-Effekts auf besondere Weise verfällt: “teams tend not to be blamed for their failures“. Charles E. Naquin and Renee O. Tynan von der Universität von Notre Dame fanden in The Team Halo Effect: Why Teams Are Not Blamed for Their Failures”  Nachweise dafür, dass “the nature of the causal attribution processes used to diagnose failure scenarios leads to individuals being more likely to be identified as the cause of team failure than the team as a collective. Team schema development, as indexed by team experience, influences this effect, with individuals who have more team experience being less likely to show the team halo effect.”

Wenn das Team halo-ziniert

In zwei interessanten Studien belegen Naquin und Tynan ihre Hypothesen, die für jeden ScrumMaster Anlass sein sollten, sich und die Performance seines Teams kritisch zu hinterfragen. Ich gebe diese Empfehlung, weil Teams, genauso wie Individuen (vgl. Attributionstheorie von Weiner, die zu den kognitiven Emotionstheorien zählt), zwar die Ursachen ihrer Erfolge den eigenen Fähigkeiten zubilligen, Misserfolge werden jedoch meist (nicht immer, aber überwiegend) äußeren Einflüssen (und eben nicht mangelhafter Planung, unzureichender Kommunikation, schlechter interner Aufgabenverteilung oder fehlender Schwerpunktbildung) zugeschrieben. Der selbstkritische Blick wird durch die eigene Hybris verfälscht und durchgehend abgeschwächt. Selbst Retrospektiven, also die eigens für ein Team geschaffene Plattform, offen, direkt und schonungslos eine Inventur der eigenen Performance zu machen, um möglichst produktiver zu werden, geben im Schritt 4 “Was könnte verbessert werden” ausreichend Gelegenheit für Halo-zinationen: z.B. “Wir haben viel zu viele Meetings, um überhaupt was arbeiten zu können”, “Wir sind viel zu heterogen, um unsere Arbeit zu teilen oder an den gleichen Aufgaben gemeinsam zu performen”, “Wir können das SP1 und das SP2 ruhig mischen. Das geht doch dann alles viel schneller”, usw.
Das Phänomen des Halo-Effekts ist typisch, menschlich und nicht vollkommen auszuschalten. Aber es lässt sich eindämmen, indem der ScrumMaster es offen anspricht und den Mut hat, seinem Team den Spiegel vorzuhalten. Er ist der Prozesshüter. Er ist verantwortlich, dass die Produktivität steigt. Gelingen kann das, wenn das Team seine Leistung ohne Halo-zinationen beleuchtet und auf dieser Grundlage hinterfragt. Nur so kann die “Weisheit der Vielen” zur Entfaltung kommen und die wirklichen Stärken einer Gruppe zum Ausdruck bringen. Das Ganze ist immer mehr als die Summe seiner Teile und demnach sollte der Fokus des ScrumMasters immer auf beiden “Systemen” liegen bzw. sie gleich wichtig analysieren und verbessern wollen: das Individuum und das Team. Ich sehe viel zu selten, dass ein ScrumMaster das Team als Ganzes betrachtet und coacht (außerhalb der Retrospektive). Die Kunst dabei ist, das Team so zu sehen, als wäre es ein Individuum. Aber eben eines mit unterschiedlichen Charakteren – eine ganz besondere Herausforderung.


Literatur
Charles E. Naquin &Renee O. Tynan (2003). Team Halo Effect: Why Teams Are Not Blamed for Their Failures. Journal of Applied Psychology Copyright 2003 by the American Psychological Association, Inc.
2003, Vol. 88, No. 2, 332–340. University of Notre Dame
ScrumMaster sind Meister der Effekte und Illusionen (Teil 1) – der Othello Effekt

How internationally distributed Teams can improve their Sprint Planning 1

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 6)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum

Stephanie G.: Now that we have already spoken about the Daily, I would say we continue with the first meeting of a Sprint – the Sprint Planning 1. Anything you would recommend to watch out for in this meeting?
Kristina K.: I sometimes find that Teams do not really discuss Stories or ask questions about them prior to Sprint Planning 1. As a ScrumMaster, one should keep an eye out for this. Particularly with distributed Teams, one should try to arrange discussions that would normally emerge in an everyday Team setting i.e. during lunch time after an Estimation Meeting. I  could imagine that the distributed setting makes the use of the Sprint Planning Checklist even more important, as it provides the Team members with a clear structure and can inform them about the Story by way of going through a set of topics. As you can hear, I find the preparation for Sprint Planning 1 – meaning the discussing and clarifying of the upcoming User Stories – to be absolutely vital. Ideally, the Team members should enter the meeting already knowing the upcoming Stories really well, so that they have lots of ideas for i.e. Acceptance Criteria and a list of questions prepared. In the best case, the meeting is shorter than the planned time-box.
Ina K.: Yes, it‘s the Product Owner‘s responsibility to give the required information to the Team in advance and make sure that it has been registered by all of the Team members before going into the Sprint Planning 1. You‘ll laugh – but yes, this also includes the access to where the Product Backlog and any additional information can be found.
Hélène V.: I recommend that – at the very beginning of Sprint Planning 1 – the Product Owner should give an overview of his expectations of what he wants the Dev.Team to have achieved until the end of the Sprint.  It is important that everyone on the Scrum Team has one shared big picture of the product. After that, there‘s always the possibility of dividing up into smaller groups either cross-location or per location and only coming together in Scrum of Scrums.
Kristina K.: And don‘t forget to take more breaks than you normally would, since it‘s much more exhausting to do it over the phone. Also, make sure to involve everyone as much as possible, so that they don‘t fall asleep at the other locations.
Christof B.: Since the Sprint Plannings are the longest meetings in Scrum, it‘s important to be visually connected as well, as it‘s much more difficult to stay focused if you can‘t connect any faces to the voices. In the past, I‘ve actually attended the Sprint Planning of Ina‘s Team and it was always interesting to see how she would use a standard webcam and play film director with it. It‘s not very interesting to see static images – the mind stops noticing them after a while – but if you do it like Ina, who used to walk around the room, film people when yawning or chitchatting, it‘s much more entertaining and more real-life, I would say.
Stephanie G.: Ina, that sounds like you had quite a lot of fun during your meetings. But now I‘m wondering – what happens during the meeting itself?
Bernd K.: We actually came together for every second Sprint change, which was very helpful. For every other Sprint change, we generally used our tool iceScrum and while the PO would present his Stories one after another, each location would follow his talk on its respective screen. Whoever then had a question could use the computer mouse to circle the part in the User Story that needed more detailled explaining. However, we always had to ask explicitly whether the persons in Rumania had any questions, as they mostly had their microphones on mute due to the background noises in their office. Furthermore, the quality of the audio tool was not ideal, which meant that we had to repeat ourselves quite often. But the Sprint Planning 1 really made the progress of the Team quite obvious: in the beginning, the guidelines where more or less dictated, yet after a few months, the Team really began sitting down and typing up Requirements, User Acceptance Tests etc by themselves.
Deborah W.: We always used flip charts. I think that if you use actual paper, it might be easier for people‘s minds to start wandering off, while on the other hand, it‘s also much easier to get them involved again. We used flip charts on both sides and had static cameras streaming the image, and while the one location was writing, the other one saw the scene on their screen. We switched to the other location’s flip chart after every Story. The cameras were excellent, so we could decipher everything. Besides, we were also connected via teleconference. A piece of advice: if you don‘t have the chance to set up flip charts in all locations, then try to involve those watching with some small tasks – for example: get them to write down User Acceptance Tests in advance. Anything to get them mentally involved.
Christof B.: Yes, and don‘t forget to send the pictures of the flip charts to the other locations afterwards, so that they can print them off and hang them up on their own walls, too.
Stephanie G.: Alright – thanks a lot. Anything else to add that we haven‘t covered yet?
Ina K.: One last thing. What I always enjoyed doing as a ScrumMaster was to ask the Dev.Team a few – perhaps simple –  questions, particularly when a Team member looked slightly lost. This way, I make sure that nobody loses face by having to ask a question that should really be clear to all members of the Team. In the past, my questions have often triggered a discussion within the Team, showing that there had still been some slight confusion. Having asked my Team members for feedback, I‘ve also learned that a lot of questions aren‘t asked, as they think that it would be embarrassing and they‘d rather wait for Sprint Planning 2 in the hope that it comes up automatically. With this in mind, I would say that asking questions from an “outside perspective” almost belongs to the ScrumMaster‘s job description under the aspect of „Protect your Team“.
Stephanie G.: Thank you for all your input. Our readers will surely appreciate that a lot. Summing up the steps, you would recommend:

  1. Make sure  that the Team comes prepared and knows the Product Backlog.
  2. The PO should start the Sprint Planning 1 by presenting the big picture.
  3. If you can use flip charts, do so – but don’t forget to send the images to the other locations.
  4. Ask (some simple) questions to make sure that everyone has the same understanding.

Alright, now what about the next meeting – Sprint Planning 2?!

Die (Über-)Lieferung von Vertrauen

Nahezu jedes Unternehmen hat Erfahrungen mit der Beauftragung von Software-Entwicklungsprojekten und das sind zum Teil schlechte Erfahrungen. Durch solche schlechte Erfahrungen haben über die Zeit immer mehr Organisationen das Vertrauen in ihre Software-Entwicklung verloren. Ich möchte nicht behaupten, dass es nur furchtbare Software-Entwicklungsprojekte gibt. Aber ich behaupte, dass wir hier zu großen Teilen in einer Vertrauenskrise leben. Diese Vertrauenskrise hat nicht nur mit enttäuschten Erwartungen zu tun, sondern auch mit einer veränderten Welt, in der Vertrauen nicht mehr über langfristige Bindungen aufgebaut wird (Vertrautheit), sondern in der Schnelllebigkeit entstehen muss. Wir brauchen also einen anderen Weg, um Vertrauen über mangelnde Vertrautheit zu entwickeln. Kommen wir nochmal zurück zu den Software-Entwicklungsprojekten und verallgemeinern kurz: Umso weniger Vertrauen besteht, desto mehr Kontrolle möchte man ausüben. Vertrauen und Kontrolle versteht man weitläufig als entgegengesetzte Pole, die nicht gleichzeitig existieren können.

Wenn wir das Problem kennen, dann kennen wir doch auch die Lösung?

Vertrauen entsteht nicht über Worte, das wissen wir bestimmt, denn das ist neuronal in unserem Gehirn so verankert. Wir benötigen also Taten, die sich einer schnelllebigen Welt anpassen. Taten, die es ermöglichen, die Erwartungen eines Auftraggebers, eines Kunden und jene von Endnutzern mit dem Beauftragten abzugleichen. Wir als Software-Entwickler brauchen Lieferungen qualitativer, anwendbarer Software in kurzen Zyklen. Mit den Lieferungen zeigen wir, dass wir verstanden haben und liefern können was beauftragt wurde. Wir zeigen, dass wir den impliziten Anspruch auf Qualität halten können. Zudem rücken wir Kunden und Nutzer in den Mittelpunkt, beziehen ihn immer wieder in die Entwicklung ein und geben ihnen eine Stimme. Wichtig dabei ist, dass wir diesen Prozess wiederholen, ritualisieren, oft durchführen, damit wir als Software-Entwickler Verlässlichkeit zeigen können. Wir zeigen, dass es kein Glückstreffer war, sondern dass wir wiederholt qualitative Software  liefern können – wir zeigen professionelles Arbeiten. Im Scrum-Prozess stehen die Lieferung und das Präsentieren der fertigen Funktionen am Ende jedes Sprints, üblicherweise nach 14 Tagen. Am Ende jedes Sprints zeigt das Scrum-Team die lauffähigen Funktionen im Review den Kunden und Nutzern.
Da wir gerade beim Kunden sind, bleiben wir kurz bei ihm. Es wäre fahrlässig, würde der Kunde die Kontrolle aufgeben. Die beauftragte Software ist relevant für die Ergebnisse des eigenen Unternehmens und soll dazu beitragen, die Zukunft des Unternehmens zu sichern. Als Kunden brauchen wir also einen Kontrollmechanismus. Diesen Kontrollmechanismus sollte man nicht an Worten, konkret Verträgen, festmachen, sondern man sollte auch hier wieder auf Taten setzen. Ein wichtiges, wenn nicht gar das Kontrollelement des Kunden sind die Reviews, die er einfordern und aktiv daran teilnehmen sollte. Das Review ist die Fortschrittskontrolle und die Kontrolle des inhaltlich Gelieferten. Zudem ist es die Kontrolle über die Schnelllebigkeit der Märkte, denn wenn Sie als Kunde agil entwickeln lassen, bekommen Sie Kontrolle über Time-to-Market und haben Einfluss auf Änderungen – idealerweise sogar “Change for free“, solange sie auch den Umfang Ihres Produkts/Projekts anpassen. Dafür sollten Sie auch einen Vertrag aufsetzen, der das Ganze widerspiegelt. Auch das ist heutzutage möglich und sogar Wunsch bei vielen Software-Entwicklungen.

Fazit

Liefern wir als Software-Entwickler regelmäßig in kleinen Abständen mit hoher Qualität, so haben wir die Chance, zerstörtes Vertrauen aufzubauen oder dem gewährten Vertrauensvorschuss gerecht zu werden. Nutzen wir Rückkopplungspunkte wie Reviews dazu den Kunden einzubinden, lösen wir sogar das Paradoxon von Vertrauen und Kontrolle zu unserem Vorteil auf. Letztlich gewinnen beide, der Kunde und die Software-Entwicklung. Die Software-Entwicklung vielleicht sogar ein wenig mehr, denn sie hat etwas zurückzugewinnen und das gilt für die gesamte Branche.

How internationally distributed Teams can improve their Daily Scrum

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 5)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?

Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Stephanie G.: Now that we have discussed internationally distributed Teams in broader terms, I would like to get to the more practical part of this interview. Let‘s start with the most frequent meeting: the Daily Scrum. Would you say that it‘s more difficult to stay within the time-box of 15 minutes in comparison to co-located Teams? Is there something that you would really advise watching out for during the Daily?
Ina K.: No, I wouldn‘t say that it‘s any different in terms of keeping the time-box. It‘s all about keeping an ear open for discussions that don‘t belong in the Daily. Sometimes it‘s just a matter of using the microphone and asking the Team, “Is the current discussion of interest to everyone? Could we perhaps talk about this afterwards?“ The ScrumMaster should always ponder over how the Daily Scrum could be made even more efficient, since a lack of concentration and focus by the Team members leads to a downward spiral of effectiveness. I always found it important to act as a kind of motivator, meaning that I would try to make the Daily Scrum at least a little bit entertaining. As a ScrumMaster, it is important to get a feeling for the Team – what jokes do they enjoy, what are their character traits, do they prefer technical discussions, do they ever speak of their private lives etc.?! Once you understand your Team, it is much easier to integrate the Team members from the other locations into the Daily. I have seen far too many ScrumMasters (no matter whether co-located or distributed, actually) that sluggishly stand in the background waiting for the meeting to be over – if you don‘t show any enthusiasm for what you propagate, why should your Team members?!
Kristina K.: Actually, in contrast to Ina, we didn’t stick to the 15 minutes, as the Team seemed to need a bit of extra time in order to make the meeting most effective. At the time, I found this to be more important than sticking to a time-box of exactly 15 minutes. It is no surprise, as my Team consisted of about 11 Dev. Team members and several locations. The English language levels varied strongly, the technology was a definite impediment and – as I have already mentioned during the previous question (Interview 4 link) – the tool did not facilitate the flow of the meeting. Still, I always continued analyzing the meeting in terms of its time-box, as this helped me to develop new ideas that could help my Team plan their day better as well as maybe hold an effective meeting in less  time.
Christof B.: That‘s true, Kristina, your situation is not so unusual. Distributed Teams are often larger than co-located ones. If that‘s the case, one simply has to accept the fact that it may take slightly longer than the standard 15 minutes. Also, communicating over the telephone with each other makes the meeting more exhausting (which is why Ina‘s tips are great, by the way) and if the technology was not specifically selected for the Team‘s needs, the likelihood of having to repeat yourself a lot is rather high. Staying within the 15 minutes time-box can really be quite difficult.
Stephanie G.: I‘ve also experienced that the technology has a large impact on the efficiency of the Daily. What do the others think?
Deborah W.: As a ScrumMaster, it‘s important to make sure that all the technology is set up properly well in advance. Ten minutes should suffice if it ensures that the equipment is ready to be used right from the start. As Christof mentioned – depending on the transmission (sadly, most Teams do not have the budget that we had spoken of earlier – see Interview 3), you might have to set the time-box at 20 minutes. When my Team started out, we only used to be able to hear each other, but after less than a week, the Dev. Team independently bought a webcam, so that they could combine the voices with images.
Bernd K.: Oh dear – speaking of transmission. I can‘t even count how many times our connection broke off during any kind of meeting. Also, we didn‘t have a webcam, so it was very important to ensure that everyone knew whose turn it was and who was currently speaking. Whether this is done by saying one‘s name before speaking, through colour codes in the Taskboard tool or some other way, is up to the Team.
Christof B.: I always liked the idea of having a Speaker Token, which can be passed around depending on who wants to go next. You can also play Ping Pong with the Team members in the other locations – Team member in location A followed by Team member in location B, then someone in location A again etc – but this makes it even more difficult to stay within the 15 minutes and the ScrumMaster really has to keep an eye out on who‘s up next. The advantage is that people stay more focused.
Bernd K.: Oh, that sounds quite good, Christof. I‘ll try that out next time. But generally, the Daily was interesting, as it showed a large cultural difference between the Team members in Romania, who were rather held back, and those in German, who would talk quite a lot. As a ScrumMaster, I had to ensure that everyone got his or her turn to voice the current progress of the Tasks.
Stephanie G.: I can imagine that if – as you say – the Team members in Germany were quite talkative, that must have made it difficult to stay within the time-box, as well?! I know my Team always wanted to use this meeting to discuss everything right away and get all questions answered – although these questions had mostly little to do with planning the work for the day.
Bernd K.: That‘s exactly one of the issues that we had. The Team was simply trying to use the opportunity that the connection between the two locations was already established. So I tried to separate the „Now“ and „Later“ a bit more strictly and pushed them towards using group chat rooms more frequently or setting up a telephone connection in the middle of the day in order to coordinate their work. I also encouraged the Team members individually to start picking up the phone and directly calling each other outside of the Daily, too.
Hélène V.: Bernd, I am completely with you. I would really advise to start using the Daily for shortly coordinating everyone‘s availability for the upcoming 24 hours. When sitting together in one room, it‘s easy to figure out the best available time for meeting up and discussing something. This isn‘t the same for distributed Teams. Another option would be to simply say that the Daily is automatically followed by another synchronisation meeting a few hours later. That way, coordination takes place more often and it becomes more natural for the Team members to talk to each other several times throughout the day. But I can say this about the Daily: It really is a challenge to ensure that everyone knows exactly what each Team member is currently working on. This is not just difficult for distributed Teams. But it is important to use the Daily for making this transparent! No matter which tool the Team uses, it should be elusive on what progress has already been made and what is still missing.
Stephanie G.: Thank you! You‘ve given our audience quite a few useful tips. Let‘s see whether I can summarise them as:

First things first

Ich gebe zu, man könnte es als luxuriös bezeichnen, eine komplette Woche mit einem neuen Team zu verbringen, bevor der tatsächliche Sprint startet. Mittlerweile betrachte ich es aber als notwendig, vor allem wenn das Team vorher nicht zusammen und nicht mit Scrum gearbeitet hat. Vor allem aber, wenn die Teammitglieder nicht daran gewöhnt sind, zu diskutieren und sich einzubringen.
 

Was man eine ganze Woche lang macht?

1) Scrum Basics vermitteln
Jeder hat über den Flurfunk oder die Unternehmenskommunikation im Rahmen der Einführung von Scrum bestimmte Buzzwords mitbekommen. Manche haben sich selbst eine Vorstellung gemacht, andere nachgelesen und wieder andere können mit den Begriffen nichts anfangen. Also, in Kürze – einen Tag – Rollen, Meetings, Artefakte. So legt man zumindest gleich zu Beginn die Grundlage für ein gemeinsames Verständnis – und eine gemeinsame Sprache verbindet zusätzlich.
 
2) Das Team kennenlernen
Ob ScrumMaster, Product Owner oder Teammitglied: Jeder ist neu im Team. Daher sollte man sich die Zeit nehmen, sich über die gewöhnliche Vorstellungsrunde mit Namen und Abteilungskürzel kennenzulernen. Ich bereite zwar eine Art Story Map vor, lasse dann aber die Teammitglieder durch Punkte entscheiden, was sie machen wollen, um sich, Scrum, die Hintergründe und den organisatorischen Rahmen kennenzulernen.
 
3) Vision und Backlog
Sich (als ScrumMaster) Zeit nehmen, den Product Owner gründlich auszufragen: Was ist das Produkt? Wer die Nutzer? Und welchen Nutzen wollen wir für sie bereitstellen? Kann man eine Vision erarbeiten oder fehlt es dafür an etwas?
 
Oft wundert man sich, dass es ein Team gibt und man vermeintlich starten kann, aber noch gar nicht richtig klar ist, was gemacht werden soll. Wenn man Glück hat, ist es für eine “strategische Runde” noch nicht zu spät, bevor die Verwirrung das ganze Team erfasst. Im besten Fall kann der PO nochmal drüber schlafen und nochmal weiterentwickeln, schärfen oder verwerfen, bevor er das Ergebnis zum ersten Mal mit dem Team diskutiert.
 
Vor allem einen nicht fertige Vision, ein mageres Backlog und die gemeinsame Erarbeitung der Personas mit dem Team laden zum Teilen der Meinungen ein. Durchstreichen erwünscht – und das ist “analog” einfacher als in einer ppt. Gemeinsam geschriebene User Stories, selbst wenn man nachher nicht alle braucht, machen deutlich, wie schwierig oft der Nutzenaspekt ist. Vor allem wenn man den Kunden bereits kennt und in der Regel einfach abarbeitet.
 
Gebt den Teammitgliedern etwas Zeit, wenn sie nicht gleich zu Beginn eifrig diskutieren. Oft sind sie es nicht gewöhnt, gefragt und gehört zu werden.
 
4) Infrastruktur und Wissen
Einen Raum beziehen, Rechner neu aufstellen, ein Taskboard bauen, weitere benötigte Infrastruktur- und Testumgebungen identifizieren, ggf. eine Schulung zu für das Team wichtigen Inhalten organisieren.
 
5) Definition of Done
Was ist selbstverständlich? Was wäre gut, wenn man es tun würde? Und was würden wir gerne tun, haben aber nicht die Mittel? Arbeitsweisen und Begriffsverwendungen variieren oft schon, wenn man die Seite des Flurs wechselt, ganz zu schweigen von Abteilungen. Das Sammeln der Antworten auf die Fragen oben ist für mich eine Herangehensweise, dem Team die Möglichkeiten und weniger die Doku-Regeln hinter der DoD zu vermitteln. Außerdem füllt sich das Impediment Backlog fast wie von selbst und das Team gibt bereits vor dem ersten Planning ein Commitment ab – und sei es nur um zu versuchen, die selbst gesteckten hohe Qualitätsziele zu erreichen.
 
First Things First – sich Zeit für die strategische Planung nehmen, bevor man in der Taktik der neuen Situation versinkt. Es lohnt sich und ist genauso ein Bestandteil von Scrum wie die Sprints.

ScrumMaster schenken kleine Freuden mit Scrum

Es sind die kleinen Freuden des Lebens, die unser Tun manchmal besonders machen. Sie passieren spontan, überraschend oder auch unvorbereitet. Genau darin steckt ihre tiefgreifende Kraft. Man rechnet nicht mit ihnen. Und plötzlich sind sie da. Sie lösen einen vollwertigen Cocktail an Gefühlen in uns aus. Ein wahres Fest für jeden Neurobiologen. Ein kleines Feuerwerk aus Endorphinen.
Vielleicht fragt ihr euch, wie ich auf dieses Thema gekommen bin. Dieser Beitrag ist entstanden, weil mir vor ein paar Tagen eine solche kleine Freude am eigenen Leib zuteil wurde. Nach zweiwöchiger Abwesenheit kam ich an den Arbeitsplatz, der mir bei einem meiner Kunden zur Verfügung gestellt wird. Auf meinem Schreibtisch fand ich diese Nachricht vor:

 
Das Ergebnis war echt erlebte Freude. Kann ein Arbeitstag wertschätzender starten? Ich bin für diesen einen Moment, meinen Moment, nicht mehr aus dem Strahlen gekommen:

Take a smile

Eine schöne und bemerkenswerte Variante zu dem Willkommen-Post-it, die ich immer wieder gerne nutze, um für eine kleine Freude, ein Schmunzeln, zu sorgen, ist das Take a smile-Post it.

Mögliche „Einsatzgebiete“? Es kann den bzw. die Empfänger beispielsweise über einen ganzen Sprint begleiten (jeden Tag ein Lächeln). Es kann aber auch für ein Lächeln pro Teammitglied stehen. Take a smile ist genauso einsetzbar für ein einzelnes Teammitglied, dem es vielleicht gerade nicht so gut geht. Vielleicht verteilt ihr es an eure Besucher im Daily oder im Review. Wenn ihr aber die Wirkung erstmal einfach so ausprobieren wollt, dann hängt ein Post-it an die Eingangstür, die zum Teamraum führt. Ich garantiere euch, dass ihr Abnehmer finden werdet und denen ihr unter Garantie mindestens ein Schmunzeln entlocken werdet.

Der Briefwechsel

Wer als ScrumMaster einen erinnerungswürdigen Moment von Freude, gemischt mit einem gerührten Innehalten erzeugen möchte, sollte sein Team zu einem „Briefwechsel“ bewegen. Der Zeitaufwand ist im Verhältnis zur Wirkung verschwindend gering und ein Zusammenrücken im Team ist nahezu garantiert. Der Briefwechsel kann als Separator in einer Retrospektive zum Einsatz kommen, aber auch als möglicher Wochenabschluss in ein erholsames Wochenende einleiten. Was habt ihr zu tun? Sorgt für eine lockere, aber störungsfreie Atmosphäre im Teamraum (z.B. lockerer Stuhlkreis, wenn das räumlich möglich ist; jedes Teammitglied kann aber auch an seinem Arbeitsplatz sitzen, sofern das Team in einem Raum ist und nicht verteilt). Jeder bekommt einen Stift. einen Briefbogen und einen Briefumschlag. Ich empfehle euch, echtes Briefpapier zu nehmen. Das sieht einfach schöner aus und macht den Briefwechsel authentischer. Eure Teammitglieder sollen ihren Namen gut lesbar in eine Ecke des vor ihnen liegenden Briefpapiers schreiben. Bei der Überschrift für den Briefwechsel seid ihr nun frei. Wählt ein Motto in Form eines Satzanfanges, der dann jeweils vervollständigt werden soll: z.B. Es ist schön, mit dir in einem Team arbeiten zu dürfen, weil … oder Ich möchte dir heute ein Kompliment machen, weil… Hat jedes Teammitglied seinen Namen und die Überschrift auf seinen Brief geschrieben, wird der Briefbogen im Uhrzeigersinn an den Nächsten weitergegeben. Dieser widmet nun dem Briefbesitzer (Name steht auf dem Briefbogen) seine persönlichen Worte durch die Vervollständigung des Satzanfangs (siehe oben). Und weiter geht es. Der Brief wird an das nächste Teammitglied übergeben. Dieser Ablauf findet solange seine Fortsetzung, bis der Briefbesitzer beim nächsten Briefwechsel überreicht werden würde. Ist der Satz formuliert, wird der Brief gefaltet und kommt in den Briefumschlag. Schreibt den Namen des Empfängers nun auf den Umschlag und übergebt den Brief an seinen Empfänger.
Der Briefwechsel – auf einen Blick
Zutaten: 1 Briefbogen, 1 Briefumschlag, 1 Stift (alles je Teammitglied)
Zeitlicher Aufwand: Teammitglieder mal zwei in Minuten
Sinn und Zweck: Wir schenken uns Freude
Räumliche Bedingungen: störungsfreie Teamatmosphäre
Anlass: Separator in einer Retrospektive, Wochenabschluss, für gute Laune zwischendurch
ScrumMaster, nehmt meinen Blog zum Anlass, verteilt kleine Freuden mit Scrum und schaut, was ihr bei den Menschen auslöst und bewegt. Denkt daran, dass die Wahrheit uns allen ins Gesicht geschrieben steht. Wer sich übrigens wirklich sicher sein möchte, ob er bei seinem Gegenüber „echt erlebte Freude“ (1) produziert hat, möge sich nicht allein auf hochgezogene Mundwinkel konzentrieren. Die Basisemotion der Freude, wenn sie echt erlebt und nicht nur sozial erwünscht geäußert wird, tritt zweifelsfrei nur in Kombination mit der Muskelkontraktion des Wangenhebers (musculus orbicularis occuli) auf. Wangenheber? Nein, ihr habt euch nicht verlesen und nein, ich meinte nicht Wagenheber. Den braucht es hoffentlich nicht für diesen Muskeleinsatz. Die Kontraktion des Wangenhebers kann leicht ausfindig gemacht werden. An den Außenseiten der Augen werden die sogenannten „Krähenfüßchen“ sichtbar, die natürlich auf meinem Freude-Foto kaum zu erkennen sind :-).
Und jetzt los. Verschenkt Freude. Ich bin mir sicher, dass ihr dankbare Abnehmer finden werdet.
 
Literatur
(1) P. Ekman (2012). Emotionen lesen.

Der Sprint – ein Zeitplan für Macher

Wer beim Sprinten ins Stolpern kommt, wird meist von etwas abgelenkt. Das gilt zumindest in den Sprints, die im Büro stattfinden. Den Sprint in Scrum gibt es aus vielen Gründen: Er dient der Synchronisation, stellt eine Grenze gegen Überlast dar (WIP-Limit) und sorgt für störungsfreies Arbeiten.

Synchronisation

Der Sprint dient der Synchronisation für die Priorisierung und Lieferung. Hierbei besteht die gleiche Kadenz für Priorisierung und Lieferung. Die gleiche Kadenz heißt, es wird zu Anfang des Sprints festgelegt, was in die freien Slots kommt, die im nächsten Sprint frei sind und es wird festgelegt, wann das Scrum-Team die nächsten Ergebnisse liefert. Sobald man in Scrum das Sprinten startet, legt man den Rahmen, die Kadenz automatisch fest. Man legt Synchronisationspunkte fest und die damit verbundenen Transaktionskosten.
Die Transaktionskosten der Koordination minimiert man bei einer regelmäßigen Priorisierung. Es ist klar, wann wer zusammenkommen muss und jeder kennt den Rhythmus.
Transaktionskosten für die Lieferung hängen von mehreren Faktoren ab: Wie aufwendig sind Koordination und Integration, wie hoch ist der Grad der Automatisierung und wie schnell kann, wie schnell muss man Geschäftswert für den Endnutzer bereitstellen.
Die Automatisierung hat heutzutage noch viel mit Professionalisierung der Software-Entwicklung zu tun. Unternehmen, bei denen bisher wenig automatisiert ist, haben meist hohe Transaktionskosten. Solche Kosten sind oftmals auf manuelle Qualitätssicherung und hohe Koordinationskosten für Integration und Releases zurückzuführen. Meist führen gerade solche langen Lieferzeiten jedoch zu einem Teufelskreis: Da die Transaktionskosten hoch sind, meiden Unternehmen kurze Zyklen. Lange Zyklen beinhalten immer ein höheres Risiko an Fehlern. Kombiniert man nun lange Zyklen mit der Angst vor Fehlern in der Praxis, stellen sich nochmals höhere Transaktionskosten durch ausgeprägte Testphasen ein. Da man zum einen mehr testet, zum anderen fehlerhafte Funktionen länger in der Praxis hat, verlängert sich der Zeitraum des fehlenden Geschäftswerts. Derweil sitzt der Kunde noch mit Praxisfehlern auf der langen Bank. Wartet der Kunde auf der Bank, dann führt das häufig zu Mitnahmeeffekten durch Wettbewerber.

WIP-Limit

“Limit work in progress” – so richtig wichtig, leider oft so richtig wenig verstanden. Überlast in Unternehmen führt nicht nur dazu, dass alles lange dauert und keiner mehr Lust hat. Es führt vor allem dazu, dass fast nichts mehr geht. Menschen betankt man nicht wie Maschinen, die dann bis auf eine gewisse Grundwartung mit einer geringen Fehlerquote arbeiten. Wann geht fast nichts mehr? Wenn alles aufeinander wartet und gemeinsame Synchronisationspunkte zu selten oder unkoordiniert stattfinden. Dann ergeben sich Abhängigkeiten, die nur noch so ungefähr aus der Vogelperspektive erfasst werden können. Wenn die Vogelperspektive hier helfen würde, dann wäre das schön, meiner Erfahrung nach zählen allerdings vor allem die Details.
Im Sprint limitiert das Entwicklungsteam die eigene Auslastung. Das Entwicklungsteam zieht sich die eigene Auslastung, manchmal auch die eigene Überlastung. Dadurch entsteht für den Zeitraum des Sprints ein limitiertes System, ähnlich einem Währungssystem, es entsteht eine Knappheit. Mit dieser Knappheit kann man arbeiten. Indem ich ausweise, dass im nächsten Zeitraum nicht mehr geht, zeige ich deutlich auf, was geliefert wird. Meine Lieferung rückt in den Fokus.
Des Weiteren kann bei Blockaden nicht auf etwas weniger Wichtiges ausgewichen werden, sondern es muss genau an dem gearbeitet werden, was wichtig ist. Trifft man auf Blockaden, so sind sie zu lösen. Ist das System nicht limitiert, so wäre die natürliche Reaktion, sich mit etwas anderem zu beschäftigten. Das führt in vielen Organisationen dazu, dass Blockaden selten oder nie gelöst werden und man sich mit ihnen abfindet. In einem knappen System geht das nicht. Es muss etwas getan werden, der Fokus auf den Wert bleibt erhalten und man reduziert deutlich die Parallelität und damit den Auslöser für das heutzutage vielmals gescheiterte Multiprojektmanagement.
Wichtig ist, die so erzeugte Knappheit im System aufrechtzuerhalten: Wird das System ständig gestört z. B. durch Incidents, dann werden schnell die Vorteile eines solchen Systems obsolet (stabile Transaktionskosten für Priorisierung, Lieferung, konsequentes Auflösen von Hindernissen, etc.).

Störungsfreies Arbeiten

Wer kennt es nicht: Manager hetzen stundenweise von Termin zu Termin. Stimmen sich ab, tauschen sich aus und tragen all die neuen Erkenntnisse überall dorthin, wo sie aktuell noch gar nicht sein müssten – ins Entwicklungsteam. Auf der anderen Seite sitzen im Entwicklungsteam Menschen, die Zeit benötigen, sich in ihre Arbeit zu vertiefen.
Ich beschreibe Software-Entwicklung meist so: Du sitzt da vor deinem PC und über dir schwebt ein stetig wachsendes Konstrukt von Beziehungen, Abläufen und Strukturen. Es ist wie ein kleines Wolkenschloss, dass mit jeder Zeile Code, die du liest, wächst. Immer mehr Gedankenblasen steigen vor dir auf bis dann… ja dann klingelt das Telefon, es kommt jemand herein, spricht dich an und du siehst weit am Horizont die letzte Gedankenblase zerplatzen und dein Wolkenschloss ist vom Winde verweht. Um ein solches Konstrukt zu erzeugen benötigt es Zeit, es ist aufwendig und anstrengend.
Wenn wir die Zeitpläne eines Managers mit dem eines Entwicklungsteams vergleichen, dann sehen wir kleine Zeiteinheiten über den Tag verteilt beim Manager und große Zeiteinheiten beim Entwickler. Jetzt würde manch einer sagen, dass es jede Menge Entwickler gibt, die auch einen zerstückelten Zeitplan mit sich herumtragen. Hier stelle ich die Frage: “Wie viel wird von demjenigen dann noch entwickelt und wie viel managt er schon?”
Paul Graham nannte 2009 die unterschiedlichen Zeitpläne “Maker’s schedule, manager’s schedule“. Er bringt dort zum Ausdruck, dass diese beiden Zeitpläne konträr zueinander stehen und so wenig wie möglich aufeinandertreffen sollten, damit die Produktivität der Macher (Entwickler) möglichst wenig beeinträchtigt wird. Im Umkehrschluss schlägt er vor, dass beide Zeitpläne voneinander entkoppelt werden sollten. Spannenderweise findet dieses Prinzip sich im Agilen im Allgemeinen und bei Scrum im Speziellen wieder. In Scrum entkoppeln die Sprints die beiden unterschiedlichen Zeitpläne voneinander. Im Sprint sorgt der ScrumMaster für störungsfreies Arbeiten und gibt seinem Entwicklungsteam den Freiraum und die Zeit, möglichst autonom und produktiv zu arbeiten. Zum anderen entkoppeln die Rollen Product Owner und ScrumMaster die Zeitpläne. Das geschieht dadurch, dass beide für das Scrum-Team zwischen den Zeitplänen vermitteln, indem sie selbst als Puffer und Filter agieren. Ein weiterer Vorteil ist, dass sich das Entwicklungsteam gegenüber Störungen ausgehend von den beiden Rollen auch durchsetzen kann, da weder ScrumMaster noch Product Owner disziplinarische Vorgesetzte des Teams sind.

Zieleinlauf

Der Sprint isoliert die hektische Welt des Managements vom Zeitplan eines Entwicklers. Entwickler können sich so fokussieren und gedankenintensive Arbeit leichter abschließen. Der Sprint fördert stabile Bedingungen, die zu niedrigeren und stabilen Transaktionskosten führen und ermöglicht Professionalisierung aufgrund von kleinen Lieferungen. Als knappes System führt der Sprint dazu, dass Blockaden gelöst werden müssen und zukünftig nicht auch anderen Arbeiten im Weg stehen. “Wenn Sie mich fragen: Ich mag ihn, den Sprint!”

Interview mit einem ScrumMaster oder die Reise zu einem fremden Planeten

Ein guter ScrumMaster zeichnet sich dadurch aus, dass er immer und überall auf der Suche nach Verbesserungen ist, die zur Steigerung der Produktivität seines Teams beitragen. Hierzu sollte er seinen Blick in alle Richtungen schweifen lassen. In der operativen Hektik des täglichen Tuns passiert es dann nicht selten, dass ein Bereich übersehen oder gar vergessen wird: der Blick auf sich selbst. Wer andere bewegen und verändern will, der sollte zuerst sich selbst bewegen, um so zu (s)einer Veränderung beitragen zu können.
Katja Lüdtke, seit einem Jahr ScrumMaster beim E-Postbrief, versteht diesen Anspruch auf ihre ganz eigene Art und Weise und sagt: „Yin und Yang. Weich und hart. Stark und schwach. Nichts ist absolut. Die Eigenschaften definieren sich immer im Vergleich. Also, es ist wichtig, nach draußen zu gehen und sich auch andere Welten anzuschauen, um relativieren zu können, um neue Erkenntnisse zu gewinnen und daraus zu lernen.“  Und Katja nahm sich selbst beim Wort und ging nach „draußen“, zur ESG nach Wolfsburg. Im Rahmen einer Weiterbildung von bor!sgloger consulting, die von ihrem Chef, Dr. Oliver Zeiler (Mitglied des Bereichsvorstands BRIEF GB 32), möglich gemacht wurde, implementierte sie dort in einem gerade neu aufgestellten Team Scrum. Drei Sprints (sechs Wochen) lang durfte sie dort als ScrumMaster und ScrumCoach ihren Blick über den Tellerrand nicht nur schweifen lassen, sondern auf besondere Weise schärfen.
Über ihre Erlebnisse, die vielen Erkenntnisse und kleinen Geschichten möchte ich heute mit Katja reden.
D.: Hallo Katja, du bist zurück von deiner kleinen Reise. Wie ist es dir ergangen?
K.: Es war besonders. Es stimmt, was Mike Cohn sagt: Scrum ist anders. Ich würde dies aber gerne ergänzen wollen: Scrum ist woanders anders.
D.: Wie meinst du das?
K: Es war wie Sprinten auf einem anderen Planeten. Ich durfte Scrum und mich als ScrumMaster und Coach in einer völlig neuen Umgebung, auf einem fremden Planeten erleben. Von drei meiner wichtigsten Beobachtungen und Erkenntnisse möchte ich gern berichten.
D.: Dann leg mal los. Du machst mich neugierig.

Beobachtung 1: Kleine Teams sind tatsächlich dynamischer als größere

Die „Fremdlinge“ haben sich für die agile Entwicklung eines neuen Produkts in kleinen Teams von vier bis fünf Personen organisiert. Das war neu für mich, da ich als ScrumMaster bislang nur die Arbeit mit Teams von acht bis zehn Personen kannte und diese Größe für mich selbstverständlich war. Nun beobachtete ich gespannt die Auswirkungen einer noch kleineren Organisationseinheit und stellte fest, dass die Teammitglieder häufiger zu Wort kommen als in einer größeren und das persönliche Kennenlernen begünstigt ist. Klingt erst mal logisch, hat aber in letzter Konsequenz große Auswirkungen. Die Phasen der Teamentwicklung sind im Vergleich mit einem Team, das aus mehr als acht Personen besteht, kürzer. Im Team werden die Ideen schneller besprochen, die Aufgaben rotieren zügiger, bei Problemen finden sich fast automatisch Partner, um diese  lösen zu können. Als Teammitglied ist man stärker gefordert und kann sich weder verstecken, noch geht man in der Anonymität unter, weil man vielleicht zu leise ist. Es ist in jedem Moment offensichtlich, wie die zugesicherte Eigenverantwortung gelebt wird – nicht zuletzt, weil man irgendwie muss, aber dadurch auch will. Das bedeutet, dass die persönliche Motivation, das Ziel zu erreichen, höher ist, da gute Ergebnisse viel schneller sichtbar sind und zur Anerkennung führen.
Weitere Vorteile eines kleineren Teams ergeben sich aus der Arbeit des ScrumMasters: Die Timeboxes für Meetings sind, ohne das Team zu überfordern, leichter einhaltbar – weniger Köpfe, weniger Kontroversen. Für die Verbesserung der Persönlichkeits- und Team-Entwicklung bleibt somit auch mehr Raum, was sich natürlich direkt in der Arbeitseffektivität widerspiegelt – die Velocity steigt, die Qualität bleibt hoch. Folge: Der ScrumMaster kann sich mehr und nachhaltiger um die Lösung von Impediments kümmern.

Beobachtung 2: Ein ScrumMaster schützt das Team, aber er hat keine Schützlinge

Kennt ihr das Bild der Glucke mit ihren kleinen Küken, die ihr nahezu blind folgen, wenn sie gemeinsam zum Spazieren gehen? Die Glucke unternimmt alles, damit ihre Zöglinge vor allem und jedem geschützt werden. Manchmal verhalten sich ScrumMaster genau so, wenn sie seit vielen Sprints mit dem gleichen Entwicklungsteam zusammen sind. Natürlich ist es absolut menschlich, dass sich mit der Zeit Freundschaften zwischen dem ScrumMaster und den Teammitgliedern bilden, Menschen wachsen sich ans Herz oder gewöhnen sich einfach aneinander. Und dann? Neigen wir dann nicht dazu, Schwächen nicht mehr so konsequent und bedingungslos anzusprechen, das Gegenüber zu schonen und Missstände sogar zu ignorieren? Interessant: Auf dem fremden „Planeten“ zeigten die „Außerirdischen“ sehr ähnliche Symptome. Sie haben allerdings ziemlich schnell eine Lösung gefunden: eine ScrumMaster-Rotation!
Es wurde erkannt und angewendet, dass jeder ScrumMaster seinen eigenen Stil und seine Stärken hat, die auf unterschiedliche Weise eine Performance-Steigerung im Team bewirken können. Erst gute und gemeinsame Emotionen lassen ein Gefühl für Gemeinschaft und Vertraulichkeit entstehen. Das ist anzustreben, um konzentriert arbeiten zu können. Aber ein regelmäßiger Teamwechsel ist eine Chance für den ScrumMaster und für das Entwicklungsteam: Der eine vermeidet die Fallen der Routine und das Team profitiert von den Fähigkeiten anderer ScrumMaster.

Beobachtung 3: Eine wirkungsvollen Vision unterstützt die Veränderung

Mut zu signifikanten Veränderungen in der Organisation haben, ist ein agiler Wert (Courage). Zu wenig davon kann teuer für ein Unternehmen sein, das auf dem Weg zur Agilisierung ist. Änderungen sind bekanntlich unbequem und schmerzhaft, können Angst und Widerstand erzeugen. Grund genug, um diese unter Vorwand nicht umzusetzen oder zu verschieben.
Auf dem „Planeten“, den ich besuchte, haben dessen “Bewohner“ im Rahmen der Entwicklung neuer Produkte einen Weg gefunden, mit den Veränderungsängsten umzugehen: Sie stellen sich ein sehr klares Bild einer gemeinsamen gewünschten Zukunft vor. Das tun sie so lange, bis dieses Bild so vielversprechend, klar und schön ist, dass es eine große Anziehungskraft entwickelt, für alle! Sie beginnen die Zukunft mit dem neuen Produkt zu lieben! Danach fällt es allen leichter, die Kraft und die Entschlossenheit für die Bewältigung der Schwierigkeiten auf dem Weg dahin zu finden.
Ich bin jetzt von der Reise zurück, fest entschlossen das zu nutzen, einzusetzen und anderen zurückzugeben, was ich für mich erkannt, herausgefunden, erlebt habe.
Hier mein Aufruf an die vielen ScrumMaster, die sicher ständig ihre neugierigen Blicke als Change Agent schweifen lassen:

Ich bin seit meiner Rückkehr von diesem gar nicht mehr so fremden Planeten überzeugt, dass wenn ihr schon einen der drei Punkte verfolgt, viele Erfolgsstories auch auf euren Heimatplaneten entstehen.

Definition of Done: Die harte Schule

Das Ende des Sprints naht und nur noch Tasks wie “Systemdoku ergänzen” und “Abnahme mit dem PO durchführen” kleben in der To-Do-Spalte. Ein Blick auf die Definition of Done neben dem Board verrät, dass das Team sich dazu committed hat, die Doku abzuschließen, bevor sie eine Story als DONE deklariert und somit dem PO zur Abnahme übergeben kann.
Nun ist es aber doch dringend, man könne die Systemdoku doch auch machen, nachdem die Abnahme vom PO erfolgt sei. Sie wäre ja schließlich sowieso nur von Entwicklern für Entwickler, den PO würde das nicht interessieren und er würde es auch nicht lesen. Vielleicht würde er noch Fehler finden oder Anpassungen haben wollen und dann müsse man die doch dringender machen als die Systemdoku. Ein Implementierungs-Task sei schließlich wichtiger als ein Doku Task …

Die Biegbarkeit der DoD

Ich diskutierte lange mit dem Teammitglied über Sinn und Unsinn der DoD. Als dann das Argument fiel “Dann müssen wir eben die DoD anpassen, da steht sowieso zu viel drin! Und du hast gesagt, dass das Team die DoD festlegt, stimmts?”, mischte sich ein weiteres Teammitglied ein. Zuerst stimmte er in den Chor der DoD-Kürzung ein, doch bei ernsthafter Betrachtung stellte er fest: “Naja, der faule Entwicklerteil in mir sagt, dass wir etwas streichen sollten, aber der vernünftige sagt, dass wir es sonst nur wieder aufschieben. Dann wird es so wie in den alten Projekten: Die Doku machen wir, wenn wir noch Aufwand übrig haben! Und dann hat man natürlich keinen Aufwand übrig!”
Im Nachgang, als ich von dem Erlebnis erzählte, wurde mir klar, dass Scrum wahrscheinlich einfach eine Methode ist, mit der sich Menschen selbst überlisten. In einem guten Moment schreibt man alles auf, was sinnvoll ist und committet sich schnell dazu, bevor man es sich wieder anders überlegt. Später fragt man sich an der einen oder anderen Stelle, warum genau man sich auf so etwas eingelassen hat. Hätte man nicht gleich sehen können, wie unrealistisch das ist bzw. wie viel Disziplin nötig ist, um das dauerhaft einzuhalten? Immerhin würden mir heute tausend Gründe einfallen, warum etwas anderes viiieel wichtiger ist als Doku, nochmaliges komplettes Testen nach einer minimalen Änderung, Testautomatisierung etc.
Pilotprojekten wird oft ein großer Vertrauensvorschuss gewährt. Man hebelt die “normalen” Prozesse aus und vertraut, dass das Team mit seinem eigenen Anspruch eine hohe Qualität liefert. Das ist gut und richtig. Oft jedoch holen einen alte Verhaltensweisen wie Featuredruck oder das Ziel der Performance-Steigerung schnell ein. Die Teammitglieder sind gewohnt an der Qualität zu sparen, wenn es knapp wird, kurzfristige vermeintliche Erfolge über z.B. die Wartbarkeit zu stellen. Im Einzelfall scheint es daher manchmal kleinkariert, auf den Regeln zu beharren. In dieser Situation sollte man sich schleunigst daran erinnern, dass man sich aus gutem Grunde selbst ausgetrickst hat.