…nun bist du also ScrumMaster. In einem neuen Team, in einem für dich neuen Unternehmen, in einer neuen Branche. Quasi in der Fremde. Du betrittst das Glatteis. Es fühlt sich wackelig an. Und dennoch ist da der Reiz des Neuen, des Unbekannten. Eine unsichtbare Kraft motiviert dich wieder mal aufs Neue, einen guten Job zu machen. Aber, nur weil du nun den Hut des ScrumMasters, des latenten Teamleads auf dem Kopf trägst, bist du noch nicht von allen unumstritten und akzeptiert in deiner Rolle. Das klingt hart, ist jedoch die Realität, so wie ich sie in vielen Fällen erlebt habe, wenn ich die Führung neuer Teams übernahm. Dennoch kein Grund zum Pessimismus, solange man sich vor Augen führt, dass es nun zu liefern gilt. Sprich, Taten spürbar und transparent für das Team folgen zu lassen. Was also tun? Ich möchte einige Beispiele beleuchten, die einem auch als Branchenneuling helfen, von einem gestandenen Team akzeptiert zu werden.

Sei du selbst die Veränderung, die du dir wünschst für diese Welt!

Mit diesem Zitat von Mahatma Ghandi möchte ich eine Überleitung zu den kleinen alltäglichen Dingen schaffen, die jedoch schnell deutlich positive Wirkung haben können. Das kann heißen, die Teammitglieder am Morgen mit einem freundlichen Händeschütteln zu begrüßen, ihnen häufig ein Lächeln zu schenken oder mit regelmäßigen anerkennenden Worten zu ihrem Verhalten oder ihren Taten Respekt zu zollen. Es wird sich zeigen, dass ihre Erwartungen diesbezüglich übertroffen werden, denn sie sind diese Verhaltensweisen aus ihrem Berufsleben sehr wahrscheinlich nicht gewohnt. Ich selbst bin beruflich mit der Philosphie „behandle andere so, wie du selbst behandelt werden möchtest“ aufgewachsen. Daher erlebe ich, wenn ich mich daran halte, dass es aus dem Wald heraus schallt, wie ich es hinein rufe. Die anderen sind der Spiegel eines selbst. Dies meine ich hier im positiven Sinne. Schenke ich den Teammitgliedern einen respektvollen und freundlichen Umgang, so erhalte ich diesen zurück.

Taten sagen mehr als 1000 Worte!

Stehe zu dem was du sagst, besonders zu dem, was du ankündigst. Das ist eine Erkenntnis, die ich aus vielen Erfahrungen teilen möchte. Teammitglieder, Mitarbeiter, Kollegen oder andere merken sich in der Regel sehr gut, was angekündigt wurde. Es herrscht also eine Erwartungshaltung. Auch wenn sie noch so klein ist. Das können wir gut finden oder eben auch nicht. Aber es ist so. Wir haben sie durch Worte erzeugt. Also sollten wir unseren Worten auch Taten folgen lassen. Nicht nur das. Ob ich vorgebe, also sage, ein engagierter Kollege, in unserem Falle SrumMaster zu sein, oder es tatsächlich vorlebe, ist ein großer Unterschied. Fragen wir uns also. Ehrlich und im Stillen mit uns selbst. Bin ich wirklich für die Teamkollegen da? Habe ich ein Ohr für ihre Themen? Lebe ich Engagement vor oder sehe ich eigentlich zu, stets sehr pünktlich den Arbeitsplatz zu verlassen und bin meist der Erste, der geht?

Schaffe Transparenz!

Ganz egal, ob als ScrumMaster, Manager, Führungskraft … Man steht im Fokus. Gewollt oder nicht. Die Berechtigung den „Hut“ zu tragen, der uns zum ScrumMaster macht, müssen wir uns immer wieder durch Taten verdienen. Hier hilft uns die Transparenz. Häufig ist die Arbeit eines ScrumMasters nicht so sehr sichtbar. Wir hacken nicht den halben Tag in unseren Computer. Wir sind häufig nicht zu sehen, da wir in irgendwelchen Meetings stecken und abends können wir keine Verkaufszahlen präsentieren. Machen wir doch also einfach transparent, was wir den Tag über so tun. Machen wir es sichtbar. Wir brechen uns keinen Zacken aus der Krone. Und, ich finde es geht die Teammitglieder sehr wohl etwas an, was ich für sie und unser Team den lieben langen Tag so tue. Das funktioniert sehr gut über ein persönliches Taskboard, das in Papierform (Flipchart) an unserem Platz hängt, sowie ein ebenso sichtbares Impediment Backlog. Unsere Aufgabe ist es schließlich, Impediments aufzuspüren und aus dem Weg zu räumen. Das darf gerne sichtbar sein. Erledigte Impediments oder Tasks wandern über unser Board. Ein Gradmesser für unsere Leistung. Für uns und unsere Teamkollegen. Letztlich möchte ich mich noch dafür aussprechen ebenso transparent zu machen, wo ich mich befinde. Auch das kann man am persönlichen Taskboard ersichtlich machen. „Im Meeting/Raum xyz oder auch „in der Mittagspause“ sind mögliche Varianten, dem Team zu zeigen, dass ich es respektiere.

Die Beispiele, die ich heute beschrieben habe, sind sehr leicht umzusetzen, haben jedoch große Wirkung. Denn häufig scheitert es einfach im Kleinen und in der Häufung dieser Kleinigkeiten. Wer kennt es nicht?! „Mein Chef sagt mir nie Guten Morgen“ oder „…nie werde ich gelobt“. Diese und andere Aussagen haben wir alle schon gehört oder vielleicht sogar gemacht. Gehen wir also mit positivem Beispiel voran und sorgen für eine gute Stimmung. Lieferung, Qualität, Produktivität und Profitabilität sind zwar die klaren Erwartungen und Ziele, die ein Scrum-Team verfolgt und erfolgreich macht. Das, was uns letztlich jedoch glücklich macht neben unseren Erfolgen, ist eines: Stimmung.

Abschließend möchte ich eine Frage zum Nachdenken stellen:

„Ob groß oder klein. Begeisterung ist nichts anderes als übertroffene Erwartung. Was tue ich dafür?“

Related posts:

1. Was sind StoryPoints?
2. Schätzen vs. Planen?
3. Taskboard Design

Assuming this list of metrics is good enough (not perfect, and not for everyone); how would one actually implement and calculate these metrics?  Will it take a super computer, or a 17 page spreadsheet full of rows and columns?  I really don't think so, but let's try a few and see how onerous it may be to have good measures of the team's performance.

