I’ve made great progress on Day 1, and I wasn’t even in the office all day!

You can see I’ve added more todos, at the bottom of my queue. I discovered two urgent todo’s. I had a call-back, to reschedule a doctor’s appt this week to next week, and to vote today. (We have a primary election today for a special senate election in June.)

And, since I’m cheating on how to do a real personal kanban, I thought I would at least describe for you how to do real personal kanban over at Personal Kanban for Your Job Hunt.

You can see now there is a huge drawback to my list. I will have to rewrite my list, instead of just moving the stickies off. This is why in personal kanban, the right way is to not have a list. If you move the stickies, you don’t get this list nonsense, with lines crossed through.

Well, most people don’t have vertigo, either. So, tough. Okay, enough being meta today. On to the real work of the day.

If you missed part 1, here is the link: Personal Kanban and Iterations, Day 1.

We are excited to announce a new major spring 2013 release!

TargetProcess 2.24.0 includes quite a few small and big improvements. Check what we’ve done to help you work better, faster, more comfortably.

10x faster search

We’re close to less than 1 sec search time, but this new search is not only fast. The search results look nicer now, and you can open them both in new tabs and as a pop-up.

Read more  about the new fast search in our Help portal.

Relations and Relations Network Diagram

Quite often one piece of work is “informally” tied to another piece of work. For example, the core team is working on an API, and the other teams are dependent on the core team’s progress. Keeping such informal dependencies in your head can be tiresome…

Starting from 2.24 you can track such informal dependencies right in TargetProcess as Relations!

Relations Network Diagram represents a network of related entities:

Relations can be created for any entity (i.e., user story, task, bug, etc.), and they can be of great help when planning or prioritizing. Be sure to check the article about Relations in TargetProcess Help Portal. It has more screens, and explains how Relations are helpful in planning and progress tracking.

New Visual Reports:Process Control Chart and Lead and Cycle Time Distribution Report

The Process Control Chart shows cycle time distribution for completed entities (user stories, features, bugs, tasks, requests) within a certain time frame. Check the screen below. If you see user stories between the warning limit and the control limit lines, this is suspicious. If a user story goes beyond the control limit line, this is really a bad thing, and you should investigate why it took so many days to complete. These limits are calculated statistically; they depend on the overall distribution of stories in the chart.

You can find a comprehensive description of the Process Control Chart here. It includes more screenshots and some examples on how the chart can be used.

Note the new powerful filters. You’ll see more of them later. They can now be used to filter out the entities in the Relations Network Diagram and in the new visual reports.

While the Process Control Chart quickly spots the entities that took too long to get done, the Lead and Cycle Time Distribution report helps you make realistic forecasts. You can filter out any entities, just as in the Process Control Chart:

Read more about Lead and Cycle Time Distribution Chart.

Improved Views

There’s a bunch of nice improvements to the views: quick convert (all the properties are kept intact for the converted entities), assign 2+ people, switch project quickly in the Info box for an assignment, auto-convert URLs to clickable links.

Besides, starting from TargetProcess 2.24 you can add up to 60 custom fields to any entity.

New History REST API

Check out the  new History API in TargetProcess REST API.
The new API will track state changes for Bugs, Feature, Impediments, Requests, Tasks and User Stories.
More info on the new History API in TargetProcess Help Portal

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

Related posts:

1. Education Paradigms & Softskills
2. People needs to “hear and view” colleagues.
3. People needs to "hear and view" colleagues.

Thinking on Jay's suggestion at his presentation (DFW Scrum, AgileFest!) to create an Agile Playbook; I'm wondering why scrum masters don't do this more often.  Well, guess what?  It's very good advice.  The authors Chip and Dan Heath give this very advice in their new book Decisive: How to Make Better Choices in Life and Work.

Why do teams continually over estimate the number of stories they can complete (potentially shippable tested working software) in a sprint?  There are many reasons.  But what play would you run next sprint if you were the team?

If your team already has an agile mindset, then the natural play will be to reduce the amount of work they are bringing into the sprint.  The result of this play is to return the team to a consistant delivery of value.  Resulting in a predictable velocity.  This predictable velocity will be used for projecting the release scope or date.

The problem for many teams is they do not posses an agile mindset.  Therefore this play appears counterintuitive to them.  So of all the plays they could run, which will move them toward an agile understanding and give them feedback?

Which play do you run in this situation?

I use a form of personal kanban inside one-week iterations to finish my work and notice what I am not doing. I do this to maintain a cadence of blogging and to finish work. Did you notice that word, finish?

Sidebar: For those of you who don’t know what “kanban” is, it literally means “card.” It’s been used in manufacturing for years as a pull system for work. I have an example for what a kanban system might look like for teams in Agile Lifecycles for Geographically Distributed Teams, Part 3. I just realized I don’t have a picture of a personal kanban on Hiring Technical People. I will have to fix that.

