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.

The Hokey Pokey — by William Shakespeare

O proud left foot, that ventures quick within
Then soon upon a backward journey lithe.
Anon, once more the gesture, then begin:
Command sinistral pedestal to writhe.
Commence thou then the fervid Hokey-Poke,
A mad gyration, hips in wanton swirl.
To spin! A wilde release from Heavens yoke.
Blessed dervish! Surely canst go, girl.
The Hoke, the poke — banish now thy doubt
Verily, I say, 'tis what it's all about.


From a Washington Post Style Invitational contest, that asked readers to submit instructions for something (anything), but written in the style of a famous person. The winning entry was The Hokey Pokey (as written by Shakespeare), written by Jeff Brechlin, of Potomac Falls, Maryland.  Source.

A rehab center with a mission.
David Koontz - CHPI

Do you want to have more effective daily stand-ups? Do you want to have the planning meetings flow better and increase the value of these meetings? Do you want to see continuous improvement flow from your retrospectives? If your answer is yes, then put it on the Team.

I’ve written about trust, relying on strengths, and improving self-organization many times — and the message of these can be summed up as “Putting it on the Team.”  Make the team responsible for solving problems; make the team responsible for defining how to deliver; and making the team accountable for delivery.

Most of the times when we talk about the concept of the team self-organizing, is it more focused on the “how” part of delivery, and not the process. However, remember that the meetings (or ceremonies as some call them) are primarily for the team. Specifically, the Iteration Planning, Daily Stand-up (or Daily Scrum), and the Retrospective meetings — these are for the team, not the stakeholders or managers. Do the stakeholders and managers gain value from these meetings? Yes, but the real value is the fact that the team takes ownership of what they are going to deliver; they take ownership of holding each other accountable to deliver and work through problems themselves; and they take on the responsibility of improvement.

A lot of times we (as in Managers, Scrum Masters, Team Leads, Type-A Team Members) want to install processes and templates around these meetings. This usually happens after a few weeks or several months of trying an agile development framework and either not following the guidelines of the framework or the team not taking the initiative to make improvements. We’re not getting any value and the team is resisting and or blaming the whole concept — we want to fall back to more structure and being told what to do.

A great example of this is when a team’s stand-ups start becoming mundane, overrun their time boxes, and team members don’t show up. So what happens is we come up with a template for the team to keep up with for daily stand-ups, as well as establish a set of metrics we answer to during the stand-up. And of course, this just becomes one more thing for a team member to keep track of, as well as an unintentional mechanism of command-and-control.

As an ex-Director/Manager, I often wanted to step in and help — and I usually would come up with a template and/or some hard-prescribed structure and tell the team to follow it. I wanted to help, and that’s what Managers genuinely want to do. But I was quickly put in my place when one of my team members said, “Let us figure it out; it’s our problem.” I gave guidance and advice, but otherwise I got out of the way. I let the team come up with how they were going to make their meetings more effective. And at the end of the day, they simply looked at the frameworks themselves and decided to more closely follow the existing framework guidelines — e.g., keep stand-ups to 15 minutes and stick to the script, then allow the time remaining to become open-space troubleshooting time.

At the end of the day, remember that more process does not equal more better. Rely on the team to solve problems, over-instituting process and templates to solve problems. I think I’ve heard this before somewhere …

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: KNOW THYSELF

“Using self-awareness and self-knowledge for self-management seems to be key in becoming an effective leader.”

Running time 26:38

What instruments have you experienced that have been helpful to you? When has really good self-awareness and self-knowledge helped you self-manage as a leader? If you’ve experienced the Hogan, tell us about it. We’d love to hear your stories.

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

Summary
Intro – Using assessments in organizations to develop self-awareness and self-knowledge to become effective leaders.
1:55 – Introducing the Hogan assessment – richer, more subtle and provides more nuanced information.
5:56 – The Hogan assessment considers three parts: individual values, leadership potential and challenges or derailers.
13:12 – Comparing the Hogan assessment with the Strengthsfinder by Gallup.
19:54 – One differential aspect of the Hogan assessment – it can be used to map teams.
23:50 – Assimilating assessments like the Hogan in academic programs.

Resources
Hogan Assessment
Myers-Briggs
StrengthsFinder

Photo Credit: Werner Kunz via Compfight cc

  Continuing with the 100 Things You Must Know to Be Effective In Software Development.   I really appreciate the 2-3 new people who commented on the day 0 blog and joined our group. It got me to write today's entry on the flight home from the Scrum Gathering - something I almost certainly wouldn't have done otherwise.  So keep reading and getting friends to join - it helps.   I've been wanting...

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

The classic tale of a year-long project finally being delivered only to discover it doesn’t meet the needs of the customer sounds ridiculous in the days of short iterations and customer collaboration but I’m guessing we are still a long way from delivering what’s really needed effectively. So what’s stopping us?

1. Is it the fear of feedback that stops us showing work in progress
2. Is it the fear of admitting that we need to abandon the plan when we discover something new
3. Is it the fear of throwing away work done when people tell us it’s not what they need
4. Is it the fear of what others will say when we admit our assumptions were wrong
5. Is it the fear of embarrassment when we discover what was really needed was much simpler
6. Is it the fear of punishment when our boss discovers the work we did will not be useful to the customer (even though it created insight into what was needed)
7. Is it the fear of people questioning our competence
8. Is it the fear of what people say if we don’t look busy, when we are thinking about a different approach
9. Is it the fear of what people say if we don’t look busy when discussing ideas with others
10. Or are we just conditioned (by fear) not to think differently and to take the safest path

Finding the best solution to the problem takes courage, courage needs support – support through collaboration which needs openness. We are fearful because we are not open and openness takes courage.

Fear creates fear.

If we want to build the right thing we must start with a workplace without fear.

Building the right thing requires listening, patience, empathy and imagination

(resources that are scarce in the prevalent business mindset)

Does your ticket sidebar look like an endless groceries list? Are you looking for a way to organize stories and epics? Are you knocking your head trying to find your way through a sea of tickets?  Then, I think you will be more than relieved to hear that we’ve released Tags for Tickets.

So, go to any ticket view and start tagging. It’s easy. Just click on the edit icon and enter a new tag or select from the existing list.

If you want to change which tags appear on the popup for users to select go to Tickets->Settings->Tag. Select Active if you want a tag to appear in the popup selector or else Hidden if you want to remove them from it.

We hope you enjoy this feature and start tagging right away! Let us if you have any comments or suggestions.

If you want to learn more about Assembla's Ticket and Issue Management System you can read more about it here.

Hey everyone… I’m out in Vegas this week at the Scrum Gathering. Got invited to speak… which was really cool (thanks Daniel Gullo)… and did the most recent iteration of my Agile Program and Portfolio Management deck. Take a look and let me know what you think!

The post Scrum Gathering Las Vegas – Large Scale Program and Portfolio Management with Scrum appeared first on LeadingAgile.