These metrics are suggested at the team level.  It may be counter productive to the team to allow these metrics outside of the team.  If so, then you have an organizational impediment that stifles visibility.  Resolve that before you hurt the team by allowing too much visibility into the "sausage factory".


Velocity (in Story Points) 
The number of story points that were completed and accepted by the product owner as "done" in this one sprint.   Not an average, not an estimate, no partial credit given, etc.  This is an empirical measure of the teams capability to turn stories into working software. One can debate weather stories that are defects fixed should be counted in the velocity.  I say no.  Assuming that this is the team that created the defect - then this is the team that warrants its work against defects.  A auto mechanics doesn't get paid twice for adjusting the carburetor and then fixing the adjustment because the car stalls at a stop sign.
Simply sum the Done storie's points.  Units are Story Points, not hours nor ideal days. Track this as a trend over sprints.

Projected capacity (in person-days) of next sprint
The number of person days of work we expect the team will work in the next sprint.  This metric should be relative stable, expect around holidays and flu season.  If it is erratic then you have an impediment.  Look around, look in the mirror - the problem may be you!  A common question is who counts and who does not count toward this metric?  My response is that if this person works day in and day out to deliver the sprint objective (working software) then they count, regardless of their title/role.  If they are less than 35% assigned to the team, then I don't count them at all.  It will be more trouble to find them and ask them for information than they contribute - treat them as overhead.  Oh, and you have an impediment.
Have the team project person-days for the coming sprint; sum them up.  Units are person-days (resolution of half days or greater - not hours!).  Track this as a trend over sprints.

Projected capability (in story points range) of next sprint
Before planning or first thing in the sprint planning session project the team's capability for this sprint.  The purpose of this metric is to give the team a goal range to shoot for, not one post that must be struck;  image a football (soccer) goal.  Anywhere within the net counts.  Take the average velocity (now you get to do some high math - make it a running average - say 5 sprints for a mature team) and adjust it for abnormal projected capacity, then apply a plus/minus range to it that covers the typical variance over the last few sprints.  Assuming you have achieved a stable capacity, then this adjust term of the equation is just needed around holiday season.  Look at the last several sprint and find the variance (the highest velocity minus the lowest velocity = variance).  Your projected capability is 1/2 variance +/- the running average.

Planned capability of the sprint (in story points)
This is the amount of story points the team accepts into their sprint.  Let's hope they have the good sense to keep it between the goal post of projected capability.  If they don't someone should be asking why five times.  There are reasons to aim outside the goal post, but you better be an expert at bending it like Beckham.  Planned capability is simply the sum of storie's points in the Sprint Backlog when planning meeting is finished.  Track this metric sprint over sprint; compare it to velocity.

Story points done and accepted by PO in the sprint
At the end of the sprint the done stories are demonstrated to the Product Owner.  The PO is then asked if this story is accepted, yes they need to make a quick assertion.  I'll let you know next week is not acceptable.  It's a yes/no immediate feedback required moment.  If there is hesitation - guess what - you have an impediment.  Maybe having conversation along the development path with the PO and showing them intermediate builds will help.

Story's started but not done (in story points and stories)
Ideally these two metrics trend toward zero and become easy to count.  Sum up the number of stories that were started but didn't get done or accepted by the PO.  Sum up all the story points that the team started but didn't get done/accepted.  This is a measure of wasted work.  Reduce the next sprint's planned capability by this amount.

Discovered work added to the backlog (in story points and stories)
High performing teams do not waste a lot of time planning for everything that they could possibly do in the future.  They allow that discover of work will happen and they adapt.  However, if your team is finding more work each sprint than they can accomplish in a sprint then you have a never-ending project.  You better add some visibility to this.  Both inside the team and outside the team.  Don't forget to add in the deferred work that has to happen at release time.  This can take on many forms: technical debt, documentation, database rollback scripts, system testing on production equipment/environment, etc.

Scope increase/decrease during the sprint/release.
Similar to discovered work, track organizational imposed scope changes (in story points and number of stories).  If this trend line doesn't become stable and near zero, then your product is at high risk.  You have impediments.  Or maybe your Product Owner doesn't have vision and is just making shit up.

Technical debt incurred this sprint (in story points)
I hope you are using the term 'technical debt' in it's technical meaning.  If so you want to have a pay back plan.  To have an effective plan for repaying the debt incurred you will want to know the principle amount.  Continually sum up the technical debt incurred and show this trend line added to your backlog.

Cost of sprint
What does your development team cost per sprint?  HR should be able to give you a cost multipler for an average salary to account for benefits and overhead.  Use that factor and the actual salaries of the team to derive the cost of the team.  Do you want to include all the overhead people?  It's up to you.  I like to know the team's cost, and the program cost (this is where multiple teams and the overhead is best reflected).  If your organization believes in the team visibility aspects of agile, then they will see this visibility as a two way street and share the cost of all teams with team members.  So if you have multiple teams all over the globe, they will understand the cost dynamics behind this decision.  Maybe it will help them deal with the dislocated-team issues better.  Human dynamic issues aside, knowing the cost of the team helps the team decide when to quit adding features to a design dead application.

Impediments discovered/removed/escalated
I like to start with the simplest measure of the scrum process.  This is it.  If it is working then the only guantee is that it will present the organization with impediments to the team.  If these discovered impediments are being removed, then the process is working.  If no impediments are being discovered then your process adoption has failed.  And guess what - the problem is not the team, it is the team's leadership.

Sprint - pass/fail
In the CHAOS report the Standish Group defined project success as: on time, on budget, and with designed scope.   If that is the definition of a project success, why don't we use it as the definition of sprint success.  Then the self-similarity of the Scrum sprint will be a fractal of the project.  Let's define success of a sprint as on time (within the timebox), on budget (typically just the scrum team remains static or has the previously defined growth in personal), and with the agreed upon scope (the team delivers very close to the sprint plans in terms of stories or story points of potentially shippable working tested application).  Make this metric binary (pass/fail).  Track this metric sprint after sprint.  If the team fails in a sprint to deliver a successful sprint, expect them to correct this behavior if they wish to deliver a successful project.  When a team is not capable of successive sprint passes in a long streak of measuring this metric, then the risk flag should be thrown on the playing field.  What would you think of a team that had 47 sprints of passes in a row?  Is that a good thing?
See Also:
An attempt to crowdsource a better list of Scrum team metrics.
Jeff Sutherland's answer - ten essential metrics.
Additional article on Scrum metrics by Bob Boyd.

I just finished up a webinar entitled Production Monitoring: The Key Steps Towards Continuous Delivery, presented with Airbrake.io The webinar focused on how Production Monitoring is the most important process in any application, but particularly online applications when practicing Continuous Delivery.

 

