Continuing with the 100 Things You Must Know to Be Effective In Software Development While adding value to the customer is the ultimate goal, there is more than customer value. There are actually at least five different types of business value: knowing what will be of value to the customer knowing how to build this building this deploying this value so it is consumed by the customer being...

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

Over on projectmanagement.com, my article “Agile: What’s in it for the Project Manager?” has been posted in two installments: part 1 on gathering requirements and work breakdown, and part 2 on interpreting requirements and tracking progress. Projectmanagement.com requires free registration to access the full content.

There’s more and more buzz around estimates and #noestimates in software development. People like to write bold statements and go extreme about things in blogs. Usually, personal dialogues are much more balanced. Some hate estimates and believe it’s a useless activity. Some defend it with arguments of arguable truth.

I want to dig into intrinsic estimates complications, what people mean by “estimate” and what future directions we may attack → Read the article.

Since Rally launched Rally Portfolio Manager in Dec 2011, I have worked with many PMOs, program managers and portfolio managers who ask: How can I adopt Rally’s portfolio management solution when I already have a PPM tool?

The answer: Use a Rally--PPM tool integration.  But what does this look like, and what does it provide?

Integrations ensure your PPM dashboards keep their value.

As Gartner stated at their PPM and IT Governance Summit last year, there is not a “ one size fits all” solution in the portfolio management world right now. That world is experiencing a major disruption and until it settles, which likely will take years, PPM providers have to play well with one another for the sake of providing you with comprehensive solutions that provide real value.

Here is one example. Agile continues to grow as a standard for project management. So portfolio dashboards must include Agile projects as well as traditional waterfall projects or risk losing their value. An integration with Rally would make sense here.

Which PPM vendors have partnered with Rally?

In 2011, several PPM vendors (Daptiv, Planisware, Oracle) partnered with Rally to offer an integration to Rally’s Agile solution. With the launch of Rally Portfolio Manager in late 2011, more integration possibilities arose. In 2012 Innotas created a bidirectional integration, Pervasive Software (now Actian Corporation) wrote the CA Clarity integration, and Rally’s own services group built an integration to HP PPM. The latest PPM integration was co-designed with Planview for several joint customers.

The benefits of integration are extensive.

The integration with Planview Enterprise is currently the most extensive bidirectional third-party integration to date between Rally and a PPM solution. Planview leveraged several new aspects of our free API to provide these key benefits:

1. Synchronization. The Planview integration automatically creates a matching Program/Initiative in Rally Portfolio Manager when you create portfolio initiatives or programs in Planview
2. Delivery of Valuable Increments. Focus on delivering valuable increments for the Program/Initiative (instead of focusing on being ‘on time and on budget’) by creating Features below the Program/Initiative in Rally Portfolio Manager
3. Real-time Status. As Agile teams work on implementing the Program/Initiative, portfolio managers & PMOs automatically view the progress of those Programs/Initiatives in the Planview portfolio dashboards, including the percent of work done based on actual Agile execution facts. Red-green-yellow status indicators are based on actual Agile execution,  actual start and end dates... you get the idea :).
4. More accurate cost data. If your organization is required to track software capitalization using a PPM tool, the integration synchronizes Rally’s timesheets with Planview’s timesheets so that everyone can stay productive in their own tool and avoid context-switching. The result? Your cost data is more accurate than when developers enter their time weekly or bi-weekly in a separate PPM tool.

If your organization currently uses mixed development methodologies (Agile, waterfall, iterative), then PPM / Rally integrations provide a way to adopt Agile at your pace while retaining your current portfolio dashboards. Now you can include your Agile programs in those dashboards.

See the integrations in action

Customers will present their use of the Planview and CA Clarity integrations at our RallyON user conference in June. If you are attending Gartner PPM shows late this month in the US or early next month in the UK, come on by our booth to see live demos!

Catherine Connor

„Wir wollen das Scrum of Scrums (SoS) anders gestalten – und zwar grundlegend. So, wie es jetzt gerade läuft, funktioniert es nicht.“

Mit diesen Worten begrüßte mich vor einiger Zeit ein Company ScrumMaster, den ich zurzeit coache. Er berichtete, dass das Scrum of Scrums seit einigen Wochen bei den Teams in der Kritik stehen würde, weil die dort besprochenen Inhalte den Teams wenig Mehrwert brächten und die dort investierten 15 Minuten Zeitverschwendung seien. Es sei vor allem herausgekommen, dass nicht jedes Team jedem anderen Team etwas zu sagen habe – und schon gar nicht jeden Tag. Vielmehr gäbe es Teams, die immer mit den gleichen Teams kommunizieren und genau das müsse man verstärken und statt einer großen Plattform mehrere kleinere Gelegenheiten schaffen, bei denen diese Themenverwandtschaften besprochen werden können. Man habe sogar schon einen Namen für diese neue Form der Zusammenarbeit gefunden: Meta-Scrums. Die ScrumMaster haben sich nach Rücksprache mit ihren Teams entschieden, das SoS- Setting mit „Meta-Scrums“ zu revolutionieren.

