Teams R SEXI

In this post, I will explore what makes a good Development Team in Scrum from an organizational perspective.

Great teams

When it comes to structuring the Development Team, the Scrum Guide tells us that the team is “cross-functional, with all of the skills as a team necessary to create a product increment” and that the team should be structured to “organize and manage their own work”. Finally, we learn that the team should have between 3 and 9 developers, to be able to contain all the skills required while not increasing management complexity beyond the level self-organization can casually deal with.

Over the past few years, I have helped some clients to improve their teams’ setup and structure, and found that there are more criteria that the Scrum Guide only hints at but never mentioned explicitly.

Have few dependencies

While Scrum expects the team to be able to provide the product increment on their own, corporate reality often sees products with a scope much larger than what a single team can produce in reasonable time.

You may have read about scaling approaches like LeSS, and their call for feature teams. Rare is the product, though, where splitting into features is possible the moment your start with Scrum.

To alleviate the situation, I look for a setup where inter-team dependencies are as few as possible. In an ideal case, this means that the team has one team to receive input from and one more team to deliver output to.

For work to flow, the team has to be independent from other teams. Define your teams so that their scope covers a large, uninterrupted piece of the value chain, and integrate technical concerns as much as possible.

That way, you will reduce the number of handovers both in planning and in the actual work done.

Stay together

In a corporate environment, projects start and stop all the time. Project managers vie for resources, eyes on the deadline, not on the social effects. For team members, this means that today’s colleague may be gone tomorrow – so each of them looks out for their own piece of work first and foremost.

When introducing Scrum in such an environment, I emphasize the twin values of stability and reliability.

It takes a stable environment for employees to benefit from investing in the team’s success rather than their own achievements. Team members learn to trust each other over time and start to co-operate. In a stable teams, members can learn each other’s abilities and preferences – and that’s what it takes to get better.

Reliability, meanwhile, means that team members are on the team, period. Splitting people between projects eats up time beyond the numbers in your spreadsheet, as it introduces interruptions in the form of urgent requests from outside projects.

Now, any corporation worth the name will have a complex resource distribution in place already, and you will be hard pressed to change it all at once. What to do?

Allot people to the product as much as possible, and encourage them to block fixed slots of time for working on the product. If necessary, suggest they turn off phones, chat and mail clients; empower them to postpone dealing with incoming requests till team time is over.

That way, their team can learn rely on them, and teamwork improves.

Learn from each other

Remember what the Scrum Guide said? “Teams organize and manage their own work.”

It takes a certain level of experience to do that, and I have frequently heard managers or Scrum Masters complain that their team is not yet ready for this level of freedom – and next coordinate the work themselves, trampling the sprouts of self-organization.

So, it takes experience for the team to self-organize, and it takes laissez-faire.

The best teams I worked with did not consist of veterans only, though, since less experienced team members bring two crucial factors to the team: By embracing their curiosity, they challenge long-standing practices; by working with several of their more senior colleagues, they foster communication.

So, when building a team, I look for a good mix of old hands and new to make learning happen and self-organization possible, while still having all the skills to actually build the product.

Make work flow

This concludes my thoughts about criteria to watch out for when building great teams:

reliabilty, stability, experience, cross-functionality and independence.

So, when you are next thinking about how to improve your team, just think “Teams R SEXI”, and you are well on your way:

Reliable

Stable

Experienced adequately

X-functional and

Independent

Mind, though, that these criteria are strongly skewed towards the organizational perspective and pay no heed to the more mushy, social criteria that are well worth considering as well.

What criteria do you apply to find your teams? Did you go at it from an entirely different angle? 

I am looking forward to your comments.

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.^↩

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

Respite and Trust in Timeboxes

Looking for a proper translation for the concept of a "time-box" in the context of Scrum, I looked up the German word "Frist". The word describes a period of time in which a certain action may (or may not) be taken, it's mostly used in a judicial context.

Inspired by a note on the words roots in Old High German, I consulted Wiktionary, and discovered that the word has siblings in several Germanic languages and is known even in English (albeit obsolete).

I was delighted by the connotations on offer: Throughout the languages, the concept denotes not only an allowance of time, but also signals a respite or truce as well as trust - all of which are on display when mutually agreeing on a time-box in Scrum.

I couldn't wish for a better match.