I’m human, the same as you. I get bogged down. I sometimes get freaked out by the amount of work I have to complete. And, this week and next, as I complete my preparations for my London workshops and Let’s Test, I have more than I originally expected to do.

Why? Before PSL, several local potential clients called and wanted meetings. Meetings! Not phone calls, but in-person meetings.

The problem with in-person meetings is that they take longer. They aren’t one hour long. They are close to two hours long. I have to leave enough time to get there, have the meeting and get back. But, these are very interesting potential clients, so I took the meetings.

The result? I am not where I want to be with respect to my deliverables. So I will be blogging my personal kanban this week, so you can see what I do to finish my work.

Now, you can see from my picture, I don’t always do personal kanban “right.” I don’t have stickies. I have a list. That’s wrong. You’re supposed to do queues. Well, I don’t. This is my kanban. I can do anything I want with it.

Why don’t I use stickies? Because I don’t want to get up and move a sticky on a board. I get too dizzy. My desk is a disaster, so I don’t use a kanban notebook. it would get buried And, I don’t believe in tools. (Sorry, tool vendors.) I like paper and pen. I get total transparency this way. It’s easy for me to move things around.

I do schedule my longer-term article commitments to other people in the reminders tool on my Mac, so I don’t forget things.

I have a backlog in rough order of priority. Well, sort of. I have a ton of things to do before Wednesday, 5/1. Yes, everything down to “SQGNE presentation by 5/1″ is supposed to be done before 5/1. I can pick anything I want off that backlog and get it to done before 5/1.

Note that I have first drafts specified for the coaching workshop and the PM workshops. I have draft zeros done already. It’s time to finish the first drafts, and put them aside for another day or so. I already have draft one of the Sweden hiring workshop, which needs finishing, which is why it’s farther down on the list.

If people call and need something that does not go on the backlog, I have an urgent queue on the right side of the page. We’ll see how the week goes.

Remember, I’m only one person, so my WIP limit is one, which is why I didn’t even bother with a “Doing” column. I’m not going to have a PEN column this week. If I call anyone this week, it has to be after I get my todos done for my trip. I’m not taking interruptions. I have way too much work to do.

Oh, and I’m still working out at the gym, and sleeping my regular hours and eating properly. In order to accomplish everything I need to do, I have to take care of myself and maintain and sustainable pace.

Let me know if this is interesting to you. Yes, this blog post counts as my “MPD blog” entry.

The Definition of Done is an agreement between the Scrum team and the product owner on a minimum quality barrier for the product that’s being built. Establishing a minimum quality barrier has much wider implications than just better quality product, although that is one outcome of having a Definition of Done. This article is about the impact of a definition of done on the types of contract that Agile teams work with. Author: Kane Mar, Scrum Coach, http://scrumology.com What is a Definition of Done? At its most conceptual level the Definition of ...

Continuing with the  100 Things You Must Know to Be Effective In Software Development. One of the big banes and puzzles in Agile has been how to coordinate teams.  Scrum of scrums is still being espoused even though its track record is worse than abysmal.  Much of the reason for the insistence on a team of teams coordination model is due to: the lack of understanding the importance of a holistic...

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

Eines der faszinierendsten Elemente von Scrum als Modell ist die Tatsache, dass hier neue, innovative Rollen im beruflichen Kontext kreiert werden und klassischen Rollen prägnantere Funktionen (z.B. dem Manager) zugeordnet sind. Die Funktionen von ScrumMaster und Product Owner sind in der Projektwelt ohne Beispiel. Daher ist das  Verständnis über ihre Aufgaben und Instrumente mitunter noch diffus und schwer einzuordnen. Was genau sind ihre Wirkungsfelder, was sind die dazugehörigen Kompetenzen, welche Methoden und Techniken stehen zur Verfügung, was sind die Einflussbereiche, was genau ihre Aufgaben und Funktionen, etc.? Und wie grenzen sie sich zu anderen Rollen wie Team- oder Projektleiter ab?

Rollen müssen sich legitimieren