Ich lobte meinen Coachee für diese tolle Idee und unterstütze seine Ausführungen, indem ich auf seinen nachhaltigen Inspect-and-Adapt-Drang verwies. Ich schloss mein Lob mit einem nachdenklichen Seufzer. Leicht verunsicherte fragte mich der Company ScrumMaster, ob ich mit der Entscheidung nicht zufrieden sei.

Ich antwortete: „Ja und nein.“ Ich bestärkte ihn erneut darin, immer auf der Suche nach Verbesserungen bzw. Veränderungen zu bleiben und die Teams weiter als Meinungs- und Stimmungsbarometer zu nutzen (Ask the team). Ich erläuterte ihm aber, worin ich ein Problem erkannt habe. Meines Erachtens wäre eine Big-Bang-Lösung das falsche Signal an die Teams und würde der Reputation der ScrumMaster eher schaden. Warum? Der ScrumMaster hat die Verantwortung, den Scrum-Prozess zu bewahren und alles dafür zu tun, um die Produktivität seines Teams zu steigern. Mit der Meeting-Revolution würde jedoch der Prozess in Frage gestellt werden.

Wurde wirklich alles unternommen, um das kritikbehaftete SoS zu etablieren? Nein. Auf die Frage, ob alle ScrumMaster dafür gesorgt hätten, dass der Sinn des Scrum of Scrums in den Teams verstanden wurde und damit die (Selbst-) Verantwortung der einzelnen Teammitglieder geklärt sei, musste der Company ScrumMaster sich eingestehen, dass das „interne Marketing“ für das SoS Lücken aufwies. Seine Entscheidung für einen vollständig neu aufgesetzten Prozess kam noch stärker ins Wanken, als ich ihn bat, sich nochmal vollständig von seiner gefundenen Lösung zu entfernen und meine Fragen zu beantworten: Was war gut am alten SoS-Prozess? Was hatte das SoS bislang erfolgreich gemacht? Warum sollte man das SoS unbedingt behalten? Ich intensivierte meine Lösungsfokussierung, indem ich dem Company ScrumMaster riet, auch sein ScrumMaster-Team mit dieser Denkrichtung zu konfrontieren.

Alles anders

Gesagt, getan. Zwei Wochen später wurde ich bei meinem nächsten Besuch Zeuge eines lebhaften, gut besuchten, produktiven Scrum of Scrums. Am Ende gab es sogar Applaus! Die Teams applaudierten ihrer eigenen Performance. Verrückte Welt! Was ging hier vor sich? Wurde ich gerade Zeuge des ersten Scrum-Bestechungsskandals? Wurde verdeckt körperliche Gewalt an den Teams geübt?

Nein! Natürlich nicht. Aber wie war dann diese (Ver-)Wandlung zu erklären? Es klingt fast zu simpel, aber das ScrumMaster-Team hatte lediglich zwei klein(st)e Veränderungen vorgenommen:

• Das SoS wurde im Rahmen des Dailys wieder fokussiert thematisiert, indem die ScrumMaster ihre Teammitglieder fragten, ob es spannende Themen, wichtige Informationen (z.B. Abhängigkeiten), hilfreiche Neuerungen oder andere Exklusivitäten gibt, die sie im SoS vorstellen möchten.
• Den Teams wurde vollkommen frei gestellt, was und wie sie ihre Themen im SoS einbringen.

Durch eine Verstärkung der Team-Autonomie wurde erreicht, dass das SoS einen neuen Anstrich erhielt. Faktisch wurde an (nur) zwei kleinen Schrauben im Räderwerk des Meetings gedreht. Das Ergebnis: klein(st)e Veränderung, große Wirkung. Es ist immer wieder beeindruckend, was möglich ist, wann man Teams mit einem Mehr an Autonomie ausstattet. Genau so verstehe ich das Prinzip der Selbstorganisation. Das erste Setting des SoS hatte einen kleinen, engen Rahmen mit wenig Freiheitsgraden, wenig Spielraum für Fehler und klaren Grenzen. Mit der Zeit werden die Teams freier, sicherer im Prozess und wünschen sich mehr Gestaltungsspielraum. Agil sein bedeutet, diese Freiheit zu geben und die Voraussetzungen dafür zu schaffen, dass der Prozess weiter funktioniert.