The Key Points were:

• Continuous Delivery is not a process that I can define for you, rather its a goal.
• The Goal of being able to continuously deliver your code to QA/UAT or Production and react in real time to the results of the release.
• Iteration Planning is Stressful
• Confidence in Releases is Key to Automating Deploys
• Confidence in Code is Key to Moving Fast
• More Data and Less Stress

If you missed the webinar, you can view it above or watch it on youtube and/or download the slides.

At the end of the webinar, I was left wondering: How does Assembla fit into the Continuous Delivery Pipeline? Stay tuned, more to come.

To Learn More about Continuous Delivery checkout some of my other blog postings:

Continuous Delivery vs Continuous Deployment vs Continuous Integration 

Distributed Continuous Integration - Keep the Mainline Clean 

Avoiding Premature Integration or: How we learned to stop worrying and ship software every day

You ever have those really good ideas, create a product or website around it, and no one cares?  That is what is happening with the Custom Tab at Assembla.  It’s about my favorite tool in the stack there, since I can use it to extend Assembla functionality and tools without doing anything.  

Our team used to have a bunch of tools all over the place, New Relic for monitoring our application, Nagios for monitoring our servers, Jenkins for our CI, Kibana for log aggregation, and even a custom application for showing off our Developer stats.  We had documentation to let everyone know where each tool was.  It was tedious and annoying to keep up to date and inform everyone where to go next.

Instead, I put them in Custom Tabs:

Now, when we add a new tool to our stack, its immediately available and visible for all our developers to use from within the Assembla project.

Ideally you are able to use authentication integration so that being logged into Assembla also has you logged into the other service or tool removing the need to double login, but typically this is not an issue as you would have to login again for another browser tab.

We also just added the favicon as default to Custom Tab tabs, I hope you enjoy this feature as much as me. To try this out yourself, visit the Admin tab of your project > click on Tools > and Add the Custom Tab Tool. 

To Check Out More Cool Features and Tools - www.assembla.com

It's not a coincidence that the RallyON welcome reception has a three-ring circus theme. The circus part seems natural, given the challenges in herding people, process and technology (another three) to align toward a common objective. Transforming into an Agile organization takes the skills of a lion tamer, the orchestration of a ringmaster (hello, ScrumMaster!) and the acrobatics of the high-flying trapeze performers. But when it all comes together, the energy is palpable. The crowd oohs and ahhs, and all are amazed. OK, so perhaps a bit dramatic for real-world Agile, but many have witnessed faster delivery and more motivated people with high-performing Agile teams.

Setting aside the circus metaphor, let's look at the number three. For this year's RallyON, we centered on where organizations derive value: people, the largest source of intellectual property, the processes that drive effectiveness, and the technology that facilitates communication, collaboration and visibility. Threes abound.

And, as the wise say, good things come in threes, so it's no coincidence that RallyON is also three days long. Three days of in-depth technical sessions, Agile 201 training from our Rally experts, practitioners sharing their stories of success and the obstacles they met along the way, tracks dedicated to transformative Agile in leadership and collaboration, and an open space marketplace where visionaries meet to exchange ideas and innovate. We'll come together to learn and contribute -- and walk the tightrope that is the path to an Agile organization. Come join the circus, at least for one night.

Rally Software

What’s exactly the product backlog grooming in Scrum When reading most of the suggested books about scrum, the grooming technique is often cited, but it is not officially normed as a scrum meeting or technique. This lack of officialization, in my opinion, is an important cause of uneffectiveness in product backlog management and adjustment and, [...]

In a Scrum context, the definition of a “spike” is “a story or task aimed at answering a question or gathering information, rather than at producing shippable product.” In this article, Bill Ambrosini discusses how to manage them and when to use this activity. Spikes might be used for reducing technical debt or creating a “proof of concept”. They should have two major characteristics: 1. Have clear objectives and outcomes 2. Be timeboxed Some of the smells that might indicate that you need a spike are: * The team has difficulties to estimate the stories * ...

Atlassian has unveiled the latest version of JIRA, its project and issue management software used by more than 19,000 companies worldwide. Wrapped in a brand new, modern user interface, JIRA 6 features faster navigation and editing, simplified workflow creation and powerful mobile functionality so teams building software can get more done with less effort. To get teams up and running quickly, JIRA 6 is available OnDemand – Atlassian’s cloud offering – or behind the firewall starting at just $10 for 10 users. “We built JIRA 6 to make every software development ...

Der Stare down, das Blickduell, ein spektakuläres Ritual. Zwei Boxer stehen sich Tage vor ihrem Kampf für ein paar Augenblicke gegenüber. Auge um Auge. Kein Ausweichen. Elektrisierende Spannung. Regloses Anstarren, keine Miene verziehen. Wer den Blick senkt, hat sich eine Blöße gegeben und gilt als der Schwächere. Über dem anderen stehen, ihn im Status überragen, ihm zu verstehen geben, dass man überlegen, besser, mehr ist und bereit, den Kampf jederzeit aufzunehmen.

 

Das Thema “Status” (= Stand, Stellung in einer Gruppe oder Gesellschaft) und im wahrsten Sinne des Wortes seinen Mann oder seine Frau stehen, spielt ähnlich wie in dem Beispiel oben auch im beruflichen Alltag eine tragende Rolle. Fragen wie “Wer steht über wem?”, “Wie viel bin ich, wenn ich wie viel Menschen führe oder plötzlich nur noch halb so viele?”, “Hab ich einen eigenen Firmenparkplatz?”, “Ist mein Bürostuhl in meinem Einzelbüro mit Lehne ausgestattet oder noch ohne?” Petra Klapps umschreibt “Status” in ihrem Buch “Das Kolibri-Prinzip – leicht und spielerisch Ressourcen stärken“ als ”soziales Niveau. Das ist die Art und Weise, in der wir unseren eigenen Wert zu anderen Menschen in Beziehung setzen. Status ist immer von Werten und Spielregeln einer Gruppe oder einer Kultur abhängig. Nicht nur im Berufsleben, auch im Alltag stellen wir zu Menschen unbewusst oder auch sehr gezielt ein Statusverhältnis her. Dieses Verhältnis beeinflusst gravierend, wie wir (…) uns zueinander verhalten. Wir platzieren uns ständig auf einer Werteskala im Verhältnis zu unserer Umgebung. Wir nehmen keinen festen Platz ein auf dieser Werteskala, sondern wir wechseln unseren Status und unser Sozialverhalten (…). Jeder Mensch verhält sich anderen Leuten gegenüber entsprechend seinem eigenen Status. Wir signalisieren die ganze Zeit über unseren Platz in der Hierarchie, indem wir anderen gegenüber einen höheren oder einen niedrigeren Status einnehmen” (a.a.O., S. 136). Klapps postuliert, dass beinahe jede Kommunikation mit unserem Gegenüber etwas mit Konkurrenz zu tun hat und der Klärung der Frage, die einem (Status-)Kampf gleich kommt: Wer wird wen verändern?