In sozialen Systemen sind Rollen zentrale Elemente, denen spezifische Aufgaben und Verantwortungsbereiche zugeordnet sind. Mit ihrem Handeln sollen sie zum Erfolg des Systems beitragen, sie haben eine definierte Legitimation, eine von außen vorgegebene Struktur und sind mit spezifischen Erwartungen an den Rollenträger in punkto Verhalten, Einstellungen, Werte, Know-how usw. verbunden. Es gibt aber immer auch einen eigenen Gestaltungsraum, in dem der Rollenträger seine Aufgaben individuell interpretieren und ausüben kann. in der Arbeitswelt gibt es relativ einfache, unkomplizierte Rollen, aber immer mehr solche, die hoch komplex und herausfordernd sind. Zu den letzteren gehören ganz sicher Rollen wie jene des ScrumMasters und des Product Owners. Neue Rollen brauchen in der Regel Zeit, um sich etablieren zu können und akzeptiert zu werden. Ihr Sinn und Nutzen für das System zeigt sich erst im Laufe der Zeit. Der Rollenträger hat darauf großen Einfluss: Schließlich trägt er mit seinem kompetenten Handeln dazu bei, wie seine Rolle im beruflichen Umfeld wahrgenommen und eingeordnet wird. Dafür braucht man bestimmte Fähigkeiten und Fertigkeiten, aber auch ein entsprechendes Handwerkszeug. Genauso muss die neue Rolle in ihrem Umfeld, besonders an den Schnittstellen, auf Offenheit und Verständnis stoßen, damit der Nutzen tatsächlich wahrgenommen werden kann. Was dabei auf jeden Fall notwendig ist, ist die eindeutige Legitimation durch das Management.

In der Scrum Praxis machen viele die Erfahrung, dass eine Grundausbildung zum ScrumMaster oder Product Owner für die ganze Komplexität dieser Aufgaben nicht ausreicht. Im Alltag wird schnell deutlich, wie zentral der sorgsame Umgang mit Menschen ist. Es müssen vielfältige Kommunikationsprozesse gesteuert werden, in der Veränderungsdynamik muss die laterale Führungskraft die Ruhe bewahren, manchmal auf Konfrontationskurs mit dem Management gehen usw. usw. Kurzgesagt lautet das, was diese Rollen so besonders macht: Change, Change und nochmal Change!

Neue Rollen sind Stützen der Veränderung

Wer an Change denkt, denkt meist zuerst an das Neugestalten von Strukturen und Prozessen im Unternehmen. Als prozesshafte Struktur tut das Scrum natürlich. Ein ScrumMaster denkt aber weit darüber hinaus: Er denkt an die betroffenen Menschen und an die tradierte Unternehmenskultur. Ihm ist bewusst, dass er die Menschen einbinden muss, wenn die Kultur des Systems neu gestaltet werden soll, denn die Menschen sind die Kultur. Sowohl ScrumMaster als auch Product Owner (ggf. auch Team- oder Projektleiter) werden zu wertvollen Stützen eines agilen Unternehmens, wenn sie in ihrem Change-Repertoire sattelfest sind und es zum richtigen Zeitpunkt einsetzen. Damit helfen sie auch dem Management, Veränderungsprozesse über Scrum hinaus anzustoßen. Natürlich gibt es Schattenseiten, wenn diese Rollen schlecht ausgefüllt werden: Frustration, Demotivation, Resignation bei den betroffenen Mitarbeitern. So werden nicht selten die wertvollsten Mitarbeiter „verbrannt“.

Der Scrum ChangeManager als multifunktionale Rolle

 

Was sind die Lernfelder für diese multifunktionalen Rollen? Laterales Führungswissen, die Kompetenz der professionellen Kommunikation, Umgang mit Konflikten, Moderation und Workshopgestaltung, die Kunst des Coachings, systemisches Know-how zum Change Management und zur Teamentwicklung haben zentrale Bedeutung. Ebenso muss die eigene Persönlichkeit durch gezieltes Selbstmanagement weiterentwickelt werden. Für einen solchen „Knochenjob“, bei dem manchmal der Widerstand um die Ohren pfeift,  braucht man Selbstsicherheit und Standing, Klarheit über die eigenen Ziele und Ressourcen, Mut zu Innovation und Kreativität und den bewussten Umgang mit Herausforderungen und Stress. Gerade neue, noch nicht umfassend etablierte Rollen brauchen Zeit um zu lernen, Erfahrungen zu sammeln und Feedback zu bekommen, um sich ihren Status zu erarbeiten.

Zukünftige Rollenträger, Management und Personalentwicklung tun also gut daran, sich schon zu Beginn einer Scrum-Implementierung um die Ausstattung mit den nötigen Fertigkeiten zu kümmern. Der zertifizierte Scrum ChangeManger als Vertiefungs- und Erweiterungskonzept ist ein sinnvoller Weg dazu. Er bleibt nicht beim Verändern vom Vorgehensweisen stehen, sondern sieht das Ganze, die Menschen in einer neuen Situation. Und daher verändert und entwickelt er zu allererst: sich selbst.

Tipp

Wie fülle ich meine Rolle erfolgreich aus? Mit unseren Scrum Supplements stärken Sie Ihr souveränes Auftreten als Change Agent: Konflikte regeln, Impediments lösen, Teams entwickeln, Workshops gestalten, Gespräche zielorientiert führen – all das mit der richtigen Dosis Selbstbewusstsein.