Die agile Haltung „inspect and adapt“ hat nicht den Anspruch, im großen Stile gelebt zu werden. Viel wichtiger ist es, konsequent dafür zu sorgen, dass der Hunger nach Verbesserungen nie gestillt ist. Alles ist möglich, alles kann/darf, aber nichts muss. Entscheidungen sind immer in die Zukunft gerichtet und sind daher immer mit Unsicherheit behaftet. Sie sind jedoch genauso wenig in Stein gemeißelt und können jederzeit justiert werden – wenn wir uns den Handlungsspielraum für Veränderungen bewahren, agil bleiben. Bevor jedoch ein neuer Weg eingeschlagen wird, sollten wir innehalten und uns (retrospektiv) umschauen, um für uns festzuhalten, was gut an dem Weg war, den wir gegangen sind und was wir von dem, was gut war, behalten sollten – nutze, was existiert und, wenn es dich erfolgreich macht, dann mach es größer.

Related posts:

1. Die drei weiteren Rollen in Scrum
2. 5 min on Scrum | Es gibt noch viel zu tun
3. Skills | ScrumMaster | Führung

Let's face it: People skills is not an area in which the software development community has traditionally excelled. The very traits that can help a developer excel at technical problem solving can often make him or her challenging to work with day...

Backlog refinement is an important part of the Scrum team activity as it allows to gain a shared understanding of the work flow. Behavior-Driven Development (BDD) is a technique that use a business language to define acceptance testing (test cases) of requirements. In this article, Zia Malik explains how teams can use BDD to support product backlog refinement. At the beginning of each sprint, the Scrum team members and the product owner meet to discuss and write out the conditions of acceptance testing for the next-highest priority Product Backlog Item (PBI), ...

Hi everyone.  To pick the pace back up I'm going to write either shorter blogs or, as in today, I will take some previous work and mold it into this work.  I appreciate your patience and will get things going again. Continuing with the 100 Things You Must Know to Be Effective In Software Development I believe that one of the essential components of successful Agile adoption across teams is...

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

Auf der Suche nach Separators (Unterbrechern zwischen den Sequenzen “Was lief gut?” und “Was kann verbessert werden?”) für eine Retro bin ich auf drei ganz einfache und doch wirkungsvolle kurze Übungen gestoßen. Sie lassen sich ohne großartige Vorbereitung und Zeitaufwand durchführen und können je nach Retro-Ziel eingesetzt werden.

 

Variante 1 habe ich letzte Woche ausprobiert. Nach dem anfänglichen „Wie jetzt? Wir sollen bis 3 zählen? Ist das Dein Ernst?“, stellte sich schnell Überraschung ein. Es stellte sich nämlich heraus, dass es nicht so einfach ist, wie gedacht.

Durch die Kombination von kognitiver und physischer Aktivität verbinden sich unterschiedliche Bereiche im Gehirn. Dadurch wird auch das einfache Zählen bis 3 zu einer Herausforderung!

Variante 1: 1, 2 … 3

ca. 3-5 Minuten – mindestens 2 Personen

• Jeweils 2 Personen tun sich zusammen und zählen bis 3. Dabei wechseln sich die Personen immer ab (Person 1 zählt 1, Person 2 zählt 2, Person 1 zählt 3, Person 2 zählt 1, Person 1 zählt 2 usw.).
• Nach ca. 30-40 Sekunden hin und her zählen gibt es eine neue Vorgabe: Die Zahl 1 muss jedes Mal durch z.B. ein Klatschen ersetzt werden.
• Wieder 30-40 Sekunden später wird die 2 durch hüpfen, stampfen, Füße anheben etc. ersetzt. Als Beobachter und Spielanleiter ist es lustig, die Gesichter der Zähler zu beobachten – man kann ihnen die Konzentration quasi ansehen.
• Je nach Belieben kann man weitere 30-40 Sekunden später auch die 3 durch eine Geste ersetzen. Nicken, auf den Tisch klopfen, einmal in die Runde drehen etc. Vielleicht hat auch einer der Zähler eine gute Idee.

Nachher kurz fragen, was beobachtet wurde, bzw. wie man sich bei den Änderungen der Vorgaben gefühlt hat. Evtl. kann man die Brücke zur aktuellen Situation (Veränderung im Unternehmen, Scrum im Allgemeinen) schlagen: einfache Regeln können schwer zu befolgen sein, Koordination, zeitliche Abstimmung und Synchronisation sind nicht einfach. Bei Veränderungen braucht es immer wieder eine gewisse Zeit, bis man sich auf die neuen Rahmenbedingungen und das Gegenüber eingestellt hat.

