Focus and focus time

In this post, I explore the Scrum value of focus, the notion of focus time and its implications for your Scrum team’s setup.

Focus as a Scrum value

Focus. It is one of the core values of Scrum, reminding us to be precise about our development goals and to stay on target at all times.

Focus tells Product Owners to build one product for a well defined audience, tells Scrum Masters to help their teams improve in one area at a time, and tells the Development Team to go for the Sprint goal and only the Sprint goal.

It is them - the team - I want to focus on in this post, although the thoughts apply to the other roles as well.

Focus time

Recently, a client introduced me to the notion of focus time. By his definition, focus time is the part of a Sprint that the team actually spends working on product backlog items directly contributing to the Sprint goal.

Thus, focus time is comprised of all the work required to get one specific product backlog item from “ready” to “done”, including design, implementation, testing, documentation and posing the odd question to the Product Owner or relevant stakeholders.

It is not: Helping to prepare the next Sprint, demonstrating the product increment in the review, improving the process in the retrospective or organizing the team in the Daily Scrum.¹ While all of these activities are important, they are by definition off-focus, as they do not directly improve the product².

Perfect world

In an ideal setup, the team spends most of their time focused. The Scrum Guide allows for up to 10% of the development team’s time to be taken for product backlog refinement³, while planning, review and retrospective take up 10% of the team’s time yet again.

Another 5% are eaten up by Daily Scrums and general communication with people in- and outside of our product: Even the best of bosses and stakeholders need some attention from time to time.

This leaves our ideal development team with
100% Sprint time

- 10% refinement

- 10% planning, review, retrospective

- 5% Daily Scrum and communication

=  75% focus time

That’s 7½ workdays out of your two week sprint! Contrast that with the common complaint that Scrum is all talking and keeps people from getting things done.

Half measures

Rare, however, is the team where all team member contribute all day, every day. The larger an organization, the larger its tendency to split people’s time and attention over several projects or products.