Related posts:

1. Der klassische Projektmanager in Scrum
2. Scrum – Erfolgsfaktor Personalmanagement
3. Die drei weiteren Rollen in Scrum

I would like to pose the question, Why not merge roles in Scrum? I'll begin not by talking about Scrum specifically, but by taking a different approach and using an example. The world of colors We recognize three primary colors: red, blue, and...

In business, we’re often asked for estimates with too little context to understand the request. When that happens, we’re likely to expect the worst–that our estimate will be treated as a “guarantee not to exceed” and we’ll likely be in trouble at some time in the future. Of course we think that; we’ve been burned too many times in the past. Our fear of the consequences will encourage us to spend far too much time and effort trying to get the estimate “right” so we won’t be blamed.

If an estimate is really an estimate, then we know that it’s “wrong” in the sense that the subsequent actual reality is unlikely to equal it. The estimate is a guess, perhaps an educated guess, predicting the future. Predictions are hard, especially about the future.

Given these problems with estimates, why do we bother to make them at all?

We do so because we have a decision to make, and looking into the future helps us make that decision.

If we’re trying to decide which of two development efforts to pursue next, we’ll want to estimate the value and cost of each of them. Since both value and cost depend on the amount of time we spend doing the work, we’ll want to estimate the time and effort required.

If we’re trying to decide whether a project is worth doing, we want to estimate whether the value is greater than the cost. We may not care what are the actual value and cost, just that it will be profitable.

If project A is clearly more valuable and less cost than project B, it’s clear which to work on, assuming it’s also clearly more valuable than it will cost. But what if it’s not so clear? If project A and B are estimated as about the same value and about the same cost, which would you choose? Unless you have some guideline other than the estimates, it doesn’t matter. If project A will provide value that’s only slightly more than the cost, then we shouldn’t do it at all.

These are just two simple examples. There are many different reasons that a business will want to make forward-looking estimates. There are some caveats with estimating, of course.

Remember that these are JUST ESTIMATES.

We should not trust our estimates too much. Estimates are not data. Even if we’ve done well at predicting the future in the past, we might get this one totally wrong. We should expect our estimates to be off a bit, one way or the other, from what reality shows later. So if our decision is a close call, we should consider what we’d do if we had no estimate, or if the estimate came out differently. Only when the estimate clearly favors one choice over another should we trust it. Even then, we should validate our decision with real data as we go along.

Estimate to an appropriate level of precision

Since we know that our estimates are not data about future events, we should consider the amount of precision we need to make our decision. There’s rarely a need to estimate project completion to the day, or project cost to the dollar. If we think a project is worthwhile if it costs $100,000 but not if it costs $200,000, then we don’t need to estimate with any more precision than to the nearest $50,000. Using greater precision than we need increases the cost of the estimate without increasing its value for helping us decide.

Using an appropriate level of precision will also help us remember that these are estimates, not trustworthy data. There’s also some evidence that precision interferes with moving toward our goals.

Continually check and refine your estimates.

Estimation should not be a phase, that you do once and then hold onto it. Estimates give you a model to judge your progress against your expectations. It allows us to track our investment toward our goal. The actual progress acts as a check on our estimate, potentially giving us early warning of future disappointment–early enough to do something about it.

In the early 2000s, it was often said that “you don’t need to do design in Agile software development.” A lot of people were very dismissive of Agile software development because of comments like that. In truth, you do need to do design. You just don’t need to do it all up front. You need to do enough to see where you’re headed, and continue to question it and refine it as you learn more about what you need from the design. The same applies to estimation. We project into the future given what we know, track our progress, and make new projections as we learn more.

Don’t make this a big job, though. They’re still “just estimates.” Do a little at a time, but look at them frequently and regularly. Cross-check with other ways of estimating. Estimates are tentative; don’t put your full weight on them.

When they’re not agreeing with the subsequent reality, don’t blame the reality. Estimates give you a map; they’re not the territory. When these disagree, trust the reality. Does our decision still make sense? Would we decide differently, given what we know now? Are there possibilities that we didn’t consider when we made our first estimates? Should we change our decision, given where we are and what we know?

The estimates are not the goal, they’re just a tool. When we find they’re “wrong,” there’s no sense blaming the estimates or those who made them. They’re now a historical record of our previous thoughts and knowledge. Instead, use them as they’re meant to be used–as a tool for making decisions. And make new decisions.

Continuing with the  100 Things You Must Know to Be Effective In Software Development. For the last several years I have been claiming that the Agile Community has been a bit myopic on the team.  I'm not questioning whether the team was a good place to start Agile - it's what we did.  It was certainly the easiest.  It also didn't require significant changes to corporate management, strategic...

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

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 1: THE SECRET CLUB