Variante 2: 33 / 42

ca. 5 Minuten – mindestens 3 Personen

• Teilnehmer stehen im Kreis und rufen nacheinander (z.B. reihum) die Zahlen von 1 bis 33 (oder eine andere beliebige Nummer – je nachdem, wie lange es dauern soll).
• Immer wenn die Zahl durch 3 teilbar ist oder eine 3 enthält, wird ANSTATT die Zahl zu rufen, gemeinsam in die Hände geklatscht (oder eine andere Geste ausgeführt).
• Wird ein Fehler gemacht, fängt man wieder bei 1 an – bis die Gruppe es zu der vorgegebenen Zahl schafft.

Hier muss man mitdenken und den anderen zuhören. Man kann nur als Team liefern!

Variante 3: Blindes Zählen

ca. 10-15 Minuten – mindestens 5 Personen

• Die Teilnehmer stehen im Kreis und schließen ihre Augen.
• Es soll laut bis 10 gezählt werden. Jede Zahl darf aber nur von einer Person und einmal genannt werden.
• Wird eine Zahl von zwei oder mehr Personen laut genannt, fängt man von vorne an.

Hier ist Kollaboration gefragt. Möglicherweise kommt das Team drauf, dass eine Person komplett alleine zählt oder sie eine bestimmte Reihenfolge festlegen.

 

Wo ich das gefunden habe, gibt es noch mehr :-): http://agiletrail.com/2012/03/27/8-great-short-games-for-groups/ – vielen Dank fürs Teilen! Oder versucht das Linie-Überqueren von David aus.

Viel Spaß beim Ausprobieren und Variieren!

Related posts:

1. Warum sind soziale Systeme so schwer steuerbar? Ein Erklärungsversuch.
2. Vorweihnachtsretro
3. ScrumMaster vs. ScrumMasterin

This question came in and I was asked to see about answering it:

We are struggling with how to forecast feature delivery to stakeholders / customers in Agile – esp for a client data migration project where we seem to keep finding bugs and exceptions. How is forecasting handled in Agile?

I spend a lot time answering this question, primarily because our software ScrumWorks assists in doing this in a variety of ways, and it’s my job to sell ScrumWorks. The underlying concepts and methods are not software dependent however, just easier. So I am going to run through some of the basics here in Agile forecasting.

What you will Need:

• Stable, Cross Functional Scrum teams.

A team needs to stable to be measurable. If our team is constantly changing members they will not only fail progress into norming (much less performing) but they will never be able to provide a consistent Velocity. Keep in mind that Velocity is simply a measurement, the average rate that your team completes work measured in whatever relative estimation scale you are using. If you were trying to measure the average number of miles you get on a gallon of gas you wouldn’t have a very useful value if you changed your car every 4 miles. The same applies to a team, the more stable they can be the more reliable your Velocity will be.

• Consistent Relative Estimation of your Backlog Items.

Backlog items need to be estimated in a relative fashion, as in; “Item A is a 2, and Item B is twice as hard, therefore it is a 4″. Over time this type of estimation, with a stable team, allows for more consistent estimation. Forecasting in Scrum isn’t about accurate estimation, just consistent estimation. Estimates are guesses, and probably wrong. If we are consistently wrong we can still use that data to forecast.

• A Product Backlog that isn’t just User Stories.

A misconception I run into constantly these days is that the Product Backlog is just user stories. This couldn’t be more wrong. The product backlog is a prioritized list of Everything the team needs to do to complete the project. Defects need to be prioritized into this list, development spikes, technical debt, functional requirements. If the team is going to do work on it and it is related to this project then you should be putting it on the backlog, estimating it, and committing to it, just like your User Stories. Without a relatively clear idea of all the work you will have to do forecasting becomes a lot less certain.

 

How you go about Forecasting:

Once you are set with a stable velocity and a backlog populated with all the work we need to do you will want to try to get as much of it estimated as possible. These estimates do not need to be solid until the team is ready to commit to them, high level estimates are good enough as you go down in the backlog. I usually suggest time boxing the estimation of items, ~5 minutes per item with a team that has a good handle on what an estimate means to them can be good enough for decent forecasting. A sold ScrumMaster can really help when it comes to this type of work. It is very likely that the items will be re-estimated when they are closer to being committed to in a Sprint.

The most basic form of forecasting just requires some simple math. For example: our team has a velocity of 50. A sprint is 2 weeks. This means that a 2 month release is about 200 points. If you have more then 200 points within the release it’s unlikely that you will finish. Less then 200 you are looking good. This doesn’t really help us visualize, or forecast dates, but it can tell us quickly if we are going to meet a target date.

