Adding a new team member to an existing team always introduces challenges. The introduction changes the makeup of the team, and if the team had jelled, it has to do so, again, with the new member.

Also, the new member has to learn about the team and its work. There are many tacit assumptions held within a team. It’s impossible to document them all and, even if you could, both reading such a document and keeping it up to date are daunting herculean tasks.

So how do you maximize the integration of a new team member with a minimum amount of work?  Here’s a way that one team with whom I worked approached the problem.

First, they brainstormed a list of topics that a new team member needed to know. It included things like how they used the story wall, who had what role on the team, the architecture of the system, the team working agreements, and the local Agile practices. These topics were written on index cards, one to a card. When a new team member came on board, they setup a section of wall with Backlog, In Process, and Done columns, and put the index cards in the Backlog column, in a rough approximation of the order to learn them.

Existing team members put post-it notes with their names on the cards they were prepared to help with. It was the new team member’s responsibility to work through these cards, one or a few at a time. The would take a card, put it in the In Process column, and ask the person named on the post-it to help them learn whatever the card mentioned. Sometimes this took a few minutes, and sometimes it took several days to go over the topic on a card. As each card was completed, it was moved to the Done column.

The very last card was “update the new member backlog cards.” Since the newest member had just gone through the process, they were in the best position to update the deck, adding, removing, and reordering cards as appropriate. This put the deck in the best possible shape for the next new member, while the memories were still fresh.

When I first took on the role of CTO at Assembla, I researched Team Building and came upon the dreaded Corporate Retreat with a lava walk or lava flow exercise.  It's a team building exercise, that quite frankly seems boring. Well I currently reside in Hawaii and we have a totally different take on the Lava Walk.  

The Team

Here you see Ben Potts (DevOps extraordinaire), myself, and Nadia Romano (CX Engineer afficionado). These two along with another (Ramsey, not pictured, he snapped the photo) followed me into a lava field for a grueling 13 hour hike, it was meant to be only 2 hours. But once out in that field, the lava beckons you to continue on until you find it.

The Treacherous Road

The terrain was tough. Lava once hardened is not like walking along pavement, so much as walking along pavement with broken bottles littered across it after an earthquake. You have to be careful where you step to say the least. Everything around you is black lava. The air is full of smoke and sulphur smells at times. And of course, we had limited water supplies, flashlights, and mosty appropriate clothing for the terrain (good hiking shoes, long pants, and an additional layer).

Fortunately we also chose to walk on a nearly Full Moon - which allowed us to not use the flashlights (as the batteries on our smartphones (the flashlight apps are great) were dying) and walk in the pale light of the moon, it was fantastic. 

We made it to the lava fountains after 4 hours or so of walking, it was sheer magnificence. To watch lava ooze down the side of a fountain is a treat to see.

The video does it no justice, smartphones just can't capture the actual image that is unfolding 3 feet (~1 meter) in front of your face.

Lessons Learned

An actual Lava Walk has many lessons to be learned hidden within it. Each person has a role to play:

• Leader, the one who sets the path and keeps the group moving
• Enthusiast, the one who remains positive and keeps the group motivated
• Stalwart, the one who continues on beyond all obstacles and triumphs
• Supporter, the one who helps others in their time of need

The role is not so much chosen as it is placed upon you. Sometimes the roles shift from person to person. I learned about these people while walking through this barren wasteland and I am sure they learned about me.  Ben is always positive and moving forward. He wants to see things and make things happen. Nadia will accomplish any task no matter how hard.  She is not afraid of an obstacle in her way. I learned that I am stubborn and when I should push people to move faster or harder and when I should allow them to move at their own pace.   

All in all it was a great experience and I hope that I continue doing other Team Building exercises in the real world, maybe not so extreme next time. I do not encourage you to make a real Lava Walk as part of your corporate exercises. This time it ended well, only some bruised ankles and sore feet. I do have to apologize to Ben's wife for keeping him out so late and worrying her half to death:

Shannon - I sincerely apologize, it was all my fault that Ben did not come back until the morning. Sorry.

We did get to see a beautiful sunrise in the morning as we left the fields. It was a worthwhile adventure.

Would I do it again?

Absolutely, I would, however not all people want to trudge through lava fields, perhaps just a Magic the Gathering Session would be a good Team Building exercise next time.

People do love that game. He sure does.