“Membership in the secret club carries with it the need to behave in certain ways that may not be your personal inclination. My advice would be to get some experience to get a clear-eyed understanding of what it looks like because it’s not a one size fits all.”

Running time 32:37

Have you made it in the secret club? What has your experience been like? If you opted out of the secret club, what prompted you to turn away and go in a different direction?

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – How do you get into the secret club?
7:37 – The secret club ideology may impact or alter one’s view of the meaning of leadership.
11:17 – What does it mean to be part of the secret club? Being aware of the demands and how will it impact your professional and personal life.
15:01 – Secret clubs are not one size fits all – understanding the differences and knowing what to expect.
20:17 – Leadership at the top – It’s about willing to work hard and building field experience.
25: 12 – The effect of generational differences on organizational leadership.
27:55 – Skewed perception of what it means to be at the top.

Photo Credit: ul_Marga via Compfight cc

Platons Zitat “Pánta chorei kaì oudèn ménei” ist die knappste Formulierung der Flusslehre Heraklits, die besagt: Alles fließt und nichts bleibt. Es gibt nur ein ewiges Werden und Wandeln. Sie ist eine Metapher für die Prozessualität der Welt. Das Sein ist das Werden des Ganzen. Das Sein ist demnach nicht statisch, sondern als ewiger Wandel dynamisch zu erfassen. (Wikipedia)

Das Leben ist Wandel, das wussten also schon die alten Griechen. Und wir sind im Flow, hier und jetzt, am besten. So besagt es die Theorie. Wir sind in unserer Energie und erschöpfen uns nicht.

Doch die Realität sieht meistens anders, zumindest meine sah anders aus.

Stunden um Stunden habe ich mit Budget-, Projekt- und Personalplanungen verbracht. Für nächste Woche, für nächsten Monat  – was ja noch gerade so geht. Fürs nächste Jahr – was eigentlich gar nicht geht. In einem Projektlaufzettel (ein hochoffizielles Dokument) habe ich tatsächlich den Begriff Glaskugelschätzung gefunden! Ich denke, da erübrigt sich jeder Kommentar. Und da Leben das ist, was geschieht, während man es plant, war ein Großteil der Planung innerhalb kürzester Zeit obsolet. Projekte kamen gar nicht, dafür fielen ganz neue vom Himmel, Budgets wurden gekürzt, Mitarbeiter kamen und gingen. Diese Art der Planung war für mich in höchstem Maße Zeitverschwendung, Geldverschwendung, sinnlos. Es war eine Verwaltung von Zukunftängsten, die nur dazu diente, eine gefühlte Sicherheit herzustellen, mühselig und erschöpfend. Geht es euch auch so wie mir damals?

Und dann kam Scrum.

Keine tapetenrollenlangen MS Projektpläne, die mich schon allein optisch überforderten. Stattdessen eine Vision entwickeln. Alle Ideen, Stories, Anforderungen in einem Backlog sammeln und priorisieren, aber nur noch drei Sprints im Voraus planen. Wow, schon das allein war eine Erleichterung

Keine stundenlange Kapazitäten-Planung für die nächste Woche mit den Projektleitern, die am Ende der Woche doch nicht gemacht hatten, was sie geplant hatten und jeder hatte tausend gute Gründe dafür. Dafür im Sprint Planning zu Anfang des Sprints mit dem Product Owner und dem Team den Umfang des nächsten Sprints besprechen, sich gemeinsam auf ein Sprintziel comitten. Kontinuierliche Fortschrittskontrolle im Daily und mit Hilfe des Burn Down Charts. Jeden Tag sehen können, wo wir gerade stehen. Kontinuierliche Planung statt Glaskugelschätzung.

Keine Jour Fixes mehr, kein Status, nur noch die Review Meetings mit den Teams. Wenn ich wissen wollte, wie der tagesaktuelle Status war, musste ich mich nicht mehr durch 50-seitige Power-Point-Berichte graben (kein Scherz!) und diverse Jour fixe mit Projektleitern einstellen. Ich bin still ins Daily gegangen, einen Blick auf Task Board und Burn Down Chart werfen und ich wusste innerhalb von 15 Minuten, wo das Team, das Projekt stand. Das ist übrigens mein Geheimtipp fürs Management: Einfach mal still das Daily verfolgen! Besser und effektiver kann man nicht mitbekommen, was im Team läuft und wie die Stimmung im Team ist. 15 Minuten pro Team jeden Tag. Mehr braucht man nicht.

Das Leben und Arbeiten machte plötzlich wieder Spaß. Die Ausrichtung auf ein gemeinsamen Ziel setzt ungeahnte Energien frei und gibt der Arbeit Sinn. Meine Teams und ich konnten jetzt Visionen entwickeln  UND umsetzen. Ganz entspannt im Hier und Jetzt. Go with the (Scrum-) Flow!