When we want to actually forecast we need to plot 3 things: The points a team completes in a sprint, the total points on the backlog, the rate at which our scope changes. The third one is the hardest, it requires us to record each change made to a backlog item’s estimate, but it is a very important piece of this.

Visually we can create a chart that looks like this:

The actual ScrumWorks 2.0 release back in ’06

 

On this report the Blue Line jumps up every time the Team completed a backlog item and the Product Owner accepted it as complete. The trend line is the team’s Velocity.

The Red Line rises or falls any time backlog items are added, removed, or re-estimated. The big drop between July 15th and 30th was when the Product Owner removed work from the backlog, and then on August 29th appears to have put it back in, or added different work. The red trend line represents the scope change. In this case the scope was trending upward.

Where the red and blue trends converge you have a potential release date. You could also use such a report to note that the velocity trend will converge with the baseline (which in this report’s case is 450) between February 10th and the 25th and say that would be the date all the work should be finished assuming no more work is added (which is pretty safe to say based on the recent trend).

This particular report is very simple and can be improved with a broad variety of options.  There are some traps people fall into when they are practicing agile that will make this report less valuable however:

• Changing estimates after they are scheduled in a sprint is something you do not want to do. Keep in mind that we are comparing the rate at which we complete points to the points that we have not completed yet. If we change our estimates after the fact we are suddenly comparing reality to estimates, and defeating the purpose. We want to compare the rate that we consistently complete flawed estimates to the total flawed estimates we haven’t started yet. If we are consistently wrong we can still generate a solid forecast because we are comparing apples to apples.

• Partial Credit is just waste. Don’t bother doing it. Velocity is the average, if one sprint results in 10 points completed and 40 partially completed, and the next sprint we complete 90 points, the average is still 50. If you look at the report above you can see an example of where this occurred, right at the November 27th mark. You have one really bad looking sprint, followed by one really good looking sprint. That’s reality, the report will reflect it correctly. Any consumer of such a report needs to understand that it is the average that matters, not what happened in any specific sprint.

• Estimation is a ritual the team uses to surface questions about a Backlog Item that need to be answered before the team can commit to completing that item within a sprint. Estimation is not a way to get estimates, estimates are simply a happy and valuable by-product of Estimation. Good Agile reporting is a passive thing that stays out of the team’s way, even as it answers important questions.

• Time Estimates technically work with this report, but not for the process of Estimation. Remember that Relative Estimation is a requirement for this type of forecasting to be successful, it’s not just a suggestion. If you are estimating your story points in time you are going to have trouble.

 

This blog entry is really just a taste of Forecasting in Agile. I’ve personally seen it work, surprisingly well in fact, and this is typically why this method is what I immediately go to when someone asks me about Forecasting, but it isn’t the only way to do it.

 

The post Forecasting in Agile appeared first on blogs.collab.net.

We know that self-organization is a critical aspect of every successful Agile and Scrum team and we also know that it takes trust, respect, openness and responsibility; so why many teams have a hard time to achieve it? Self-organization changes the dynamics between the manager and the team and between the teammates themselves. Resistance may arise and the source is frequently rooted in mental habits, such as a latent blaming culture, confusing guidance and command, fear of taking responsibility or losing status, unconscious agendas. Through real stories from the field and ...

We announced our latest feature Server Side Hooks the other day. But before we even did that, something very cool happened, we got our first hook submitted by a contributor outside of Assembla. Thanks so much Jakub.  Now users with Subversion repositories can install this hook and check their PHP code syntax.

We could never have had the time to think of creating nor actually implementing a solution for checking PHP code, because we would want to check all sorts of style of code and the scope would grow. Now users can scratch their own itch with minimal effort on our part.

For those of you still not sure what I am talking about: We are allowing customers to write their own Server Side Hooks and install them on our Servers, that’s right, you can extend Assembla’s cloud repository offering.

Thanks again and keep those hooks coming.

My friend and colleague, Gil Broza, is interviewing me for his Individuals and Interactions virtual training event. My topic? “Focus Keeps You Going.”

If you read my personal kanban series a couple of weeks ago, you saw how my focus kept me going. Even with a big interruption last week, due to a death in the family, I was able to maintain my focus, because I knew exactly what I had to do, to finish my work, to get ready for my trip today.

Gil has other great people in his event: Doc List, Ellen Gottesdiener, Mary Gorman, David Spann, Christopher Avery and Bob Schatz might be names you recognize. How about Rick Ross? David Spann? Caren DesBrisay? You might not recognize these names, and you should listen to what they have to say, too.