That’s right. We’ve done it once and now we are doing it again. For tinyPM 3.0 we’ve made a lot of small changes and it influenced also the translations.

You as a tinyPM user can help translate the tool into your language. Why should you do that? Well… Agile tools play the best role in distributed environments where different cultures with different languages meet together. You can make it feel more familiar to your team mates. However we have also something for you personally :-)

What do you need?

• You need to know English and one another language (your national language)
• You need some time
• You need to have a SaaS tinyPM account with any plan (PERSONAL is enough)

What are the rules?

• Top contributor for each language wins a tinyPM t-shirt and a $20 Amazon.com gift certificate.
• Each other contributor who provides at least 20% of translation gets a tinyPM t-shirt.
• We will send gifts and include a language in main tinyPM release when it reaches 80% of translation.

Where to start?

You need to log into your own tinyPM. From there you can access translations in the two following ways.

• First one is to go to your “Account Settings” and there you will find a “Language” and a link to translations application.
• Second one is to use a “gear” menu in the upper-right corner of the screen, which contains “Translate tinyPM” option.

Oh, by the way… When I’m writing this post we have already Spanish translation done, Portuguese and German in progress with new contributions! You are great!

Update May 8th, 2013

Yeah! There are some translations that are already finished. It’s also great to see some new languages that where not present in previous versions. Great! We’ve already contaced translators and are sending gifts.

• Spanish
• Slovenian NEW!
• Chinese
• Suomi (Finnish) NEW!
• French
• German
• Russian

A few more are in progress. Gift certificates and T-shirts are waiting!

• Portuguese
• Dutch
• Afrikaans NEW!

One of the promises of agile is the idea of continually adapting the process - inspecting and adapting as you learn about what works and what needs to change. When a scrum team is able to identify a process impediment in the daily standup or sprint retrospective and fix it the same day, we’re able to very quickly iterate to a highly effective process for that team.

As we scale Agile, it’s natural to want the same thing for the portfolio or organization.

And in my time managing the portfolio at Rally, I’ve learned that inspecting and adapting is one of the keys to making a sane portfolio process that delivers value smoothly, supports strategic steering, and reduces waste. But inspecting and adapting takes a very different form at scale.

When you have a small team of 5-7 people sitting together in one room, talking about a process change that impacts only them, it’s easy to make a consensus-based decision and roll it out. You don’t have to ask for permission or get help.

But at scale, any change you make is going to impact many people.

We’re all familiar with top-down change initiatives. Senior leadership gets together, analyzes the problem, designs a solution, and announces it. Everyone else is left to react.

This approach leads to problems for two main reasons. First, people don’t know when change is going to happen, so they live in a constant state of low-level anxiety. Second, the leadership group never has all of the context. Often, there’s local information that would make a big difference if it were known.

Well intentioned agilists often try the obvious collaborative approach: Get everyone together in one big room and talk through the change. This doesn’t work well either. It’s expensive; it’s hard to make process changes in a large group, and it’s hard to do effective root-cause analysis with more than 4-5 people.

So what do I suggest instead? Think about 3 things:

1. Cadence. How often does your process need to change at scale? My experience has been that minor changes to meeting agendas should be considered with every meeting. If you have a monthly council, apply the learnings from each meeting to the next one, and send out the agenda in advance. Bigger changes (purposes of meetings; who makes what decision, etc) should be considered and made on a quarterly basis. We don’t change our process every quarter, but we try very hard to only propose disruptive changes around quarterly boundaries. This dramatically reduces ‘change anxiety’.

2. Communication plan. How often have you been notified about a change to a meeting purpose and agenda when you arrive at the meeting? It’s better to give people warning so they can be prepared. At higher levels of the portfolio, people often have tight schedules and struggle to maintain slack time, so don’t overhaul a meeting and expect them to do 3 hours of prep with 3 days of notice.

3. Consent. It is hard to design a process that everyone likes on paper. Change can be stressful. People worry about power shifts, how they will appear to their peers, and whether the change will make their lives easier or harder. Often it seems easier not to change. Over the years, I’ve tried many times to get every single person in a group to buy-in to a process change. I’ve scheduled hundreds of one-on-one meetings, trying to please everyone. You’ll never please everyone.

Now, I approach it differently. I sample the group. I talk to a handful of people 1-on-1. Sometimes I pair with another person on figuring out a process change. I write a clear, short explanation of what i’m proposing and what the underlying goal is I’m trying to achieve.