25 years ago, in 'Quality Software Management: Systems Thinking', Gerald Weinberg introduced us to the hidden cost of context switching, claiming that an even split across two projects left a knowledge worker with only 40% of his or her capacity to apply to each of them. (While Weinberg's original text is not available for free, his idea has spread beyond the cover of his book.)

So, let’s split some people and look at their focus time:

50% allotted time

- 10% context switching

- 5% refinement

- 10% planning, review and retrospective

-  5% Daily Scrum and communication

= 20% focus time

In case you’re wondering, I left the numbers for the four main Scrum rituals at their original value since all teams I have worked with so far insisted that their split members take part in all of them, since this is where the team makes all major decisions.

So, out of a promised 50% of somebody’s time and attention, only 20% contribute directly to the goals we set for the product – that’s hardly more than half of the 37.5% we might expect when looking at the original calculation.

Now, suddenly, Scrum is all talk and no action.

Said and done

So, the idea of focus – concentrating on what we ought to do – lead us to the notion of focus time, the time spent directly contributing to the Sprint goal. We have seen that ¾ of a team’s time could be spent focused, and that this number shrinks drastically when we split people’s time across products.

Now, I’d like to invite you to examine the time your team spends focused.

Do you get close to ideal numbers? Are you in the 20% range, even though everyone is on the project 100% of their time? Where does the time people don’t spend focused go and which of these activities are really necessary?

All in all: What could you do to improve the numbers?

Besides looking at things that distract the team, you might want to look at the product backlog items your team and Product Owner agree upon for the sprint. Is there a common theme, so that most or all of them contribute to a single goal?

If they have little in common, one could argue, there is not really one Sprint goal, and the team could never reach the lofty numbers I laid out above. However, there could be leverage in the way the Product Owner prioritizes the product backlog or the way you plan your sprints.

Let’s talk about your numbers and your findings in the comments!

Postscriptum

Writing this post brought to my mind a number of questions, among them:

“What keeps teams from focussing and how to get back there quickly?”, “How to show the value of Scrum’s rituals to the ‘rather do than talk’ faction?”, and “Is focus time a good measure for the quality of a Scrum process? What other metrics are there?”

Comment below if you have thoughts on any of these questions or are particularly interested in one of them.

---

1 Neither is it taking part in communities of practice, performance reviews, answering mails, general discussion or undirected learning, along with most other things team members like to do.^↩

2 Actually, this is the main reason that some developers tend to resent them. Hackers want to do, not talk. As a Scrum Master, you could do worse than to think about this before your colleagues bring it up.^↩

3 Note that this is not the established practice of a “refinement meeting”, but rather includes all activities dealing with the process of refining the product backlog.^↩

Punkt, Punkt, Komma, Strich

Heute habe ich mich mit meiner Kollegin Anna Lorenz (@roadranna) über Daten und Punkte am Satzende unterhalten. Wieviele sind es? Und wann? Ein Ausflug in die Interpunktion.

Das Datum und der Doppel-Punkt

Auf den ersten Blick war die Frage einfach: Schreibe ich nach einem Datum am Satzende einen oder zwei Punkte?
Also:

Ich komme am 01.10..

oder doch lieber

Ich komme am 02.10.

Klare Frage, klare Antwort: Version zwei ist richtig.
Förmlich heißt das dann: "Am Ende eines Ganzsatzes setzt man nach Ordinalzahlen, die in Ziffern geschrieben sind, nur einen Punkt.." (§105 der amtlichen Rechtschreibregeln)

Abkürzungen und Ellipsen

Das aber ist natürlich nur die halbe Antwort, denn auch andere Fälle bringen Punkte vor den Punkt:

Abkürzungen zum Beispiel

Ich komme am 03. Okt.

und auch Ellipsen, etwa wenn ich laut nachdenke

Ich sollte am 04.10. kommen...

Wieder setzen wir keinen weiteren Punkt.
Förmlich: "Am Ende eines Ganzsatzes setzt man nach Abkürzungen nur einen Punkt." (§103 der amtlichen Rechtschreibregeln)
Zusammengefasst können wir also festhalten: Nach Punkten steht kein Punkt.

Satzzeichen mit und ohne Ende

Zum Glück aber ist nicht alles Punkt, was am Satzende steht, und da verhält sich die Sache anders:

Du kommst am 05.10.!

brüllt der Vater dem Sohn nach, wenn jener droht, der Mutter Geburtstag zu verpassen, und

Kommst Du am 06.10.?

fragen wir bei einer Einladung zu einem gemeinsamen Freund.

Genauso verhält es sich bei den schwächeren Satzzeichen Komma und Semikolon, beim Gedankenstrich und beim Doppelpunkt.

Wie geht's noch?

Jetzt hilft die schönste Regel nicht, wenn der Leser trotzdem darüber stolpert und sich wie wir heute fragt: "Ist das so richtig?"

Elegant und zweifelsfrei umschifft man das Problem mit ein paar Ziffern mehr

Ich komme am 07.10.2015.

oder einigen zusätzlichen Buchstaben

Ich komme am 08. Oktober.

Bei Abkürzungen stellt sich die Frage nicht mehr, wenn wir sie ausschreiben.

Tisch für zwei allein

Doch Vorsicht: Während der Vorschlag

Ich könnte am 09.10. kommen oder am 10.10.

leicht von der Hand geht, steht bei der langen Form

Ich könnte am 11. Oktober kommen oder am 12. Oktober.

sofort der innere Deutschlehrer hinter uns und mahnt die Doppelung an.
Schnell steht da

Ich könnte am 13. Oktober kommen oder am 14.

und wenn ich diese Zeile am 10. September schicken, dann wartet Anna vielleicht vergeblich auf mich.

Body scanner estimation

9 out of 10 coaches agree: Estimating is not about the numbers, but about the dialogue.

Even though, many teams find themselves discussing a meager difference in story points - often to the point of frustrated sighs - while the technical details are long clarified.

Today, I have been listening to an explanation of story point estimation. The team was just discussing a list of criteria to judge stories by, and I couldn't help but think: "What if we just cut to the dialogue instead of dealing with points, and used the criteria to encourage it?"

That thought led to a quasi-algorithmic way of estimating, quickly dubbed "Body scanner estimation" by my colleague Ilja Preuß (@ipreuss on twitter).

How to play

1. Discussing the story itself, and answer any questions.
2. Answer all of the following questions with either Yes or No.

• Inside/Outside
• Do we need to pull support or input from outside the team?
• Does it affect outside systems?
• Do we need to share knowledge about the results?
• Does it need management approval?
• Knowledge/Skill
• Does it need specialized knowledge? (Or can any of us do it?)
• Is this story the first of its kind for our team?
• Is it very time consuming?
• Is it annoying to complete?
• Technical
• Do we have technical debt in the vincinity?
• Does the change ripple throughout our system?
• Do we need to set up testing infrastructure?
• Do we need to set up build infrastructure?

3. Now, count the number of "Yes" and add 1 as the base cost.

4. Round the result to the nearest number from Fibonacci's sequence to get your estimation.

5. Sanity check the result.

This method of estimation gives teams a handrail to work with, with questions to spark further thought and discussion.

I yet to try Body scanner estimation, so I am eager to hear of your results. Do the questions make sense to you? Did you add some of your own?

More importantly, though, did you come up with a fresh way of estimating lately? 

Let us know in the comments.

A template to communicate intent

In a corporate environment, teams face many different stakeholders.

Despite of best efforts, team members often have trouble judging requests for what they are actually worth, and tend to react to apparent urgency instead of actual value.

A team lead I recently met found himself in the very same situation, and prompted me for advice. In our conversation, we found out that in his particular case, the issue was partly about communication: the team members didn't know the teams goals, and so they had little to go against.

However, knowing that goal would only get them so far, because things are rarely cut clearly - a request may be out of scope for the team, but fully aligned with the division goal.

The template

Shortly after, I came up with a template to cover three levels of goals and intent:

We will [achieve the team goal],
in order to [achieve the division's goal]
so that the company can [achieve the company's goal].

For example:
"We will ensure the performance of the mainframe
in order to enable the free flow of data
so that Skynet always remains one step ahead of the resistance."

How to apply it

Facing fresh input, this enables team members to think on their feet and look beyond the team's immediate goals, judging issues not only by what their team lead told them, but also by the larger objectives.

This mirrors the military concept of commander's intent, where doctrine says that the aim, purpose and implications of an operation have to be understood two echelons down - something that can hardly be achieved in a single sentence.

By that measure, just filling in the blanks makes for a nice poster, but leaves half the work undone: The actual act of face-to-face communication, where the team lead informs his colleagues about the three levels and their implications - once to make them clear, and once again whenever they change.

Obviously, a dialogue like this requires knowledge of the higher level's intent - but that is hardly a bad thing, since communication goals in a clear and concise fashion is part of proper leadership.

By my assessment, this template works best when the team has an overarching goal or mission that keeps constant for at least some weeks. With small adjustments, though, you could easily use the template for short term objectives like Sprint goals in a Scrum process.

What do you think of the template? What do you do to communicate management intent to your teams? Please tell me in the comments.

Antifr-Agil

In der aktuellen Ausgabe der "agile review" sprechen Sandra und ich über Antifragilität.
Hier ist der erste Teil, dem im vollen Artikel eine Diskussion aus Sicht der Berater und weitere Gespräche folgen.

Interessiert er euch? Schreibt mir, ich schicke euch gern ein Exemplar der Zeitschrift!

Antifr-agil
Ein Dialog in 3 Teilen von Urs Reupke und Sandra Reupke-Sieroux

Erstes Gespräch: Antifragilität

Die Schildkröte hat es sich im Schatten eines Baumes bequem gemacht, den Achill unruhig umschreitet.

Achill: “Welch Trick! Um der Schmach der Niederlage zu entgehen, greifst Du zu Mitteln, Panzertier, die Deiner unwürdig sind! Doch höre: Die Götter sollen den Gleichstand entscheiden. Heb Deine Fäuste, Reptil!”

Schildkröte: “Kampf, Kampf, stets höre ich Kampf. Eines Tages wird Deine Zeit vergehen, mein Freund, wenn einer kommt, Dich zu besiegen.”

Achill, aufgebracht: “Hektor schlug ich, Trojas größten Helden! ‘Unbesiegbarer Achill’ haben sie gerufen! Keinen Kampf habe ich je verloren, und schwach reden wirst Du mich nicht.”

Schildkröte: “‘Unbesiegt’ jubelten sie, nicht ‘unbesiegbar’. Früher oder später kommt eine Zeit, in dem Dein Alter Dir das Kriegshandwerk verbietet. Was dann?”

Achill darauf: “Dann musiziere ich! Cheiron lehrte mich die Laute!”

Tönt es aus dem Schnabel der Schildkröte: “Nein, dann stirbst Du. Der Feind kennt keine Gnade! Ein größerer Verlust ist undenkbar, und wie begrenzt der Gewinn: Eine Stadt, ein Königreich, und wenn sie ein Juwel ist wie das vielbesungene Troja - ein Fehltritt, und anstelle ihrer Schätze erblickst Du die elysischen Felder. Nimm allein Deine Ferse…” ﹣ “Sprechen wir nicht darüber!” ﹣ “Deine Verse! Dein Lautenspiel! Harmonielos wie es auch sein mag, birgt es doch ungleich weniger Gefahr. Wer weiß, wes gönnerhaftes Herz Du regst, wenn Du den rechten Ton anschlägst! Alles, was Du wagst, ist ein Abend mit knurrendem Magen, doch der Lohn, süßer Lohn! Welch Reichtümer könnten Dich erwarten, welch Ehre könnte Dein sein.

Jeder Abend, jede Nacht bietet Dir eine neue Gelegenheit, einen neuen Wurf, Unsterblichkeit zu erlangen!”

Kommentar: Was ist antifragil?

“Antifragilität” charakterisiert Systeme, die von zufälligen Ereignissen profitieren, anstatt wie “fragile” Systeme darunter zu leiden oder ihnen indifferent gegenüber zu stehen, wie es “robuste” Systeme tun.

Nassim Nicholas Taleb, Spekulant und Philosoph, beschrieb das Konzept 2012 in seinem gleichnamigen Buch [3]. Er zeigt darin auch eine Reihe weiterer Eigenschaften, die solche Systeme ausmachen - Eigenschaften, zu denen die Schildkröte Achills Leben verhelfen möchte.
Ihr Rat beherzigt den Grundsatz antifragiler Systeme: [Weiter gehts in agile review 01/2014]

Schreib mir und ich schick Dir!

I like Java 8 streams

I'm learning the JDK 8 API.
This seems pretty sweet, for Java standards:

Stream<String> input = Stream.of("Tick", "Trick", "Track");
Map output = input.collect(toMap(t -> t.length(), t -> t, (t, t2) -> t + "," + t2));
System.out.println(output);

Result: {4=Tick, 5=Trick,Track}

Der Agile Entdecker

Gemeinsamer Post mit Sandra Reupke-Sieroux und Olaf Lewitz:

Bei der play4agile 2014 hat Olaf mir erzählt, dass er schon eine Weile daran sitzt, Tobias Mayers Buch "The People's Scrum" ins Deutsche zu übertragen. Im Gespräch am Abend hat er mich und Sandra eingeladen mitzumachen. Alan Cyment, der an der spanischen Version arbeitet, gab uns drei einen Haufen Tips, und seitdem arbeiten wir daran.

Wir wollen in den nächsten Wochen einige der Essays vorab veröffentlichen - das Buch ist ja aus einem Blog entstanden. Auch für die deutsche Version sind wir gespannt auf euer Feedback!

"Der Agile Entdecker" haben wir als ersten gemeinsamen Post ausgewählt, weil es der Essay im Buch war, bei dem wir unsere gemeinsame Sprache gefunden haben. Wie viele seiner Essays vereint er Kritik an einem bekannten und verbreiteten Konzept mit einer neue Idee - gerade ausreichend skizziert, um sich inspirieren zu lassen. Tobias sagt uns nicht, was wir tun sollen. Er öffnet unser Herz und unseren Verstand für Neues, manchmal Radikales.

Viel Spaß beim Lesen! Habt ihr Agile Entdecker im Unternehmen? Habt ihr so was schon mal gemacht?

Der Agile Entdecker

Während eines Projekts in Indianapolis unterhielt ich mich mit einem Entwickler.
“Was weißt Du über Atomkraft?” fragte er mich, und erzählte dann, dass er in einem Atomkraftwerk gearbeitet habe. Dort erfuhren alle Arbeiter regelmäßige Schulungen über die Sicherheitsbestimmungen, sogar noch nach langjähriger Anstellung.

Die beste Absicherung gegen eine Kernschmelze sei, sagte er, die Köpfe der Kollegen stets durch aktuelle Erkenntnisse und häufige Erinnerungen an gutes Vorgehen wach zu halten.

Er fragte mich, warum agile Ausbildungen nach einem Durchgang vorüber wären. Er habe in verschiedenen Organisationen während der agilen Transition beobachtet, dass die Leute nach dem Training gut voran kamen und voller Wissen und Begeisterung steckten, diese Energie jedoch schnell verebbte und das gewohnte Verhalten zurückkehrte.

“Auch Softwarefirmen schmelzen”, stellte er fest.

Daraufhin hab ich mich damit beschäftigt, wie Firmen Scrum einführen und verwalten. Die meisten heuern für eine kurze Zeit Berater oder Trainer an.

Die Engagierteren unter ihnen besorgen sich einen Scrum Master, der von einem der zahllosen Verbände zertifiziert ist - im festen Glauben, das Zertifikat gewähre Qualität. Beide Ansätze erreichen dieses Ziel selten.

Hin und wieder habe ich den Gedanken, dass der Begriff des “Scrum Masters” die Agile Bewegung aufhält, dass diese Position die Selbstorganisation behindert. Zwar ist die Absicht gut, doch in der Praxis wird die Rolle viel zu oft herabgewürdigt zum Metriksammler, zum Prozesswachhund, im schlimmsten Fall sogar zur Scrumpolizei oder zum agilen Projektmanager.

Dadurch entreißt man dem Team Verantwortung, und die Menschen unterwerfen sich dem Prozess, der ihnen aufgebürdet wird.

Tobias Mayer

In den letzten zwei Jahren ist die Rolle des Scrum Masters in meinen Kursen immer mehr in den Hintergrund getreten. Ich beschreibe Scrum als die Beziehung zwischen Product Owner und Team und erforsche diese Beziehung in Hinblick auf Teamkultur, Fokus, gemeinsame Ausrichtung und Zusammenarbeit.

Scrum verspricht engagierte Teams und glückliche Kunden, aber dieses Versprechen löst das Problem der Kernschmelze nicht. Die Organisation muss nach wie vor einen nachhaltigen Weg finden, um kontinuierliche Verbesserung rund um die Grundprinzipien des Scrum-Frameworks zu etablieren.

Scrum Master sind dieser Weg nicht, denn Scrum Master sind stets auf den untersten Rängen des hierarchischen Totempfahls angesiedelt. Häufig müssen sie einer Projektmanagementabteilung Rede und Antwort stehen oder einem Entwicklungsleiter. Sie haben wenig Autonomie und werden oft zu Helfershelfern des Status Quo.

Auch agiles Coaching ist nicht der Weg. Coaching hilft Einzelnen und Teams sich selbst zu verwirklichen, doch wie bei einer Therapie kommt der Moment, an dem der Coachee die Beziehung beenden muss. Tut er es nicht, läuft er Gefahr, sich mit seinem Coach im Kreis zu drehen und gemeinsam eine ungesunde Beziehung gegenseitiger Abhängigkeit zu schaffen.

Der Weg scheint mir zu sein, Agilität in die DNS der Organisation zu injizieren. Wir wissen, dass Viren die DNS von Organismen verändern können, wenn sie nur stark genug sind, die Antikörper des Wirts abzuwehren. Um die Kultur der Organisation zu verändern, brauchen wir genau so ein Virus.

Daher möchte ich eine neue Rolle vorschlagen, um das Virus zu verbreiten: Den Agilen Entdecker. Diese Rolle ist anders als die des “Paten der Agilität”. Der Pate ist jemand - häufig ein Geschäftsführer oder der Chef der Entwicklungsabteilung - der sagt: “Jetzt aber agil!”, aber der weder versteht, welcher Änderungen in der Organisation dieser Schritt bedarf, noch die Zeit hat, sich auf wirkliche Veränderung einzulassen.

Der Agile Entdecker ist jemand, der auf der Suche nach Wissen in unerforschtes Land reist. Er oder sie ist ein Visionär und ein furchtloser Abenteurer, der durch seine Handlungen andere inspiriert selbst aufzubrechen.

Agiler Entdecker ist ein Vollzeitjob. Am besten ist es, wenn er niemandem unterstellt ist, doch wenn es sein muss, dann sollte er der Geschäftsführung berichten, und zwar in einer autonome Position, deren Leistung nicht gemessen wird.

Es ist nicht die Aufgabe des Entdeckers, Teams zu coachen oder anderen zu helfen, besser mit Scrum umzugehen.

Er oder sie soll zuhören, denken, inspirieren, konfrontieren, anheizen, herausfordern und die kollektiven Augen der Organisation öffnen, damit sie neue Möglichkeiten erblicken können. So sät er die Saat eines neuen Seins.

Ein guter Agiler Entdecker bringt sich in die agile Gemeinschaft außerhalb seiner Firma ein, nimmt an Veranstaltungen teil, diskutiert online, liest ausgiebig, lernt Neues und fördert den Dialog mit anderen Organisationen und Individuen. Er sorgt für den Austausch im Haus, begründet Gesprächsrunden und Workshops und fördert Ideen rund um experimentelle Verbesserung.

Insbesondere aber ermutigt er andere, es ihm gleich zu tun.

Der Agile Entdecker webt aus Silos und Hierarchien faszinierende Werke kinetischer Kunst, die Ehrfurcht und Erstaunen erwecken. Diese Umgebungen lassen Selbstorganisation gedeihen; gegenseitiges Coaching floriert und ersetzt teure Hilfsarbeiter, die sich nicht ums Ergebnis scheren. Das Engagement wird stärker, die Freude wächst - und die Kernschmelze bleibt aus, Tag um inspirierten Tag.

Tobias Mayer, 19. April 2012