Related posts:

1. Schätzen vs. Planen?
2. First things first
3. Ferien und Sprints

OK, I'm cheating a little on this one, but watch this 7 1/2 minute lightning webinar Why Seeing the Value Stream Is So Important  When one sees that our workflow does not match our management hierarchy, one can better understand: one of the main challenges to developing software why Scrum is a great way to avoid this challenge but how it doesn't work as well as the size of the organization...

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

Richard Hundhausen has put together a great list of funny Scrum/Agile related videos. Some of these are classics such as High Moon Studios: Portrait of Scrum and Adam Weisbart’s Shit Bad Scrum Masters say.

Be warned, not all of these are actually that funny. I’ve never found The Downfall of Agile Hitler to be funny, because the original film is harrowing and difficult to watch. I also find the Scrum Haka to be trite and unwatchable … this is what a real haka should look like.

So here’s the list and, once you’re done (in the words of Adam Weisbart), “Get back to work!”

I want to run an agile project http://www.youtube.com/watch?v=4u5N00ApR_k I want to run an agile project (part 2) http://www.youtube.com/watch?v=lAf3q13uUpE The Power of Scrum (Ian Sense Scrum Master) http://www.youtube.com/watch?v=P6v-I9VvTq4

The making-of http://www.youtube.com/watch?v=ncjdtqf1gSg Developer Abuse http://www.youtube.com/watch?v=LYlhCGng5Mk Spooning and pair programming http://www.youtube.com/watch?v=dYBjVTMUQY0 Improving Sprint Reviews (is that Jeroen?) http://www.youtube.com/watch?v=fpBQ5yxrR_c The Downfall of Agile Hitler http://www.youtube.com/watch?v=l1wKO3rID9g High moon studios: Portrait of Scrum http://www.youtube.com/watch?v=UT4giM9mxHk Shit Bad Scrum Masters Say http://www.youtube.com/watch?v=GGbsgs611MM The Scrum Haka (hideous) http://www.youtube.com/watch?v=Qvqq97unS2w Joe Justice Team WikiSpeed http://www.youtube.com/watch?v=x8jdx-lf2Dw Deathstar Project Deployment Meeting http://www.youtube.com/watch?v=2T5QNcb_Z8g Raking Leaves – A Scrum/Agile Approach http://www.youtube.com/watch?v=StBS-loIIz4 I Need Agile Methodology http://www.youtube.com/watch?v=nvks70PD0Rs

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!

Running continuously sprint retrospectives while keeping the Scrum team awareness during this activity is one of the biggest challenge for ScrumMasters. In this article, Marc Nazarian present an game called “Turn the tables” that should help the ScrumMaster to achieve this objective. This game is a simple exercise where team members write on red and green cards two things that went well during the sprint and two things that could be improved in just one or two words. The interesting part of the game is that these cards are then passed ...

How do you prioritize your features?  Is it a gut-feel kind of thing?  Is it based on who’s yelling the loudest?  Is it based on what drives your next big sale?  Do you do it collaboratively or alone?

In his book Principles of Product Development Flow, Don Reinertsen suggests using calculated economic models to decide what work to do first.  Specifically, he advocates an approach called Weighted Shortest-Job-First, or WSJF.  All other things being equal, the shortest job will deliver value soonest, so you should do that one first.  

But all other things are not equal - some projects reduce risk more than others, some enable other opportunities, and some are more important to your customers.   So you weight the scores - roughly, value over job size.

This approach is gaining popularity in part because the SAFe framework suggests you use it.  And it sounds great on paper.  But how does it work in the real world?

At Rally, we recently held a roadmap planning meeting with one of our product lines, and we tried a collaborative game to incorporate this economic technique into our planning session.  

We started by estimating relative job size.  Our group of 14 tech leads, product owners, and other leaders started with a bunch of stickies on a whiteboard representing value we wanted to deliver.   I asked the team to sort them by size - smallest items at the top of the board; largest at the top.  As they moved the items, they discussed each move.  People took turns, and asked clarifying questions.  

“Why do you think that one is so huge?” asked Greg, a product marketing director.  

“Because I have no idea what it means! It could be anything!” replied Ryan, a dev manager.   Together, they were able to clarify some details and get it sized, and we processed about 40 items in about 20 minutes.

As the movements slowed down, I stepped in and forced the stickies into 5 clusters.  I asked the team to correct my clustering if I had made mistakes, and they adjusted a few stickies.

We then translated them into rough cost.

I then asked the group about the smallest cluster.   “Do we think each one of these on its own could be completed by a team in significantly less than 3 months?”.  They said yes.  “How about the next group? Is that still less than 3 months?”  Yes.  “How about this next group?  Is it about 3 months, or is it more?”.  I did some simple math to figure a rough loaded cost for a team for a month, and used that to put rough dollar amounts on each size - $100k, $150k, $250k, $750, $1M+.