Then I ask for consent to move forward. This is a concept I picked up from a governance system called Holocracy. I say, “Are you willing to let me run an experiment with this for a month or two, knowing that we will adjust based on what we learn?” I ask if people know specific ways the proposed change will harm the organization. This is very different from asking whether people like the change, or whether they want to do it. I’m asking for permission to try something.

If there are individuals who won’t consent to try the change, the burden is on them to help me modify the change to make it safe for the organization.

Sometimes, after presenting a proposal, I will ask a group (or a set of breakout teams) to list out what surprises them, what puzzles them, what risks they see, and what dependencies there are with the change. Offering some time to react and consider in small groups tempers the knee-jerk change aversion reflex. And there are almost always at least some small but meaningful adjustments that can make the change work better.

Think about the last time you wanted to make a process change for your department or organization. Did you spring it on the team with little notice? Did they have time to react? To prepare? Was it really as urgent as you thought it was?

If, instead, you choose to pause, think about your change cadence, your communication plan, and asking for consent, you may find that you get much deeper buy-in and more enthusiastic implementation of your changes.

Alex Pukinskis

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:

• Formt kleine Teams
• Wendet die richtige Mischung persönlicher Bindung und Team-Förderung an
• Sorgt für Inspiration im Team durch den Product Owner

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.

Related posts:

1. 10 Things about ScrumMasters
2. Führung in Scrum | Manager | Teil 4
3. Der ScrumMaster – Wirklich ein Weichei?

For years I’ve assumed that when Agile principles succeeded at a team level they would naturally spread to other teams in the organisation until eventually the whole organisation would embrace openness and failing fast. I’ve naively been surprised when this doesn’t happen. I’ve probably been a bit slow, or perhaps my bias for optimism has lead me to ignore the signs, but today the penny dropped. The reason bottom-up Agile doesn’t spread beyond the team is a consequence of the blame and punish culture that dominates traditional hierarchical management.

Failing early and openness are at the foundation of agility. Our practices make problems visible as early as possible so that we can fix them whilst the cost of doing so is relatively small. We test our code to reveal its problems before it’s written. We pair program so that we are more likely to spot problems as soon as they appear. We integrate our code as soon as it is committed. We deliver our code to customers early before we waste time doing the wrong thing. Most importantly we stick our problems on a big board visible to everyone often marked with a fat red post-it that nobody can ignore. We try to work as close to reality as we can.

Traditional Management is not so accepting of failure whether it’s early or late. Culture dictates that failure is the bedfellow of blame and embarrassment, and defensive reactions to embarrassment are typically violent . Problems are best swept under the carpet if internal, or attributed to somebody else if external. Failure that cannot be attributed is just plain bad luck. It’s safest and most advantageous for a managers career progression to keep his head firmly buried in the underfloor network conduits.

But here’s the rub, it’s not enough for managers just to hide their own problems. Hierarchy dictates that, as a manager, you are also responsible for all your team’s failures. It’s fine if they keep it to themselves, but if they start sharing their problems with other departments it’s going to make you look incompetent. The safest course of action is to ensure that there are no channels of communication to other departments (except via you) by creating a Silo and sticking a fat stop sign in front of any inter-departmental collaboration. It also pays to keep teams so busy that they don’t have time to explore how others can help with their problems or how they can help others.

To an Agile team a silo is an impediment that restricts cross-functional collaboration. To a traditional manager a Silo is a necessity for survival and the tighter it is the safer he feels. If this type of culture exists in an organisation the change seems unlikely to happen without a credible top-down effort to change the mindset that creates this culture. The cause of the fear of failure is blame. Blame comes from fear of punishment. We must replace blame with empathy. What would happen if the CEO of your organisation abolished blame and started encouraging failure to be treated in a more healthy way? What would happen if you asked her to?

We can’t go on living this way

Collaboration Games from the Growing Agile Toolbox is a free e-book written by Karen Greaves and Samantha Laing that proposes ten games to build collaboration in Agile teams. The 10 games are Broken Skype, Crazy Chat, Collaborative Origami, Listening Game, Movers & Shapers, Human Knot, 123 go, Columbian Hypnotist, Non Musical Chairs, Yes and, Magic Stick, Singing Clapping Numbers. For each game, the book explains what you can learn, what you need to play the game, how to play it and how the authors have used the game.Book reference: https://leanpub.com/CollaborationGamesToolbox Growing Agile ...