Check out Gil’s Individuals and Interactions training. Sign up. It’s a steal.

We’ve promised something special at our Facebook page last week, so here it is! We are happy to support a very interesting Agile conference in Belgium that will take place on June 15th/16th. But what is even more exciting – YOU can win a ticket to that conference worth 750 EUR!

The Rules

• You need to be a tinyPM client – it does not matter if you just became one ;-)
• You need to post a tinyPM review at BestVendor.com
• Tweet (the best choice) or post to Facebook or share the information about DARE 2013 any other way you prefer
• Post a comment here under this post that you did all this :-)

The Prize!

Do all the above and we will draw the prize among the participants on May 30th (Thursday). The winner will get 1 ticket for DARE 2013. We will ask the winner for details and the ticket will be issued by the organizers to your name.

Spread the word and win a ticket for DARE 2013!

When you're about to engage in a risky activity, such as flying an airplane, it's wise to be prepared. The cost of a mistake may be measured in lives. Thankfully, aviators have figured out a simple but effective means to keep planes flying safely....

"Es sind nicht die Dinge, die uns beunruhigen, sondern unsere Sicht auf die Dinge." Seneca

Eine Szene aus einem Training für Manager im Scrum-Kontext. Auf der Themenliste aus der konkreten Führungspraxis stand der Satz: Wie motiviere ich mein überlastetes und gestresstes Team?

Im Fallgespräch erzählt der Teamleiter, der mit seinen vier Mitarbeitern für die Qualitätssicherung im Unternehmen zuständig ist, dass seine Mitarbeiter von den ständigen Unterbrechungen bei ihren täglichen Vorhaben genervt und immer mehr demotiviert sind. “Kaum eine Aufgabe können wir kontinuierlich zu Ende führen, immer gibt es höhere Prioritäten, durch Kunden, Management oder den Product Owner. Die Tage sind zerrissen durch spontane, unvorhergesehene Situationen, die es uns schwer machen, gute Arbeit abzuliefern. Der Druck ist groß und die Ressourcen sind knapp. Veränderungen aus dem Umfeld sind in absehbarer Zeit keine möglich. Und so quälen wir uns über die Runden und sehen irgendwie kein Land. Trotzdem machen wir immer noch einen guten Job, aber wie lange noch? Wie halte ich in so einer Situation meine qualifizierten und guten Leute bei der Stange, wie motiviere ich sie?“

Während er mir und den anderen Teilnehmern seine Geschichte erzählt, wirkt auch der Teamleiter selbst gestresst, hilflos und deprimiert. Mehrere Kollegen kennen das Erzählte aus ihrer Praxis und bestätigen ihn verständnisvoll in seiner Not.

Ein Bild sagt mehr als tausend Worte

Ich fordere ihn auf, sich mal ein Bild, eine Metapher für sich und sein Team zu überlegen. Er braucht nicht lange und bringt als sein Teambild den Notarzt. Er beschreibt das Bild: „Wie wir muss der Notarzt permanent ohne Vorwarnung zum Einsatz. Manchmal von einem direkt zum anderen. Er hat immer Probleme vor sich, wenn er ausrücken muss. Trotz hoher Kompetenz sterben ihm oft die Leute unter den Händen weg, weil er nicht genug Zeit hat. Oder sie sterben trotz aller Bemühungen später im Krankenhaus. Irgendwie ist seine Arbeit doch meist Stückwerk. Dann muss er auch noch ellenlange Berichte schreiben und ist im schlimmsten Fall an allem Schuld. Das ist doch deprimierend und total unbefriedigend und genauso geht es uns“.

Immer noch ist er deutlich wahrnehmbar in seinem Defizitzustand, es geht ihm nicht gut, er wirkt ratlos und resignativ.

Ich bitte ihn nun, sich doch mal ein positives Bild zu seinem Team und der Arbeitssituation zu machen. Er überlegt lange hin und her, es arbeitet in ihm, aber er kann keine positive Bildmetapher entwickeln. „Mit fällt da wirklich nichts ein, ich bin völlig blockiert. Da gibts anscheinend einfach nichts Gutes bei uns“, ist sein Fazit.

Nun frage ich ihn, ob ich ihm ein positives Bild anbieten darf, das aus meiner Sicht auch eine Möglichkeit sein könnte seine Teamsituation zu betrachten und einzuordnen. Er stimmt, leicht skeptisch, zu.

Ich entwickle folgendes Bild für den Teamleiter:

„Stell Dir vor, Dein Team ist eine hochprofessionelle Bergführermannschaft, deren tägliche Aufgabe es ist, Menschen aller Art sicher auf hohe, steile, ja auch gefährliche Bergriesen aller Höhengrade zu begleiten. Alle Deine Spezialisten beherrschen ihr „Handwerk“ perfekt, sind optimal als Team aufeinander eingespielt und kennen ihren Job genau. Ihr liebt eure Aufgabe und eure Kunden. Gut vorbereitet und hoch motiviert beginnt ihr den Aufstieg. Ihr kennt die Routen genau und arbeitet routiniert. Trotzdem ereignet sich immer wieder Unvorhergesehenes. Das Wetter wechselt plötzlich und zwingt zum Biwak, gefährliche Gerölllawinen erfordern Routenwechsel, Kunden verletzen sich und müssen ins Tal zurückgebracht werden, oder sie geraten in Panik, sind unzufrieden und belasten die Gruppe, usw. Die geplanten Zeiten können nicht immer eingehalten werden. Manchmal kommt es zum Abbruch und es muss ganz neu gestartet werden. Dein Bergführerteam löst die Probleme kompetent und gelassen unter Deiner engagierten Leitung. Bei allen Hindernissen erreichst Du mit Deinem Team und den Kunden (fast) immer die Gipfel. Dann genießt ihr den „Sieg“, freut Euch über die Anerkennung der Kunden und seid immer aufs Neue begeistert vom herrlichen Ausblick auf all die Gipfel, die ihr in Zukunft noch bezwingen werdet. Ihr wisst, dass es kaum eine Situation gibt, die ihr nicht engagiert angehen und lösen könnt, wenn es darauf ankommt. Das zeichnet Euch als Spezialteam aus, das ist Eure Mission und darauf seid ihr auch richtig stolz. Ihr freut Euch auf die nächsten, sicher nicht einfacheren Aufgaben und gebt Euch untereinander Feedback, was läuft und was man verbessern könnte, um Euch als Team zu optimieren.”

Schon bei den letzten Worten meiner Bildbeschreibung wirkt der Teamleiter deutlich entspannter und kommt aus seiner negativen Haltung heraus. Folgender Dialog entsteht (leicht gekürzt):

Frage: „Wie ist das jetzt im Moment für Dich“?

Antwort (mit fester Stimme): „Das klingt ganz  gut, so kann man mein Team und seine Arbeitssituation tatsächlich auch sehen. Und vieles stimmt tatsächlich, wenn ich es genau betrachte.”

Frage: “Wie geht es Dir denn jetzt mit dem neuen Bild?”

Antwort: „Prima, ich fühle mich optimistischer und gestärkt, irgendwie ein ganz positives Gefühl.“

Frage: „Stell Dir vor, Du gehst mit diesem positiven „Bildgefühl“ an Deine Arbeit, was würde evtl. anders sein als vorher?“

Antwort: „Das hätte sicher einen gute Wirkung auf meine Mannschaft, ich lass mich immer wieder zu sehr runterziehen.

Frage: „Nimmst Du das Bild mit, und probierst mal aus, ob Deine neue Haltung tatsächlich seine Wirkung tut?“

Antwort: „Ganz sicher, ich denke ich hab was begriffen, was für mich als Führungskraft ganz wichtig ist. Und ich werde mir ein tolles „Bergbild“ als Merker besorgen.”

Innere Bilder – das sind all die Vorstellungen und Szenen, die wir biographisch (von Kindheit an) gespeichert haben und die unser Denken, Fühlen und bewusstes/unbewusstes Handeln in hohem Maße mitbestimmen. Wenn sich Menschen bildlich etwas vorstellen, sind die gleichen Hirnbereiche aktiv, wie wenn sie es tatsächlich tun. Im Sport wird das seit langem erfolgreich be- und genutzt. Innere Bilder sind im Gehirn abgespeicherte Muster, die wir meist unbewusst benutzen, um uns zu orientieren, Situationen zu analysieren, zu bewerten und unsere Handlungsimpulse danach auszurichten. Je länger sich Menschen z.B. in für sie negativen Bildervorstellungen aufhalten, umso mehr verfestigt sich dieses Bild und seine Auswirkung auf Denken, Fühlen und Handeln. Innere Bilder können uns blockieren, oder aktivieren, können uns ängstigen oder Mut machen und motivieren. Bilderprozesse sind auf alle Fälle eine wesentliche menschliche Ressource, um das Leben und seine Anforderungen zu gestalten.