A couple of things about this:

1. You don’t have to be very accurate about this.  You just need a rough sense of relative size.
2. The dollar cost went up steeply for the larger items.  I wanted a dollar amount on the bigger items that would prompt fear, and then conversation about how it could be broken down.  Beyond 3 months, you have no idea how big these items really are.  But, if they’re valuable, you can break them down more.

Value Scoring

Once we had our jobs roughly sized, we used a Google spreadsheet to value score them. Dean Leffingwell and the SAFe folks recommend calculating relative scores for user value, time value, and risk/reduction opportunity enablement value for each item to get a good sense of cost of delay. But I had 14 people in the room and I figured across the group I could get similar results a quicker way.

I went with Johanna Rothman’s suggestion to let people distribute value points across all the items any way they wanted, and then explain their rationale.  

Here’s how it looked:

It’s not a ‘buy-a-feature’ activity.  Rather, each person got 10,000 points (enough to feel rich) to distribute however they wanted across all the items.  After 5 minutes, each person talked through their rationale.

This was the important part.

If Tom and Alan are using completely different rationales to prioritize, and then we just use a formula to rank our items, and that formula happens to put Alan’s favorites at the top of the list, Tom doesn’t feel heard.  The reality is that each person has a very good reason for the scores they offered.  The goal of this meeting is to have a really rich conversation about value.  I want to go beyond Reinertsen’s goal of getting our priorities right.

I want the whole team bought in to our decisions.  The conversation about the rationale helps us get there.

Then we sorted the list, highest value score first.  This was interesting - we saw a lot of obviously important items bubble to the top.  Some of them were very large.  We talked about how people felt about the results - what was missing that they felt should have been higher.  

The magical calculation

Then Michael, an internal coach, spoke up, and suggested we try a weighted-shortest-job-first score.  To do this, we divided our total value score by the cost (the value/cost column in the picture above).  A number of items that were small but valuable jumped higher up in our list.  This led to another valuable conversation

So we’re done, right?

Does the WSJF scoring solve all prioritization problems?  Do you work on items in exactly that order?  Not exactly.    We did another activity to lay out our work into our roadmap, and this led to further conversations about the capabilities of different teams, dependencies with other groups, and the like.  It’s not a perfect technique, but it was an incredibly valuable input for us.

For more on  managing a portfolio, tracking and prioritizing work according to its value, and effectively aligning business strategy with development work, join our Portfolio webinar series.

Alex Pukinskis

Unlängst schilderte mir ein guter Bekannter, ein Unternehmensberater, dass er eine Führungskraft zu unterschiedlichen Ausprägungen ihrer Kompetenz befragte. Er wollte mit der betreffenden Person gemeinsam Handlungsfelder identifizieren, in denen diese sich entwickeln könnte. Es kam allerdings heraus, dass die Führungskraft mit dem Stand ihrer Entwicklung vollends zufrieden war und dass aus ihrer Sicht derzeit kein wirklicher Handlungsbedarf bestand. Etwas irritiert erzählte mir der Bekannte, dass er sich über die vollkommen übersteigerte Selbsteinschätzung dieser Führungskraft ärgerte und er gar nicht verstehen könne, dass die Diskrepanz zwischen seiner Meinung und der der Führungskraft so groß war. Er begründete seinen Ärger mit den Worten: „Das ist so typisch. Sie (die Führungskraft) denkt tatsächlich, dass sie schon alles weiß. Es gäbe so viel zu verbessern. Ich habe die Arroganz und Ablehnung in ihrem Gesicht gesehen. Wie kann man nur so von sich überzeugt sein!“ Ich stutzte, sah meinen klagenden Bekannten mit einem Schmunzeln an und erwiderte: „Du hörst dich an wie Othello.“ Fragend sah er mich an: „Othello? Was hat der denn damit zu tun?“

Der Othello-Effekt

Othello, Feldherr in der Republik Venedig und mit der wunderschönen Desdemona verheiratet, wurde das Opfer einer Intrige. Ihm wurde der schreckliche Floh ins Ohr gesetzt, dass Desdemona eine Affäre mit seinem bestem Freund Cassio hätte. Der voreingenommene und rasend eifersüchtige Othello konfrontierte seine Ehefrau mit dieser Anschuldigung, forderte sie auf zu gestehen und beging dabei den Fehler, ihren unter Tränen vorgebrachten Unschuldsbeteuerungen keinen Glauben zu schenken. Rasend vor Eifersucht erwürgte er sie, nachdem er zuvor bereits ihren angeblichen Geliebten getötet hatte. Othello sah, dass Desdemona offensichtlich Angst hatte, als er sie zur Rede stellte. Als sie dann auch noch zu weinen begann, nachdem sie von Cassios gewaltsamen Tod durch die Hand ihres Mannes erfahren hatte, fühlte sich Othello zusätzlich bestätigt. Für die Tränen seiner Frau auf die Nachricht vom Tod ihres Geliebten und für die Angst in ihrem Gesicht konnte es nur eine Erklärung geben: Sie musste schuldig sein. Desdemonas Angst war für Othello ein Schuldbekenntnis des Ehebruchs, der ans Licht gekommen war.

 