Was macht ein Teamleiter in Scrum? Was wird aus einem Projektleiter? Wie verhalten sich diese Rollen zu den Rollen in Scrum? Früher oder später tauchen in jeder größer angelegten Scrum-Implementierung diese Fragen auf. In den meisten Fällen wird die Rollenduplizität eine ganze Weile erhalten: Der Teamleiter ist dann beispielsweise Product Owner. Und der Projektleiter macht (mehr oder weniger nebenbei) den ScrumMaster. Und umgekehrt. Oder es gibt eine Rollenparallelität: ScrumMaster und Product Owner führen und entwickeln nach Scrum, während Projektleiter und Teamleiter klassisches Projektmanagement machen (oftmals sogar für das gleiche Projekt). Dass das auf Dauer nicht optimal ist, sollte keine Überraschung sein. Umso dringender stellt sich die Frage nach einer besseren Rollenverteilung.

Scrum ist keine Rollenevolution

Die Antwort dazu muss zwangsläufig ernüchternd ausfallen. Scrum wurde nicht erfunden, um das klassischen Projektmanagement weiter zu entwickeln. Scrum versucht daher erst gar nicht, eine Kontinuität oder eine Evolution herzustellen. Von Anfang an ist Scrum als Alternative angetreten, die nicht ein UND oder ein ZUDEM, sondern ein ODER im Angebot hat. Folglich gibt es in Scrum keine natürlichen Zuordnungsmöglichkeiten: Wer behauptet, dass ein Projektleiter “am ehesten” Product Owner wird, der unterschätzt die Radikalität der Scrum-Rollen.

Manche pendeln dann direkt ins andere Extrem und behaupten, für die klassischen Rollen gäbe es in Scrum gar keine Verwendung mehr. Wer so denkt, der ist noch nicht in der Wirklichkeit angekommen: In jedem Projekt geht es doch darum, Scrum unter den jeweils aktuellen Bedingungen zu implementieren. Und diese Bedingungen sind nur im Lehrbuch die einer grünen Wiese.

EIn Beispiel

Ich habe vor kurzem mit einem Projektleiter zusammengearbeitet, der Scrum für sein Projekt einführte. Nach einigen Sprints übernahm er die Rolle des ScrumMasters. Der Product Owner kam wiederum aus dem Fachbereich. Beide Scrum-Rollen haben nie ganz richtig gesessen: Der Product Owner hatte zu wenig Produktkenntnis und konnte daher mit dem Team nicht auf der Ebene eines zweiwöchigen Sprints planen. Er hat sich mit der Zeit in die Rolle des Kunden zurückgezogen – und fühlt sich nun dort besser aufgehoben. Der ScrumMaster war anfangs sehr ungeduldig und versuchte in seiner Projektleiterrolle zunächst, das Team mit Vorschriften und Arbeitszuweisungen zu führen.

Wir haben solche Momente kritisch reflektiert. Über die Sprints gelang es dem ScrumMaster, in die Rolle des Teamsponsors zu wechseln, der nicht nur das Team beschützt (das tat er schon immer), sondern auch Freiräume ermöglicht und Entscheidungen respektiert. Als klar wurde, dass der Product Owner seine Rolle nicht ausüben konnte, spielte der ScrumMaster mit dem Gedanken, dorthin zu wechseln. Wir empfahlen ihm, ScrumMaster zu bleiben. Er hatte genügend Produktkenntnisse und wäre vermutlich ein guter Product Owner geworden. Aber sein Interesse um das Wohl und Gedeihen des Teams war bei ihm so stark ausgeprägt, dass er letztendlich selber entschied, ScrumMaster zu bleiben.

Wichtig: Perspektiven

Das oben genannte Fallbeispiel soll eines zeigen: Ob jemand für eine Scrum-Rolle geeignet ist, hängt einerseits davon ab, wie klassische Rollen gelebt werden. Ein Fachbereich mit wenig Produktkenntnis wird es schwer haben, in die Rolle des Product Owners zu kommen (was nicht heißen muss, dass man ihn nicht dorthin entwickeln kann). Und ein Projektleiter mit viel besserer Produktkenntnis ist nicht unbedingt der bessere Product Owner – entscheidend sind dann nämlich auch die Persönlichkeit und die sonstigen Fähigkeiten der einzelnen Person.