In Anlehnung an einen Blogbeitrag von Boris Gloger vom 18. Februar 2013 kann gesagt werden: „Führungskräfte sind konstruktiv, nicht destruktiv.” Sie müssen um ihre besondere Wirkung auf ihr Team wissen und durch Selbstwahrnehmung, Selbstreflexion und ihre mentale Einstellung ihren Mitarbeitern gute, positive, stärkende „Bilder“ vermitteln, auch wenn es manchmal schwer fällt. Den Einfluss, den die mentale Verfassung von Führung auf Teams hat, wird in der Regel unterschätzt. Für Motivation, Engagement und Arbeitszufriedenheit, besonders in schwierigen Situationen, ist dies zweifellos oft entscheidend. Dieser Beitrag soll Mut machen, „das eigene Bild“ einer schwierigen Situation zu erkunden, dessen evtl. kritische Wirkung wahrzunehmen und sich ein neues, unterstützendes Bild zu gestalten und den Unterschied zu testen.

Übrigens: Der Teamleiter überlegte zum Ende des Trainings, dieses Bild mit seinem Team im nächsten Meeting zu besprechen. Er kann sich gut vorstellen, dass auch seine Kollegen eine neue Perspektive gewinnen und so mit einer anderen, lockeren Einstellung an die Arbeit herangehen.

Tipp: An der eigenen Einstellung arbeiten und mit dem Team zu neuen Erfolgen aufbrechen – Scrum Supplements sind die Krafttrainings für die Veränderungsarbeit mit Scrum. Nähere Infos und alle Termine gibt es hier.

Related posts:

1. Führung in Scrum | der Manager | Verhalten | Teil 2
2. Führung in Scrum | Manager | Teil 4
3. Einzelkämpfer ScrumMaster? Herausforderungen als ScrumMaster Team gemeinsam meistern Teil 4

Experimentation is a powerful learning tool. When I was young, I performed scientific experiments by mixing chemicals together to see what they would do. I learned that most random concoctions from my chemistry set would make a brown liquid that was often hard to clean out of a test tube. I learned that sometimes they would create very smelly brown liquids. These were not really experiments, however, and I didn’t really learn from them. Instead, these were activities and I collected anecdotes and experiences from them.

The scientific method rests on the performance of experiments to confirm or deny a proposed hypothesis. Unless you can propose a hypothesis in advance, you cannot design an experiment to test it. Until you test the hypothesis, you haven’t really learned anything.

“In general, we look for a new law by the following process: First we guess it; then we compute the consequences of the guess to see what would be implied if this law that we guessed is right; then we compare the result of the computation to nature, with experiment or experience, compare it directly with observation, to see if it works. If it disagrees with experiment, it is wrong. In that simple statement is the key to science. It does not make any difference how beautiful your guess is, it does not make any difference how smart you are, who made the guess, or what his name is — if it disagrees with experiment, it is wrong.” — Richard Feynman, The Character of Physical Law

When we estimate how long it will take, or how much it will cost, to implement a desired amount of software functionality, we create a hypothesis that we can test. Our hypothesis may not be of enduring and universal value as a hypothesis that predicting physical laws, but it may still be extremely valuable to us.

For example, suppose we have a number of features we’d like to get into our next software release. And suppose we have a date in mind for that release, and a team ready to work on it. We could then ask that team to estimate the features relative to each other, bucketing them into groups of similar sizes. We could also ask them to estimate how much bigger (or smaller) are the features in one size group than the features of another. If this team has previous experience working together, they might be able to guess how long one feature might take to implement. Otherwise, they might just take a guess at it.

I would expect these numbers to be simple, with only one or two significant digits. After all, we don’t have much data to base them on. Their precision should not pretend that we do.

If we were practicing a plan-driven serial software development cycle, we might treat these estimates as promises and try to manage the work to meet them. In such case, I would expect them to have padding for the unknown, and higher precision to hide the fact that they’re padded guesses.

Using an empirical software development approach, we’ll instead treat this projection as a first hypothesis. When we finish the first feature, we’ll have some better data on the rate at which we’re progressing, and can project into the future with a bit more confidence. Does this data confirm our hypothesis of when we’ll be done?

This experiment helps us make decisions. If completing the features by the target date looks unlikely, we’ll want to take drastic action. Perhaps we’ll eliminate some features, or make them all simpler, in order to trim scope and achieve some success. Perhaps we’ll decide to cancel the project altogether, cutting our losses with only a fraction of the budget spent.

If the target still looks feasible, we can continue the experiment. We’ll still have uncertainty about both the rate of progress and the size of the work, but we can reason about those uncertainties. Are our errors in sizing likely to be additive, or random? Is the current rate of progress sustainable? Is it depressed because of one-time startup work? Or is it optimistic because we’ve been cutting corners?

Poorly handled estimation is a means to fool ourselves, but handled with care, it gives us tools to experiment and learn.