Verhaltensweisen, die Status sichtbar machen können – ein Must für gute ScrumMaster

Ich halte es für eine herausragende Fähigkeit, Statusverhalten wahrzunehmen. Gerade ScrumMaster in ihrer besonderen Rolle als Servant Leader, als Führungskraft ohne Anspruch auf Autorität, brauchen hierfür äußerst sensible Antennen. Wie wirke ich in der Rolle als ScrumMaster? Wie sehen mich andere? Was verschafft mir meinen Status im Team, gegenüber anderen ScrumMastern, gegenüber dem Linienmanagement? Es gibt eine Vielzahl von Informationsquellen, die sich ein ScrumMaster zunutze machen kann, wenn er herausfinden möchte, welchen Status er in einer Interaktion gerade einnimmt. Dazu sollte er den Fokus seiner Wahrnehmung in erster Linie auf sich richten und überprüfen, was seinen Status wirklich ausmacht. Alles hat und zeigt eine Wirkung und kommt beim Gegenüber an.

 

So logisch das klingt, so wichtig ist es, es sich bewusst zu machen. Dabei geht es auch weniger darum, ob man mit seinen Verhaltensweisen richtig liegt. In erster Linie zählt die Selbstwahrnehmung und die mögliche Wirkung auf andere. Ich verstehe dabei insbesondere die Wahrnehmung des eigenen Handelns als echten Quantensprung. Wie ist mein Gang? Wer berührt wen (Körpernähe – oftmals ist nur der Person mit dem höheren Status gestattet, berühren zu dürfen)? Wer nimmt mehr Raum ein (Sitzposition, Redeanteil, etc.)? Wie wird mit dem Thema Zeit verfahren (wer lässt wen warten, werde Zeiten eingehalten, wer überschreitet die Timebox)? Wie ist der Tonfall in einem Gespräch, wie ist die Wortwahl, gibt es Unterbrechungen und wer unterbricht wen? Wie stehe ich im Raum (über anderen, weit entfernt)?

Wie ist nun mein Standing im Team? Welchen Status genieße ich als ScrumMaster? Informationen gewinnt man darüber am besten, indem man konsequent und ehrlich hinterfragt, mit welcher Haltung man anderen Menschen begegnet und wie die Art und Weise von Kommunikation gesehen wird. Man unterschiedet hierbei

• einen positiven/natürlichen Hochstatus, mit dem man Begriffe verbindet wie Freundlichkeit, Klarheit, Einfühlvermögen, Bescheidenheit, Kompetenz, Vertrauenswürdigkeit oder Geduld. Vereinen sich viele dieser Attribute in der inneren Haltung und der Art und Weise der Kommunikation, dann wird diesen Menschen oftmals Anerkennung, Wertschätzung und Respekt von ihren Interaktionspartnern entgegen gebracht.

• einen negativen Hochstatus, mit dem man Attribute wie Egoismus, Eitelkeit, Arroganz, Ungeduld oder Launenhaftigkeit verknüpft, erzeugen eher Widerwillen und (versteckte) Aggressionen beim Gegenüber.

• einen positiven Niedrigstatus, der sich in Hilfsbereitschaft, Flexibilität, Zuverlässigkeit oder Kreativität wiederfindet oder
• einen negativen Niedrigstatus, der das Ergebnis von Unzuverlässigkeit, Gleichgültigkeit, Widerwillen, Unnachgiebigkeit oder Sturheit ist.

Natürlich stehen diese vier Statuserläuterungen und die beschrieben Typologien nicht für stereotype Definitionen und kommen darüber hinaus fast immer in Mischformen vor bzw. sind ebenso situationsabhängig. Es sind dennoch Orientierungspunkte, die eine Idee vermitteln sollen, welchen Einfluss Verhalten auf den Status innerhalb einer Gruppe, einem Team haben kann. Wer nun einen Vorgeschmack darüber erhalten möchte, welches Standing Teammitglieder untereinander oder aber ein ScrumMaster im Team hat, vielleicht auch, welches Standing man selbst genießt, dem empfehle ich als Startpunkt die nachfolgende Übung.

 

Wie ist mein Standing? 

Teilnehmerzahl: je mehr umso besser

Vorbereitung: Es braucht eine kleine Freifläche, die als Bühne genutzt werden kann. In der Mitte der Bühne wird ein X auf dem Boden markiert. Alle Teilnehmer sitzen mit Blick zur Bühne (Kinobestuhlung). Neben der “Bühne” ist eine Sitzgelegenheit (Warteposition). Darüber hinaus braucht es einen Moderator.

Material: Kreppband für Markierung, Kinobestuhlung

Ziel: Die Teilnehmer

 

Ablauf: Der erste Teilnehmer betritt die Bühne und nimmt auf dem Stuhl neben der Bühne (Warteposition) Platz. Wenn er/sie für sich selbst entschieden hat, bereit zu sein, tritt der Teilnehmer auf die Bühne und stellt sich auf das markierte X. Er nimmt mit seinem Blick Kontakt zum Publikum auf und steht dort solange bis der Moderator nach 30 bis 40 Sekunden zu dem Teilnehmer gewandt sagt: “Ja, bitte?” Der Teilnehmer nennt seinen Namen. Im Anschluss daran applaudiert das Publikum und der Teilnehmer nimmt wieder auf dem Stuhl neben der Bühne Platz.

Das Publikum gibt dem Teilnehmer zu seinem Auftritt bzw. “Standing” Feedback. Das Feedback sollte wertschätzend sein und keine Negationen enthalten (z.B. du sollst nicht mehr). Sprecht euer Feedback in Ich-Form aus (z.B. ich habe beobachtet/wahrgenommen, dass…).

 

Das Wichtigste kommt meist zu kurz: das Debriefing in sechs Schritten

Die Übung soll natürlich nicht für sich alleine stehen, sondern einen gewinnbringenden Abschluss haben. Auf der Bühne stehen ist das eine, ein Feedback erhalten inkl. Debriefing das andere und ebenso Wichtige (= die gemeinsame Beschreibung der Erfahrungen, die das Team in der Übung gemacht hat. Dies beinhaltet ebenso die Auseinandersetzung mit deren Gedanken, Gefühlen und Reflexionen zur Umsetzung ins Business). Häufig kommt genau das in Übungen viel zu kurz. Eine Übung sollte nie für sich alleine stehen.

 