Othello hatte Desdemona leider – wie sich später herausstellen sollte – zu Unrecht getötet und zwar ohne anderen Ursachen für die Angst und Pein seiner Ehefrau Raum zu geben: Dass nämlich Desdemonas Angst die Reaktion einer unschuldigen Frau sein könnte, die wusste, dass ihr von Eifersucht geblendeter Ehemann im Begriff war sie umzubringen. Und sie hatte ja keinerlei Möglichkeit mehr, ihre Unschuld zu beweisen, weil der Einzige, der es hätte bestätigen können, bereits tot war.

 

 

Emotion verrät uns nichts über ihren Ursprung

Emotionale Signale, wie z.B. Ärger, Überraschung oder in Othellos Fall Angst, verraten uns nie etwas über ihren Ursprung oder anders ausgedrückt (vgl. Ekman, 2011, S. 80ff):  Wenn ich das Was kenne, weiß ich noch lange nichts über das Warum. Wollen wir den Othello-Effekt vermeiden, müssen wir daher der Versuchung widerstehen, zu rasche und einseitige Schlüsse zu ziehen. Dies gelingt uns nur, wenn wir uns darum bemühen, neben der für uns offensichtlichsten, also der erstbesten Ursache für ein Gefühl, mindestens eine Erklärungsalternative zuzulassen.

 

Wenden wir uns mit dieser Erkenntnis erneut meinem Bekannten zu. Die Führungskraft reagierte auf sein Weiterentwicklungsangebot mit arroganter Ablehnung. Die offensichtlichste Ursache lag für meinen Bekannten auf der Hand: Die Führungskraft erkannte keinen Handlungsbedarf für sich. Diese ablehnende Haltung wurde durch die Erwartungshaltung meines Bekannten verstärkt, der aus seiner Sicht Handlungspotentiale identifiziert hatte und daher mit einer ganz anderen Reaktion gerechnet hatte. Fremd- und Selbsteinschätzung gingen vollkommen auseinander. Mit freundlichen Grüßen, Othello.

 

Welche weiteren Ursachen könnte das ablehnende Verhalten der Führungskraft gehabt haben? Antworten finden sich, wenn wir uns Fragen nach alternativen Ursachen stellen:

 

• Welche Erfahrungen hatte die Führungskraft in der Vergangenheit mit Weiterentwicklung gesammelt?
• Welchen Anteil hatte der Berater und die Art und Weise seines Angebots, dass die Reaktion so ausgefallen war?
• Wie würden der Vorgesetzte der Führungsraft oder das Team reagieren, wenn sie wüssten, dass diese noch Handlungsbedarf in punkto Führung hat?
• Was wohl andere Führungskräfte über mögliche Defizite dieser Führungskraft denken?

 

Wie ihr seht, eröffnen die Fragen mehrere, alternative Zugänge auf Ursachen für die Reaktion bzw. Emotion der Führungskraft. Der Othello-Effekt ist in unserem Alltag allgegenwärtig und handlungsleitend. Achtet darauf und nehmt euch Zeit dafür, Ursachen zu erforschen. Wenn ihr bei eurem Gegenüber eine Emotion wahrnehmt, dann bewertet sie nicht gleich. Oder, wenn ihr das tut, dann denkt an Othello und gebt einer zweiten Meinung zu eurer Bewertung eine echte Chance.

 

Und in Teil 2 von ScrumMaster sind Meister der Effekte und Illusionen geht es um den Halo-Effekt und seinen Einfluss auf die Teamleistung und die Teamkommunikation.

 

Literatur

Ekman, P. (2011). Gefühle lesen. Wie Sie Emotionen erkennen und richtig interpretieren. Spektrum.

Related posts:

1. Der ScrumMaster ist eine Versicherung (Mike Beedle)
2. Über das Schreiben | Schreibblockaden
3. Über das Schreiben | Leidenschaft

  Continuing with the  100 Things You Must Know to Be Effective In Software Development. Scrum talks about self-organizing, cross-functional teams. Let me make it clear, this is the best team structure I know.  Some folks have construed this to mean - teams of generalists.  That is not what it means.  It means the team has all of the skills and knowledge required to create valuable software....

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