Zu Beginn spricht auch in der Tat nichts dagegen, Rollenfragen – wie hier beschrieben – pragmatisch zu lösen.  Entscheidet sich das Unternehmen jedoch, Scrum auszurollen, dann brauchen wir bessere Antworten auf die Rollenfrage. Denn die Mitarbeiter werden sich in jedem Fall die Frage stellen, wie es mit ihnen weitergeht und manche werden sich in Scrum nicht wiederfinden. Aber auch ein ScrumMaster braucht eine Perspektive: Was bedeutet meine Rolle im Unternehmen, welche Entwicklungs- und Aufstiegsmöglichkeiten habe ich? Auch formelle Strukturen wie Rollenbeschreibungen, Einstufungen und Karrierepfade sind wichtig für die Mitarbeiter, bevor sie sich langfristig für eine solche Rolle entscheiden.

Sind die Perspektiven erstmal da, kann man mit den Mitarbeitern gemeinsam herausfinden, wo sie sich am ehesten sehen und ihnen auch klar machen, wo die Organisation sie am ehesten sieht. Scrum hat enormes Begeisterungspotenzial, weil es für viele Unternehmen einen frischen, unverkrampften und oftmals subversiven Neuanfang bedeutet. Gerade in größeren Unternehmen kann Karriere jedoch nur über formale Pfade gemacht werden. Damit die Begeisterung für Scrum anhält und auch über die Pioniere hinaus wirken kann, braucht es die Anerkennung und Ausgestaltung der Scrum-Rollen im Unternehmen.

Danke an Kristina Klessmann, die mich beim Verfassen dieses Artikels unterstützt hat!

Related posts:

1. 3 + 3 Rollen in Scrum Oder doch nur 3 +1?
2. Die drei weiteren Rollen in Scrum
3. ScrumMaster can not be the Product Owner | 10 reasons

While a successful Agile retrospective implies an open discussion in a team, many would agree that it's not always easy to have everyone in a team actively involved in an exchange of opinions. There can be a number of reasons why people feel retic...

My blog on Patterns of Agile Adoption: Team Focus Sets Us Up To Fail has created a bit of a stir on Twitter.  Thought I'd put together this table of Agile anti-patterns, their underlying causes and their solutions! What's important to remember is that every solution to each of these problems was postulated with Lean-Thinking.  Makes me believe that other problems, previously unencountered, might...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

I've been re-organizing the webinars on our website to make them more accessible (we have almost 100 of them).   I came across some old technical ones that are still relevant. They have difference access requirements as noted.  'guest' means anyone can access them and 'registered' means you must register. Here they are: Design Patterns: Advice from the Gang of Four This presentation investigates...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

There has been much debate about whether a team, at the start of a sprint, commits to a sprint goal, or merely forecasts what they currently understand will be completed by the end of a sprint.

It's both.  In sprint planning, the team creates an initial sprint backlog, which is a forecast of the tasks, or bits of work, that they feel represents the best path to achieving the sprint goal.  The form this takes is up to them (hours, days, thrown chicken bone patterns, etc).  They will refine how they create the backlog over time to improve the value of their forecasts.

The commitment part is more about a commitment to do their best to achieve the goal while maintaining quality.

The problem is that very often this commitment comes into conflict with the initial forecast.  For example, one time I estimated it would take two days to implement drift-racing physics (with a handbrake control) into our vehicle dynamics model.  I was able to do this, but it took another week to make it "fun", much of that time sitting next to a designer.  This couldn't have been predicted and we could have stopped after two days and said "sprint goal achieved", but was it really?

At which point do we say, "it's good enough, time to move on"?  That can't come from sprint planning.  It has to come from the daily conversation with the team (including the product owner).  Sometimes this results in the forecast growing and the team delivering a part of the goal that meets the quality bar.

This definition can scare managers that first hear about it and it's where they and teams struggle at first.  This often comes from a culture that isn't prepared to trust developers to judge or achieve quality on their own and the inexperience of teams to be given this control.  So the forecast becomes the commitment and the teams focus on making the hours look good, rather than the game.   It takes time to establish the balance.

A commitment to quality at the expense of the forecast is the correct choice.  It's very easy to cut quality to look good on paper, but it will bite you in the tail end.  This doesn't mean we pursue the highest possible quality at all costs.  That quality has to be arbitrated by execution and measurement.  It has to be balanced with the needs of the customer.  It shouldn't rule at all cost.   My favorite example of "quality gone wild" comes from another driving game.  As the prototypical product owner, I encountered an artist modeling window flower boxes throughout the city players were to race in.  These required thousands of polygons and detailed textures to render.   The flower boxes were beautiful and added much color, but based on the cost of creating and rendering them, they couldn't be justified, especially from the point of view of the player, who would be passing them at over 90 MPH.