Eine gute Struktur für ein aufschlussreiches Debriefing kann so aussehen:

 

Schritt 1: Wie hast du dich gefühlt? (Beschreibung der Emotionen während der Übung. Es wird deutlich, wie unterschiedlich die gleiche Situation empfunden und/oder bewertet werden kann)

Schritt 2: Was ist geschehen? (Austausch von Wahrnehmungen und Beobachtungen)

Schritt 3: Was hast du gelernt? (Identifikation der Erkenntnisse und Schlussfolgerungen)

Schritt 4: Wie hängen die Übung und die Realität zusammen? (Transfer zwischen Übung und Realität. Achtung! Unterscheidung, ob das Verhalten aus der Übung zufällig oder einmalig war oder in Beziehung zur Realität und dortigen Handlungsmustern steht)

Schritt 5: Was wäre gewesen, wenn? (hypothetische Szenarien – optionaler Schritt: Spekulation über hypothetische Szenarien)

Schritt 6: Wie geht es nun weiter und was mache ich mit den neuen Erkenntnissen? (Festlegung von eindeutigen, machbaren, messbaren Zielen und Maßnahmen für das zukünftige Verhalten inkl. Mechanismen für Feedback und/oder Follow ups)

 

Viel Spaß beim Ausprobieren. Eure Kommentare zum “Standing”, wenn ihr euch mal in eurem Team ausprobiert habt, würden mich brennend interessieren.

 

 

Literatur

Klapps, P. (2012). Das Kolibri-Prinzip. Leicht & spielerisch Ressourcen stärken. Kreuz

Related posts:

1. Und gib uns unseren täglichen Status…
2. Der ScrumMaster: Status, Position, Rolle
3. Nein! Es gibt keine BI-Projekte!

A few weeks ago Michael published a post called Product Software Development Is a Marathon. The message of this post is: if you want to come up with a decent product, you’ve got to brace yourself up for a long-distance marathon run. I agree to the point of long-distance and endurance, but I’d rather compare this not to a marathon but to a triathlon race.  Triathlon requires diverse skills, you not only have to run, but to swim and to bike, and, as we know, good software developers need diverse skills, too. By the way, quite a few IT guys I know, they do triathlon as a hobby, so there really must be something to it. As in triathlon, diverse skills needed to develop a software product require that you keep up your endurance with all of them, learning to alternate your activities, such as coding, researching, coming up with solutions and empathizing with others while keeping a workable race rate. Success in a  faster-faster-faster race comes as a by-product of following some smart endurance tips and tricks. Our brains are our most indispensable tools, and we need to exercise a caring attitude to them… and to our colleagues’ brains, too. I’m saying this time and time again: there’s nothing ever more important to us as professionals than taking good care of our brains (well, and bodies, obviously, because brains work better after some good physical exercise, and that’s apparently what the folks that do triathlon are sensing as well :) . I’ve touched upon that subject one way or another in a number of my previous posts, and this caring attitude would ideally stem from the company’s culture in many subtle ways. It’s a paradox, but very often we’re unaware of how those small bummers at work are killing our performance and draining our cognitive powers. For quick reference, cognitive is anything related to mental processes: attention, memory, talking, listening, learning, reasoning, problem solving, and decision making. This diagram shows the interrelated network of the processes going on in our brains as we work. If you come across some bummers disrupting those processes, the performance of your brain wanes for any given day at work, and unless you do something non-mental for a change (like, hang out with your family, or do some triathlon training), your brain powers would not restore just so.

The insidious sources of cognitive bummers can be broken down into 3 groups:

• Process-related. Anything that has to do with the glitches and communication issues arising from a sloppy development process, e.g. too many meetings, unfocused online messaging as opposed to face-to-face talks, not knowing who to go to and where to report to if there’s an issue that needs to be solved. These would be purely cognitive disruptions.
• Workspace-related. That’s more about the general feeling good, although in the end it boils down to cognition, as all those kinds of workspace-related stresses would end up in the brain as well. What if someone prefers to sit with the air-conditioning off and just with the flow of fresh air? Or the lights? What if someone prefers natural light to the LED lights? The most notorious workspace-related disruption wouldn’t be the lights or air, though. It’s the noise produced either by colleagues discussing a solution to a problem, or can be some of them wants to listen to music from the speakers while a few others prefer to work just quietly. Workspace-related disruptions depend on personal sensitivity. Someone can sense them very acutely, feeling that this something is really tiring their brain. Others may be unaware of the direct impact, but they are affected all the same, regardless of the awareness or unawareness. I wish everyone could have such a plate by their desk:

• Individual. This is about personal time management skills and will power. Things like: if you start your day with Facebook, or browsing news, or reading some casual stuff, don’t be surprised if you’re drained by noon, when it occurs to you that you never got down to doing the things that would actually make you call your day a productive one.

Of those 3 kinds of disruptions, the first two are enrooted in the company’s culture, and need to be cured at a company level first. In fact, if a company nurtures the culture of keeping everyone’s flow and takes care of the good workspace, then it’s a lot easier for people  to perform at their best on an individual level. I mean, not everyone is a personal productivity guru. Well, of course, it’s in one’s own power to stay away from all kinds of online time wasters, and do things successively, one after another, but it’s a company who can literally lend a helping hand and contribute a lot to cutting down on multi-tasking as much as possible.  I will write more about those disruptions, and what can be done to tackle them both at a company level and at an individual level in my future posts.

 If you have more than 30 open tickets, you will need a good way to filter them by feature, team, or client.  You should use the new Tag feature.

Adding Tags

Now, you can enter tags on a Ticket.  As you add tags, you will build a tag cloud in your popup tag selector.

Using Tags

You can use these tags to see the tickets that you want to work with.

In the LIST view, you can quickly open the sidebar and select a tag.



On the CARDWALL, the tag selector makes it easy to see the current tasks for a team, feature, or client.

On the PLANNER, you can quickly select a tag (on top of the new column).  You will see backlog and current tickets that match that tag.  The shorter list will be much easier to sort, and your new tickets will automatically match your tag.  What happens if you sort the tickets in this filtered view?  We put a lot of work into an algorithm that we call “ladder sort” which keeps the same slots in the big list by swapping tickets in the filtered list.

Why use Tags?

You can tag and filter your tickets  with  a custom list field, or “component”.  Why use tags? 

* You  can add multiple tags tags to one ticket.  So, you can easily tag a ticket as being from Client A, for Feature team 1. In the old system, you would need to create two custom fields to do that, and you would need  to plan those categories in advance.

* Users can add new tags when they need them.  You want a limited number of tags so that the tag cloud will be readable, and so that you do not have to hunt through too many tags.  So, we give you the option of marking tags as “hidden” from the tag selector.  They are still available for the team members that need them.

* We are using tags as  quick filter on top of cardwall and planner.

Getting Started and Administration

You can add tags to tickets as you need them.  Then, you can start using the tags in the list filters, Planner, and Cardwall views.  After you have a coherent set of tickets for a client, project, or a team, you can make child project views in Space Manager.

Or, you can manage your tags to add better structure.  As a space owner, you can add and manage tags in the ticket settngs view.  You can “hide” tags that are not used very often, and keep your tag selector clean.  You can use batch update to apply tags to your existing tickets

Working with multiple teams on one big project If you have a big project, you might have multiple teams, and when each team comes to the cardwall, they will want to select their view.  They will want their own default view.  They will also want to have discussions and share code reviews without seeing a lot of noise from other teams.  It’s not easy to manage a big project inside one Assembla space.  So, we just added a major new feature called “Space Manager”.  This feature allows you to create a child space, (like a subproject) where a team will see only a relevant set of tagged tickets.

When you create a child space in the Space Manager, you select the tag a tag for that child space.  It will show tickets with the related tag.  You can also create new tools, or share tools with the parent space.




Each team lead, works prioritizing their work in the child space view, while our VP and CTO work on the master space that holds all child space tickets.  This gives you a way to break out of one space and make your project much more expandable.
One team working with many clients or systems

Do you have one team or designer that is working on requests from multiple clients or projects?  In most agile planning systems, it is difficult to prioritize these requests.  You need separate collaboration spaces and separate planning sessions for each project.  What you want is a system that collects all of the requests in one place, so you can prioritize  them into one backlog. 

With Space Manager, you can create a child space for each client or project.  Then, invite the stakeholders to the child spaces.  They can add tickets and sort tickets and discuss tickets.  Those tickets will automatically be tagged with the selected client tag for that child space.  The client stakeholders will not see activity from all of the other clients or projects.  However, in the parent view, you

For maximum scalability, you can use both forms of organization at the same time.  You can take tickets from client spaces, and distribute them to team spaces.  If you have a Portfolio plan, you can create a child space for each of your clients. From the parent space, you can add a tag for the feature team that will work on that client request.



In this way, you and your client will be updated in one space, and the dev team can start to work on it right away in a different space.

Getting Space Manager

Want to try the new Space Manager for handling big backlogs from multiple teams or clients?  It is in the new Portfolio feature pack.  You can now add a Portfolio Feature Pack to your subscription for a reasonable, fixed price. The user who is set as the Payer for your Assembla account can easily add the Portfolio Pack now in their Account page.

As recently as this week, I’ve been involved in conversations with customers about how we can help make their teams deliver more predictably.  How can they meet commitments on all levels of the organization, including project, program, and portfolio?

Well, it’s not easy.  There is no silver bullet that is going to allow you to align the organization overnight.  I do, however, have one recommendation:  Stop trying to maximize the utilization of your people.  I know some are going to find that hard to understand.  To maximize value throughput, you need to keep your people as busy as possible, right?  Didn’t Henry Ford do it that way, when he had cars coming off the assembly line at three-minute intervals?  Actually, no, he did not.  What he had and what you need is a balanced system.

Henry Ford did not have everyone working at 100% utilization.  If everyone worked at 100%, the result would have been congestion — bottlenecks within his (assembly) system and the production of excessive parts inventory.  Instead, one of the many things he did was focus on limiting lead times.  That’s the time something waits before an activity happens.  By understanding his system, he was able to have the right amount of people, working at the right pace, in the right sequence, in order to maximize flow (delivery through the system).

When trying to get your teams to delivery predictably at your organization, let’s look at this from a 100,000 foot view:

• Understand Current and Potential Capability and Capacity
• Understand the Delivery System and Establish Goals
• Balance Capacity and Capability with delivery throughput
• Monitor Performance

That is how you establish predictable outcomes.

No let’s look at this with some detail.

Understand Current and Potential Capability and Capacity

You’ve probably heard the analogy of a freeway being a value delivery system.  If not, let me draw the parallels.  On a freeway, we don’t care about utilization; we care about throughput. That is, we don’t care how many vehicles can fit onto the freeway. We care how quickly we get from point A to point B.  Measuring the capacity of the freeway is not going to directly help us. Measuring the throughput will.  For those who follow Lean Startup, these are referred to as vanity metrics and actionable metrics.

Actionable metrics can lead to informed decisions and subsequent action.  Example, I know how fast the vehicles travel on a given freeway, therefore I can plan accordingly to arrive on time.  Vanity metrics show that you’re measuring things, but they really aren’t helping you. You need to measure the right things.  By measuring the capacity of a freeway and then trying to fully utilize it would be foolish.  Strangely enough, I see organizations do that with their people all the time.  They try to keep them as busy as possible.

Understand the Delivery System and Establish Goals

We don’t build bigger freeways so they can hold more vehicles.  We build bigger freeways because we’re not smart enough to figure out how to limit the size or amount of vehicles on them at the same time.  The fewer or smaller the vehicles on the highway at the same time, the faster everyone moves along.  To increase throughput (speed) on a freeway, you need to increase the ratio of space utilized by a vehicle relative to the total space of the freeway.  If we could increase the (distance) buffers between the vehicles, we’d have fewer start and stops along our commutes. Once we hit higher utilization rates, things dramatically slow down until we have traffic jams.

Balance Capacity and Capability with delivery throughput

It’s the same thing with knowledge based systems!  Exceed a 70% utilization rate and you’ll begin to see dramatic performance decreases.

One thing that I have seen that is bringing it together is enabling teams to make their own commitments.  Once they have a sequenced queue of work and all the people necessary to complete that work, allow them to commit to, start, and then finish it.  You should begin to see the flow of value start to emerge.  Don’t pull people from the team to give them “busy” work.  Don’t push extra work on the team to keep them busy.

Monitor Performance

You can tell if your people are over-utilized by measuring the lead times.  If their work is properly sequenced, and they limit the size and volume of work they agree to do at any given time, the result should be minimal delays.  If you want to go faster, you may have to change the system.  Measure how long it takes to get something through your system.  Reflect on that.  Were there any dependencies on other people or resources that slowed you down?  Did you have your people over-utilized?  Was the work you committed to too big?  Look for an area of possible improvement, address it, and run work through your system again.  Did the lead time get shorter?

Going back to the commuting analogy, for those doing the driving, understand the conditions and know the optimal start time to begin your commute in order to avoid delays and arrive at your destination without breaking any laws.  For those asking for arrival commitments, respect what the driver tells you.  If you don’t, you’ll find people doing things like driving on the shoulder or illegally speeding in the express lane, just to arrive on time.  Sooner or later, there’s going to be an accident.

 