So, we killed the window boxes, but it was a good lesson on our team's path to learn how to build "95 MPH art.

Bloggers note: I feel compelled to mention that this blog is not at all an attack on Scrum.  At Net Objectives, Scrum, within the context of Lean-flow, is a popular method we espouse along with Kanban.  This is an attack against the improper use of Scrum.  In the same way I love my Lexus but don't drive it into the Puget Sound or off-road.  Not because I don't like it, but because that's not what...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Friday the 12th of April, I’m giving a talk at “Agile Project Management in Action!” seminar, organized by PMI-Rome. Besides me also participate great speakers from inspearit Italy, HP, TenStep and Ericsson; the seminar will be hosted by: Università degli Studi Roma Tre,  Facoltà di Economia “Federico Caffè”,  Via Silvio D’amico, 77 Roma.     This is [...]

Friday the 12th of April, I’m giving a talk at “Agile Project Management in Action!” seminar, organized by PMI-Rome. Besides me also participate great speakers from inspearit Italy, HP, TenStep and Ericsson; the seminar will be hosted by: Università degli Studi Roma Tre,  Facoltà di Economia “Federico Caffè”,  Via Silvio D’amico, 77 Roma.     This is [...]

We had the pleasure of hosting Bob Galen this week at DFW Scrum. His topic was centered around the practices of a great Product Owner. I tried to take some notes and so I am pasting those here in this … Continue reading →

Let’s say you are ready to start sprinting using SCRUM: have you already created a first raw version of the product backlog? Well, why not using the story mapping technique?! When a ProductOwner find herself, for the first time, involved in the product backlog creation, it’s usually a real drama. This because she has to [...]

I have two courses coming up in Montreal:

April 11-12 : Certified Scrum Product Owner for Video Game Development course.  Details here.

May 16-17 : Certified ScrumMaster for Video Game Development course.  Details here.

These courses focus on the two Scrum roles, which help guide creative teams to apply Scrum in video game development projects.  Come discuss the application of Scrum for video games with the certified trainer who has 20 years of video game development experience, who introduced the industry to Scrum in 2003 and wrote the book.

The course is open to people who develop any type of product, but benefits those who work on products that have a more creative dimension.

We are hosting a free live agile webinar (Agile and Scrum Q&A Webinar) on March 28, 2013 at 11:00 AM PDT that is going to consist of questions sent in from the agile community. The content of what we talk about is entirely up to you.

We need your help to make this webinar informative and awesome. Please submit an interesting question or problem you are currently facing in your organization that you would like covered during the webinar. If there is time at the end, we will answer follow up questions.

If your question or problem is used during the webinar, we will send you a $25 amazon gift card. Please send your questions to team@axosoft.com.

Register at: http://www.ontimenow.com/training/scrum-webinar

If you can’t make it on that day, register anyways and we will send you the video recording of the full webinar.

I had the good fortune to attend the Mass Technology Leadership Council (masstlc.org) Annual Meeting in Boston this week where Robert Kraft was the featured speaker. Mr Kraft turned out to be a great storyteller.  In addition to owning the New England Patriots Kraft is the CEO of The Kraft Group, which is an international paper business. He has years of pure business experience so his stories were full of interesting business-relevant anecdotes. But even when he was talking about running the New England Patriots the lessons were business-oriented and you could see that he has a strong sense of purpose and passion that he has instilled in all of his organizations.

Early into his Q&A session Mr. Kraft stated "Life is about execution, not just dreaming." 

This is true in both sports and business.  If you don't execute in sports, you lose the game. Don't execute in the playoffs? Your season is over. If you don't execute in business, you lose the deal.  Continue to not execute, you will eventually go out of business.

Though I could have listened to Kraft talk for days about the New England Patriots (his Vladimir Putin/Superbowl ring story was incredible), the business-oriented nuggets in Kraft's speech were even more interesting.  If you get a chance to hear Kraft talk, do it. He was interesting, often funny and very inspiring. 

"Life is about execution, not just dreaming"  - Robert Kraft Owner, New England Patriots CEO, The Kraft Group