The post Getting Teams to Deliver Predictably appeared first on LeadingAgile.

Scope creep is a term that I see being used by Scrum teams. I've always wondered if this term smacks of inadequate Scrum implementation. It's an indication of traditional project management that's disguised in the appearance of Scrum. To explai...

Auf meinen vielen Reisen habe ich stets die beste Möglichkeit zu reflektieren. Sei es im Zug, Taxi, Bus, Flugzeug oder in der U-Bahn – ich genieße es, diese Zeit damit zu überbrücken, dass ich meine Gedanken über die letzten Stunden schweifen lasse. Im Zug von München nach Oldenburg reflektierte ich letztens über das Team Booster Training, das ich in den letzten zwei Tagen bei Dieter Rösner absolviert hatte. Wir waren eine spannende Gruppe (bestehend aus zehn Männern und mir als Quotenlady), die durch die Teamentwicklungsübungen innerhalb von 16 Stunden Training, einem Sushi-Dinner in der Innenstadt und einem Absacker-Weizen an der Hotelbar langsam aber stetig zusammenwuchs. Die erste Übung, die wir jedoch als „Team“ durchführen hätten sollen, war der Sin Obelisk. Diese Übung wird mir noch eine Weile in Erinnerung bleiben.

 

In diesem Spiel geht es darum, anhand von (teilweise unnötigen) Informationen auf Spielkarten eine einigermaßen simple Rechenaufgabe im Team zu lösen. Das Spiel zeigt die Dynamik von Teams sehr gut auf. Wer mehr zu diesem Spiel erfahren möchte, kann es gerne hier (http://www.teamentwickler.eu/sin-obelisk) nachlesen.

 

Unsere Durchführung war das reinste Chaos. Da ich normalerweise aus dem Blickwinkel des Coaches ein Team beobachte, fand ich es spannend, mal Teil eines DevTeams sein zu dürfen. Oh boy, hab ich das schnell bereut! Obwohl ich nun doch ein Weilchen im agilen Umfeld tätig bin und schon einige Teams gesehen habe, verlief die Kommunikation und Rollenteilung letztendlich so chaotisch, dass ich mich mental komplett ausklingen musste und die Hälfte des Spieles nur von der Seitenlinie aus zusah.

 

Weshalb kam es dazu? Und weshalb hat niemand darauf reagiert, dass sich ein Teammitglied abseilt? Oft gibt es keine simple Antwort auf diese Frage, doch in diesem Fall schon. Zwei Themen spielten darauf ein: Rollentrennung und Misskommunikation. Der ScrumMaster war kein ScrumMaster, sondern agierte stattdessen als DevTeammitglied. Das DevTeam hat es – u.a. als Resultat daraus – nicht geschafft, auf einer Ebene zu kommunizieren. Die Liste an Frustrationen, die innerhalb von 40 Minuten aufgrund dieser zwei elementaren Fehler zustande kamen, ist lang.

 

Hauptproblem: Kein gemeinsames Ziel

Die Fragestellung der gewünschten Lösung war einigen Personen bis zum Schluss unklar. Die (mangelnde) Visualisierung wurde nur dank eines Dev.Teammitglieds gestartet. Der ScrumMaster war Schriftführer und Rechenmeister zugleich. Die Konversationen liefen kreuz und quer. Wenn eine Frage auftrat, wurde sie nur zur Hälfte beantwortet, da sich alle ständig gegenseitig unterbrachen. Unnütze Informationen, die schon als solche identifiziert worden waren, wurden weiterhin öfters in den Raum geworfen. Der Kunde wurde nicht eingebunden. Obwohl eine (falsche) Lösung in der Hälfte der Zeit ausgerechnet wurde, verschwendeten wir die gesamte Timebox (Sprint), statt den Kunden früher um Feedback zu bitten. Als ein Dev.Teammitglied für (Kommunikations-)Ordnung sorgen wollte, kam eine direkte Ansage vom mitentwickelnden ScrumMaster: „Ich bin hier der ScrumMaster.“ Das i-Pünktelchen war für mich erreicht, als ein Einzelgänger im Dev.Team die korrekte Antwort fand, diese vom Kunden bestätigt bekam und das Team in seiner Dynamik weiterhin auf seinem eigenen, aber falschen (Rechen-)Weg beharrte.

 

Die multiplen Vergleiche zu einem echten Scrum-Team werde ich nicht explizit aufzählen. Die kann man schnell erkennen bzw. spätestens nach dem eigenen Ausprobieren der Übung vermutlich bestätigen. Doch eines möchte ich hervorheben: Unsere Ausübung des Sin Obelisks hat die Wichtigkeit der ScrumMaster Rolle auch für alle Skeptiker verdeutlicht. Hätte der dezidierte ScrumMaster seine Führungsrolle komplett eingenommen, hätte er darauf geachtet, dass das WAS klar ist, bevor wir uns in das WIE stürzen. Er hätte jedem eine Stimme gegeben und das Kommunikationschaos entbündelt. Das Feedback des Kunden wäre frühzeitig eingefordert worden und er hätte sich über jeden Verbesserungsvorschlag aus dem Team gefreut. Und so wären wir gemeinsam und vermutlich schneller zur Lösung gekommen – ohne dass ich von der Seitenlinie zuschauen musste und ein Dev.Teammitglied die Lösung alleine fand.

 

Doch eines muss ich dem ScrumMaster lassen: In der anschließenden Retrospektive war er sehr reflektiert und äußerte viel Selbstkritik. Hätten wir die Übung ein weiteres Mal spielen können, bin ich mir sicher, dass wir eine eindeutige Verbesserung erzielt hätten. Und nicht nur, weil wir die richtige Antwort dann schon kannten…

 

Termine zu den nächsten Scrum Supplements Trainings mit Dieter Rösner findet ihr hier.

Related posts:

1. Der ScrumMaster ist eine Versicherung (Mike Beedle)
2. Fussball EM und 3 Sprints | Scrum ist überall !
3. ScrumMeetings moderieren oder „ein ScrumMaster hat nichts zu tun“

I gave a talk at Devs in the ‘Ditch last week when I was in London. I posted the slides on slideshare: Overcoming Three Pitfalls of Transitioning to Agile.

The very nice people at 7digital made a video and posted it, too. If you can take the time, watch the entire video. Rob Bowyer gave a great talk about kanban and theory of constraints. My part about overcoming these three pitfalls starts at about 42 minutes in.

There are many other pitfalls to transition. This talk had just three of them: the stories are too big, you need experts to do the work, and you implement as layers instead of through the architecture.

I hope you enjoy the presentation and the video.

 

If you are someone who is passionate about agile, the word “Waterfall” is usually used in a derogatory manner or, at least, when you use it — you are making the stink eye. On the converse, if you are someone who practices what is popularly known as “Waterfall” Project Management, you generally get offended or defensive when the word “Waterfall” is used.

Here’s how the conversation plays out:

Agile practitioner:  ”There’s no way I’ll ever work on a Waterfall project.”

Waterfall practitioner: “There’s no way I’ll ever work on that Agile project.”

Agile practitioner: “Waterfall projects are never successful and I hate being told what to do.”

Waterfall practitioner: “Well at least we do work and don’t practice that Agile witchcraft and all that kumbaya mumbo-jumbo.”

Agile practitioner: “Well, your mama said Waterfall is for losers.”

Waterfall practitioner: “Don’t be talking about my mama!” …

[Chaos ensues]

 

The sad part about this dialog is that although it’s somewhat fictitious, I’ve heard similar arguments at organizations and with colleagues who work across all spectra of the project management continuum. The funny part about the dialog above and, in particular, the word Waterfall — is that no one is really clear who started calling it Waterfall. It’s obvious that when diagramming out a sequential process, it looks like a waterfall:

Often, people credit Dr. Winston Royce with Waterfall project management, especially with respect to software engineering when, in 1970, he wrote a part in a white paper that describes this approach (read it here). The funny thing is that he goes on in that same white paper that is credited for starting the Waterfall practices to describe how risky it is, and that, in order to mitigate the risks, each stage of the Waterfall process should do things iteratively and incrementally.

Waterfall project management is really Sequential Project Management. Meaning we perform a sequence of activities and there are generally stages, maybe with sign-offs, and usually hand-offs, to another group of people who are charged with performing the next sequence and consuming the output of the previous sequence. Some refer to this as Traditional Project Management, but in most environments its called Waterfall.

I’m not going to discuss the differences between the two and which approach I think is better — it should be clear since you are reading an agile blog. I will say that I think that the merits of each approach are obvious and each approach has challenges. The usage of one approach over the other really depends on the project and possibly the people engaged.

What I am going to say is that, in the world in which we all live today, it is very likely that we’ll have a mix of projects using a more of an agile approach and one using more of a Sequential approach. Sometimes we’ll have to join forces and combine the output of these approaches into one. Of course, we are learning and adapting ways to do this, but that too is another discussion altogether.

Let’s face it, when words start dividing people, we probably shouldn’t use them any more. Instead call the project management approaches what they are – iterative and incremental, or sequential, or continuous, or simply ad hoc. Also, be aware that the moniker we place on people isn’t really on the people; it’s on the processes by which they may operate in — and they may be really comfortable in that process. Generally, they’ve put in a lot of blood and sweat to make it work. Sometimes we need to put the monikers aside and focus on “individuals and interactions over process and tools” (crazy how I got the Agile Manifesto into this blog, isn’t it?).

For now on, be aware and call it Sequential Project Management or even Traditional Project Management — unless you want to get in an argument about “your mama.”

Integrated Git issue tracker

Forget about setting up a Git repository and an issue tracker locally only to have an integrated Git repository with a bug tracking system to run your software project.

With Assembla, you have an integrated system at your fingertips - just install a Tickets tool and a Git tool to your Space - that’s it, you are done setting up, let the work begin. Out of the box, you will be able to reference tickets from your commit messages - just write “re #1” in your commit message and a link to the commit will appear on ticket #1.

• Change ticket statuses - just naming a ticket status - “Fixed #1” - will place a link in the ticket to the commit and change the ticket status to Fixed.
• Track time - enter a record of how much time you spent working on a particular task by using  “Fixed #1 Time: 1h30min” to your commit message.

Want more integration? Are people making commits to the repository, which you can’t trace back? Well, we have a solution for you. With our new custom server side hooks feature you don’t need to ask everyone to create a pre-commit hook on their machine. Just install a server side hook to your repository to reject the commits that do not contain a ticket reference - nobody will be able to push a new commit that is not related to a particular ticket. Even more integration?

Need more automation in your workflow? You can write your own server-side hooks, which we will review and put on our servers for you to install. Just send us a merge request!

Get your free Git repository with an issue tracker here.

In my journey from a small town and poor farmer family of India to the Big B's (Bosses) of the world's largest corporations, I've seen some strange behaviors. Whenever I set up an Agile transformation workshop or an Agile center of excellence i...

I’ve been noodling on the phrase “Thinking Together”. Thinking Together is one aspect of the mindset that Product Owners need to embrace. I have been using this phrase with new Product Owners to explain why many Agile practices work. But each time I start to write about this simple idea, it gets complicated because I get into process steps and roles and responsibilities.

Yesterday, I returned to a big company with a pretty complex product portfolio where we had done quite a bit of work including starting up multiple Scrum teams. I recalled our first release planning with this group. There was a lot of uncertainty and even some anxiety about this “lightweight” approach.

They were missing their requirements and specification documentation. They were hesitant to assess the value and size of the features, concerned they might leave something out. I prepared a Release Planning agenda for them to follow. I also prepared a list of roles and responsibilities. And I had some one page cheat sheets on the activities for release planning. They needed some process rules initially to learn how to think together.

When I ran into a Product Owner from this big company months later, the changes they had made were obvious. He was facilitating release planning and was excited to walk me through it.

My friend the product owner brought me into the conference room where they were wrapping up their release planning. There were some product managers, the product owner, some tech leads, QA and even a project manager. They were taking a break chatting and smiling. There were some architectural sketches on the white board. There were four flip chart sheets with sticky notes representing epics and features. The flip chart sheets represented the work completed for the past release, the plan agreed to for the next release, and planning for the following release. They had one more sheet with parking lot items.

The product owner showed me the result of their Thinking Together. They had discussed the epics written on blue stickies and wrote all the features they might need on purple stickies and put them under the epic. Then they thought together some more and rated each feature with business value, complexity and sizing. They added some acceptance criteria and clarified assumptions as they went. They did this for several epics. Then they started adding features to the flip chart sheet representing the next several releases.

Now, they realized they would not get everything done that the product managers wanted. So they moved some lower value features to the parking lot and rearranged the features on the flip chart sheets until they agreed on a plan. By Thinking Together in planning the next couple releases, they pretty quickly learned together and gained a shared understanding of the work they would do for the next six months.

They had learned to Think Together to get the end result: a solid release plan.

 

 

 

The post Thinking Together for Release Planning appeared first on LeadingAgile.