Skip to content

Feed aggregator

Compromises in setting up teams in a scaled framework

Scrum 4 You - Thu, 09/18/2014 - 07:16

Making the first steps in setting up a scaled framework with agile teams in a complex environment does not always allow to set up teams by the book. Rather than dragging people from their current activities and having everybody dislike agile, before we have even really started using and living it, I try to make compromises.

By working in very short sprints of one week, I allow team members to switch between teams with every start of a new sprint. For the one sprint however, they commit to be fully engaged in the sprint backlog and team activities of the one single team. Product owners can plan with the team members’ knowledge for some sprints. The team can make the experience i.e. every other sprint what they are capable of on their own and build confidence and see where they still need more knowledge transfer and help. Multi skilled team members can learn step by step to let go their „baby“ and still be engaged in the field of the product.

An alternative in the same situation might be:
If there is a huge overlap in skills needed for one and the other team or part of the product, try putting the teams to either being one team. Build rather large teams in the beginning covering two backlogs (should not be more). Creating a team backlog rather than a product backlog allows the others to learn about the other parts of the product by just being in the team and does not force team members to leave one or the other part of the product without their experience and knowledge.
Forcing the teams into a decision for one or the other might lead to the opposite – double work by only making one part transparent or frustrated „left alone teams“ and multi skilled team members with feelings of guilt.

What else have you tried?

Related posts:

  1. Sprint Planning with geographically dispersed teams located in different timezones
  2. Scrum Teams – No Part Time!
  3. How internationally distributed Teams can improve their Sprint Planning 2

Categories: Blogs

The Grumpy Scrum Master

Agile Tools - Tom Perry - Thu, 09/18/2014 - 06:54

grumpy dwarf

“Going against men, I have heard at times a deep harmony
thrumming in the mixture, and when they ask me what
I say I don’t know. It is not the only or the easiest
way to come to the truth. It is one way.” – Wendell Berry

I looked in the mirror the other day and guess what I saw? The grumpy scrum master. He comes by sometimes and pays me a visit. Old grumpy looked at me and I looked at him and together we agreed that perhaps, just this one time, he just might be right.

We sat down and had a talk. It turns out he’s tired and cranky and seen this all before. I told him I can relate. We agreed that we’ve both done enough stupid to last a couple of lifetimes. No arguments there. He knows what he doesn’t like – me too! After a little debate, we both agreed we don’t give a damn what you think.

So we decided it was time to write a manifesto. That is

We grumps have come to value:

Speaking our mind over listening to whiners

Working hard over talking about it

 Getting shit done over following a plan

Disagreeing with you over getting along

That is, while the items are the right are a total waste of time, the stuff on the left is much more gratifying.

 


Filed under: Coaching, Humor, Scrum Tagged: bad attitude, grumpy, Humor, Scrum, Scrum Master
Categories: Blogs

How to create an Agile Burn-Up Graph in Google Docs

Scrumology.com - Kane Mar - Wed, 09/17/2014 - 22:01

A Burn-Up graph is simply a stack graph showing the total amount of work the team has in their product backlog over a number of Sprints. I’ve used a variety of different Agile Burn-Up graphs over the years. Here’s one of my favourites:

 

Agile Burn-Up Graph

Agile Burn-Up Graph

 

I created this with Excel while working with an insurance company based in Mayfield, Ohio. In this article I’ll show you how to create something similar using Google docs.

Understanding the Burn-up Graph

This graph (above) shows the total amount of work in the product backlog (top line of the graph), the amount of work completed (yellow) and the amount of work remaining (red and blue). The amount of work remaining is divided into estimated work (red) and un-estimated work (blue) which we guessed at using a very course scale. At the start you can see the total amount of work on the backlog increase until the fourth Sprint as indicated by the rising top-line of the graph.

After the fourth Sprint the team decided that they needed to start breaking down the un-estimated work into small User Stories and so you can see an increase in the red area of the graph and a decline in the blue. We continued to complete work, so the yellow area continued to grow.

By Sprint 12 we had completely broken down all the large bodies of work and had a well refined backlog.

Creating the Graph in Google Spreadsheets

The Google graph that I’ve created is a little bit simpler than the graph above. It shows the total amount of work in the product, the total amount of work added to the product backlog, and the total amount of work completed. You can get the Google Spreadsheet document to create this graph here.

This is what it looks like:

 

Agile Product Burn-up Graph

Agile Product Burn-up Graph

 

The spreadsheet contains two tabs. The first tab contains the data necessary for the graph, and the second tab contains the graph. To start using this graph,

  1. Make a copy of the Google Spreadsheet
  2. Enter the total of the teams estimates in the product backlog into the first column of Series A.
  3. There after all you need to record is the total number of the teams estimates completed at the end of each Sprint, and
  4. The total number of the teams estimates added to the Product Backlog (by the Product Owner) during the sprint.

 

Product Burn-up Graph Google Spreadsheet

Product Burn-up Graph Google Spreadsheet

 

You can get the Google Spreadsheet document to create this graph here.

Categories: Blogs

Die Lego-Story oder das Geheimnis gelungener Skalierung

Scrum 4 You - Wed, 09/17/2014 - 07:30

Wenn wir von Skalierung sprechen, denken wir häufig an Umbrüche, Neuorganisation und Transformationen. Wir haben große Schemata und Organigramme im Kopf. Ein schönes Lehrstück darüber, wie solche Skalierungen mächtig schiefgehen können, beschreibt David Robertson in seinem Buch “Brick by Brick”. Es erzählt die Geschichte der dänischen Lego-Gruppe.

Besonders spannend sind zwei Augenblicke in der Firmengeschichte: Zum einen ist da die frühe Firmengeschichte in der Nachkriegszeit, als Lego sich vom Hersteller von Holzspielzeugen zum Fabrikant modularer Plastikbausteine mauserte. Damals, im Jahr 1946, investierte Lego mehr als den zweifachen Jahresgewinn zum Erwerb einer enzigen Spritzgussmaschine für Kunststoff. Den Erfolg dieser Entscheidung kennen wir alle.

Verlorener Fokus

Weniger bekannt ist, dass Lego um die Jahrtausendwende kurz vor der Insolvenz stand. Wie konnte es so weit kommen? Lego hatte in den 1990er Jahren erlebt, wie sich das Spielverhalten von Kindern und Jugendlichen veränderte. In Zeiten von Gameboy und XBox erschien das Aufeinandertürmen von Spielklötzen zur Erschaffung eigener Welten plötzlich veraltet. Lego reagierte, indem es sich in einer Reihe von Geschäftsfeldern wie Computerspielen, Lifestyle-Produkte, Themenparks und Lernkonzepten versuchte. Dabei geriet das, was Lego immer schon stark gemacht hatte, aus dem Fokus. An Stelle des klaren und einfachen Designs, in dem Kinder ihre eigenen Erlebeniswelten nachbauen konnten, traten abstrakte Action- und Sci-Fi-Figuren. Die bei Kleinkindern beliebte Duplo-Linie wurde durch ein längst schon wieder abgeschafftes System namens Lego Explore ersetzt, das sich an den Spielzeugen des Konkurrenten Fisher-Price orientierte. Lego war in viele Richtungen gewachsen, aber diese Diversifizierung brach dem Unternehmen fast das Genick.

Eine interne Untersuchung ergab im Jahr 2004, dass 94% der Lego-Baukästen unprofitabel waren. Neben der misslungenen Diversifizierung war dies auch auf eine misslungene Systemarchitektur zurückzuführen. Zwischen 1997 und 2004 war die Nummer an Einzelbausteinen von 6.000 auf über 14.000 explodiert. Die Farbvarianten der Bausteine stiegen von ursprünglich sechs auf über 50 an. Jeder Einkäufer, jeder Logistiker kann sich vorstellen, wie viel Mehraufwand es für Produktion, Lager und Versand bedeutet, wenn neue Elemente nur für ein Baukasten-Set verwendbar sind. Aber auch die Integrität der Marken litt darunter: Plötzlich gab es nicht ein, sondern gleich acht Polizeimännchen mit minimalen Unterschieden in der Konfiguration. Für Produktlinien wurden eigene Minifiguren geschaffen, die zum Teil den Gesichtern ihrer Designer nachempfunden waren. Die Tradition war, im wörtlichsten Sinn (tra-dere – hinüber-geben) verloren gegangen. Erwachsene fanden das Lego ihrer Kindheit nicht wieder – und Kinder konnten mit den schönen neuen Welten wenig anfangen.

Rückbesinnung auf die Stärken

Der Weg zurück zur Profitabilität war ebenso einfach wie genial. Robertson erzählt, wie bei dem frisch ernannten CEO Jørgen Vig Knudstorp, damals Mitte 30, der Groschen fiel:

“For children and their parents, the benefits of a play system were obvious: combining bricks in almost any way they wanted fired kid’s creativity and imagination and delivered a singularly unique building experience. But for Knudstorp, his eureka moment came when he realized the Lego System is not just a play system, it’s also a business system. (…) Instead of following the industry norm of striving to come up with one-hit wonders, LEGO should create a coherent, expandable universe of toys. A Lego system of toys (…) would build familiarity and a sense of community around Lego.”

Diese Erkenntnis führte beispielsweise dazu, dass künftig mindestens 70% aller Bauteile aus bisherigem Bestand sein mussten. Oder dass die erfahrensten Designer und Entwickler wieder die Autorität bekamen, den Entwicklungsprozess von Anfang an mitzubestimmen. Oder dass die interne Softwareentwicklung mangels Erfahrung aufgegeben wurde und stattdessen Kooperationen eingegangen wurden.
Die Lego-Story ist ein Lehrstück in Skalierung. Kurz vor dem eigenen Untergang hat Lego erkannt, dass wirkliches Wachstum nur in Feldern geschehen kann, in denen das Unternehmen stark ist. In den neunziger Jahren versuchte Lego, Zeittrends hinterher zu laufen, die mit seiner eigenen Identität wenig zu tun hatten. Entsprechend hilflos agierte Lego dann auch. Bis es schließlich erkannte, welche Stärken es schon immer gehabt hatte. Dann hat Lego angefangen, konsequent auf diese Stärken zu fokussieren. Dort, im geschlossenen Ökoystem der Bausteinwelten, ist das Wachstum gelungen. Das Ergebnis kann sich mittlerweile auch finanziell sehen lassen: Im vergangenen Jahr meldete die Lego-Gruppe eine Umsatzrendite von 34% bei 3,1 Milliarden Euro Umsatz.

VitraHause_23

Vitra-Haus in Weil am Rhein. Die Architekten Herzog & de Neuron beschreiben die Verschachtelung von zwölf Häusern auf fünf Etagen als “domestic scale”. Das archetypische Haus (Ur-Haus) dient dabei als Grundform. Quelle: en.wikiarquitectura.com

Related posts:

  1. 1 Euro wer zu spät kommt | Daily Scrum | Bärenherz
  2. Die Kraft der Begeisterung
  3. Mehr wissen! Moderationstraining

Categories: Blogs

Role != Job

Agile Tools - Tom Perry - Wed, 09/17/2014 - 07:16

Student_teacher_in_China

When I talk to folks about Scrum, one of the points I make sure to cover is the holy trinity, the three basic roles in Scrum: Product Owner, Scrum Master, and Team. I’m starting to think I must be doing it wrong because when I talk about roles, somehow that role manifests itself as a job. Let me back up a step and see if I can explain what I mean. To me, a role is a transitory responsibility that anyone can take on. It’s akin to what actors do. Actors take different roles all the time. But when an actor takes a role, say as a teacher, they act in every way like a teacher, without actually being a teacher. They do it and then leave it behind and move on to the next role. They may perform the role so well that you can’t tell the difference between the actor and the teacher, but to the actor teaching is still just a role.

Now there are people for whom teaching is a job. A job is very different from a role. You are hired for a job. A job is something that you identify with and are assigned to. A job, at least for some, becomes something that they identify strongly with (i.e. “I am a teacher.” or “Teaching is what I do.”). A job is a very different thing than a role. A job comes with identity, some feeling of authenticity and permanence. Typically we hire people to perform jobs.

According to this definition, jobs and roles are very different beasts. However, people have a hard time keeping this distinction in mind. We tend to take roles and turn them into jobs. That’s unfortunate, because a role is meant to be something transitory, something that is filled temporarily. It is meant to be worn like a costume and then passed on to the next wearer. When you turn a role into a job, you risk perverting it’s purpose. When you turn a role into a job, you make it very difficult for others to share it – it’s hard to swap back and forth. When you make a role into a job, people get surprisingly defensive about it. It becomes something that they identify with very closely. If you try and tell them that anybody can do it, they tend to get all fussy and upset. They start to try and protect their job with clever artifacts like certifications – they’ll do anything to make themselves unique enough to keep that job. It’s an identity trap.

Here is how I see this problem manifest itself with Scrum teams: You sell them on scrum and teach them how it works. Every team has a Scrum Master and a Product Owner. So what do they do? They run out and hire themselves some people to fill the jobs of Scrum Masters and Product Owners. They get their teams sprinting and start delivering quickly – hey, now they’re agile! Only they’re not really. You see, as you face the challenge and complexity of modern day business, the team often needs to change. That person you hired as the Scrum Master? You may be best served to swap that role with somebody else. Maybe a developer or QA on the team. The ability to move that role around to different actors could be very useful. But you can’t do that now because it’s no longer a role, it’s somebody’s job. And you can’t mess with their job without seriously upsetting somebody. The end result is that your organization effectively can’t change. You limit your agility.

The bottom line is that I believe that the roles in Scrum were never intended to be jobs. To make those roles into jobs risks limiting your agility.


Filed under: Agile, Coaching, Scrum, Teams Tagged: Agile, agility, jobs, roles, Scrum
Categories: Blogs

Agile Jeopardy–Not as Easy as You’d Think

DFW Scrum User Group - Tue, 09/16/2014 - 16:39
Last month we played Agile Jeopardy, and the questions and answers related directly to the Agile Manifesto. Four values and twelve principles—how bad could it be? Turns out most people don’t have them memorized, and our teams had a rough … Continue reading →
Categories: Communities

Telling Executive Stories

Leading Agile - Tue, 09/16/2014 - 15:31

Delivery teams manage and deliver value supported by the tool user stories. These teams tell stories about who, what, why, and acceptability using standard form, “As a <persona>, I want <capability> so that <delivered value> occurs,” and behavior acceptance form, “Given < context>, when <action occurs>, then < consequence >.” These stories form the foundation of repeatable delivery and management of value.

While these forms support delivery team conversations well, they are inadequate to support the richer conversation needed by executives to manage investment and value. What forms the basis of these stories? How do we tell stories about delivering product value to our customers and delivering investment value to our organization?

Developing contextual story-telling focuses on the kinds of conversations the product managers, product owners, business owners, and executives have when they meet to operate and run the business. We listen to these stories and then use existing canvas templates to develop contextually relevant canvas designs. These canvases become the fabric used when beginning new stories, and continuing old stories regarding business strategy and tactics.

To develop the canvases, we need to listen to these conversations and stories and develop a sense for topics and content of the strategic and tactical conversations. These questions form the thinking needed to create a first draft tool that can be used to bookmark a conversation.

  • What is the focus of each conversation?
  • What are the conversational topics?
  • What is the airtime of each topic?
  • What is the passion level of each topic?
  • In what order are the topics discussed?

These conversations may cover the following topics:

Product Focus Areas

  • Vision
  • Problem Space
  • Solution Space
  • Metrics
  • Costs
  • Alignment
  • Value
Market Focus Areas

  • Revenue
  • Customers
  • Delivery Channels
  • Strengths
  • Vision
  • Value

We also discover that there are quite a few topics of conversations that don’t quite fit into the strategic bucket and sound more like high-level tactics. This turns out to be the work of the executive and product teams. Those topics of conversation may cover the following:

  • Naming
  • Goal
  • Metrics
  • Leader or Owner
  • Customers
  • Stakeholders
  • Overview
  • Big Picture
  • Alignment
  • Solution Details

The key is identifying the key conversations in meetings and formulating a canvas around those topics. A common mistake is to use an existing template and force the conversations to conform to that template. Although tempting, this mistake leads to disengagement and abandonment of the canvas and tools. The tools are there to support the way the team works, not to force conformity to industry luminary ideals. These canvas designs will evolve as the organization improves its prowess at portfolio management.

The following is an example of the conversations important to an executive strategy canvas we recently developed:

  • Vision: Why pursue the strategy?
  • Customers: Who wanted it achieved?
  • Problem Space: What problems were they facing?
  • Solution Space: What solutions would work?
  • Value to the Customer: What epic stories would the customers tell?
  • Metrics:  What dials would move in the near future?
  • Value to the Organization: How does the organization benefit?

These topics of conversation are arranged canvas style so that new conversations take place to create a new strategy or so that existing conversations can be continued to check in on existing conversations. You may notice that while the range of topics available, this group focused around the customer. This is very clear by the absence of cost and revenue as a significant part of their strategic conversation.

The executives also had conversations about investments they would make in the strategy. The topics of that conversation included the following areas:

  • Goal: What is the desired outcome?
  • Metrics: What are the measures of success?
  • Customers: Who wants this?
  • Big Picture: What is the big picture?
  • Solution Details: What are possible solutions?
  • Alignment: How does this align with the strategy canvas?

We also listened for how the executive team intended to use the tools to support their work. They decided to use the canvases in the following ways:

Strategic Canvas

  • 90 Day True North
  • Investment Decision Filter
  • Organizational Strategic Alignment
  • Organizational Transparent

Investment Canvas

  • Tactical deliverable investment designed to experiment with some part of the strategy
  • Flow in a work system
  • Regular discussions about discovery, validation, delivery, and evaluation

We have created a glimpse of a strategic and work alignment system focused on portfolio management. The system and artifacts was developed based on the context of the organization and the thought leadership in the industry. The key point to take away is that context matters when developing the artifacts executives use to manage their strategic and tactical portfolio work.

The post Telling Executive Stories appeared first on LeadingAgile.

Categories: Blogs

Projects Where You Can’t Predict an End Date

Johanna Rothman - Tue, 09/16/2014 - 13:50

Do you have projects where you can’t predict an end date? These tend to be a job search, a change project, and with a tip of the hat to Cesar Abeid, your life. I like to call these “emergent” projects.

You might prefer to call them “adaptable” projects, but to me, every project has to be adaptable. These projects are emergent. You need to plan, but not too much. You need to replan. You need to take advantage of serendipity.

My column this quarter for projectmanagement.com is Applying Agile to Emergent Projects. (Free registration required.)

Enjoy!

Categories: Blogs

Squad Health Check model – visualizing what to improve

Henrik Kniberg's blog - Tue, 09/16/2014 - 10:00

Squad Health Check model

(Download the cards & instructions as PDF or PPTX)

At Spotify we’ve been experimenting a lot with various ways of visualizing the “health” of a squad, in order to help them improve and find systemic patterns across a tribe. Since a lot of people have been asking me about this, I wrote up an article about it together with coach-colleague Kristian Lindwall.

Read it on the Spotify labs blog: Squad Health Check model – visualizing what to improve.

Categories: Blogs

Sichtbarkeit ist der erste Schritt – das Taskboard auf Management-Ebene

Scrum 4 You - Tue, 09/16/2014 - 07:33

„Aber ich habe ja so viele Dinge, die ich jeden Tag erledigen muss – da kann ich doch gar nicht ständig einen Zettel schreiben?“ So oder so ähnlich lauteten in einem Projekt die Kommentare, als wir begannen, ein Taskboard auf Management-Level einzuführen. Ich kann das gut nachvollziehen, meine Taskliste von heute sieht so aus:

  • Kunde: Backlog mit N.N
  • Kunde: Meetings mit N.N. und O.O.
  • Kunde: Daily Scrum
  • Kunde: JIRA Training – Setup
  • Kunde: Arbeit an der Darstellung zur Meeting-Struktur
  • Marketing: Review Pressemitteilung Agile Bodensee
  • Blog: Brauchen wir noch Daily Standups?
  • Blog: Die Generation Y – “Wir wollen unser Leben genießen”
  • JIRA Playbook an alle geschickt
  • Travel: Flüge für die nächsten drei Wochen gebucht
  • Blog: Das Taskboard auf Management Ebene – Warum eigentlich ein Taskboard?
  • Intern: HR-Backlog und Unklarheiten besprochen
  • Sales: einen Kunden angerufen, und um Feedback gebeten
  • Travel: Ersatzreisedokument am Flughafen Berlin besorgt
  • Familie: Meine Frau vom Flughafen abholen

Soll ich da wirklich jedes Mal einen Zettel schreiben oder meine kleine 1h-Aufgabe in einem Tool wie JIRA oder Trello ablegen? Ihr könnt euch denken, dass ich vor mich hin schmunzle. Denn während ich das hier schreibe, habe ich ja gerade die Einträge für ein Taskboard erstellt. Das nun auf Klebezettel zu schreiben, oder vielleicht sogar in ein Tool wie JIRA einzutragen, ist sicher genauso möglich. Es ist ein wenig komplizierter, aber nicht sehr. Wer mehr dazu wissen will, wie man das effizient macht, dem sei Personal Kanban empfohlen. Und doch: Management-Teams wehren sich zunächst, diese wenigen Einträge zu machen. Also mache ich sie in meiner Rolle als ScrumMaster in der ersten Woche für das Management-Team. Auf diese Weise sehen sie auch, wie viele Dinge sie erledigt bekommen und wie viele Dinge sie abseits des Üblichen  noch so machen.

Ist Euch das auch schon mal aufgefallen? Die meisten Manager machen unendlich viele ad-hoc-Aufgaben, sie stecken zu tief im Tagesgeschäft. Ständige Störungen, permanente Meetings und sie werden von E-Mails überflutet. Konzeptionelles Arbeiten oder gar Führen ist fast nicht möglich. Ich habe schon öfter geschrieben, dass Henry Mintzberg das schon vor Jahren festgestellt hatte:

“Folklore: The manager is a reflective, systematic planner. The evidence of this issue is overwhelming, but not a shred of it supports this statement.

Fact: Study after study has shown that managers work at an unrelenting pace, that their activities are characterized by brevity, variety, and discontinuity, and that they are strongly oriented to action and dislike reflective activities. Consider this evidence: Half the activities engaged in by the five chief executives of my study lasted less than nine minutes, and only 10% exceeded one hour. A study of 56 U.S. foremen found that they averaged 583 activities per eight-hour shift, an average of 1 every 48 seconds. The work pace for both chief executives and foremen was unrelenting. The chief executives met a steady stream of callers and mail from the moment they arrived in the morning until they left in the evening. Coffee breaks and lunches were inevitably work related, and ever-present subordinates seemed to usurp any free moment.“

Trotzdem es ist etwas anderes, das täglich in der Praxis zu sehen. Management-Teams haben also nicht wirklich Zeit, das große Ganze zu sehen. Sie kommen gar nicht dazu, sich um die vielen wichtigen Aspekte zu kümmern, denn sie sind total beschäftigt. Gesehen haben wir ein ähnliches Phänomen in der Vergangenheit bereits bei skalierten Scrum-Implementierungen. Dort mit den Product Ownern konzeptionell zu arbeiten, in Ruhe ein Backlog aufzubauen, vielleicht zwei Tage intensiv daran arbeiten, eine wirklich ausgearbeitete Story Map zu erstellen – das war aufgrund der vielen Störungen gar nicht möglich. In diesen Kontexten hatten wir aber die Schwierigkeiten auf die Komplexität der Produkte geschoben.

Was mir jetzt als ScrumMaster eines Management-Teams auffällt: Es fehlt die Priorisierung. Alles scheint gleich wichtig, als wäre es in einem größeren Unternehmen nicht auch möglich, sich zu fokussieren. Gleichzeitig ist das nicht so viel anders als das, was die Arbeit von vielen Entwicklungsteams in der Vergangenheit gezeigt hat.

Wie kann ich meinem Management-Team dabei helfen: Mit einem Taskboard. Es macht transparent, wie viele Dinge erledigt werden müssen. Damit kann man daran arbeiten, die wirklich wichtigen Dinge zu tun und sich gegenseitig zu helfen. Jetzt brauche ich nur noch Geduld – wie bei allen Teams dauert es ein wenig, bis die Idee des Taskboards angenommen wird.

Literatur
Henry Mintzberg: The Manager’s Job: Folklore and Fact, HARVARD BUSINESS REVIEW: March/April 1990, p. 163 – 176

Related posts:

  1. 5 Minutes on Scrum | Transparency
  2. Prioritäten | Product Owners Tools
  3. Product Backlog | Templates | Scrum Tools

Categories: Blogs

Building a Change Artist

Agile Tools - Tom Perry - Tue, 09/16/2014 - 06:45

Team

So you want your organization to change? Then you just might need a change artist. What is a change artist? A change artist is someone who leads change in an organization by sharing example and by influence using visualization. That is to say, a change artist will not mandate or coerce in order to introduce change, but rather they will begin with themselves and demonstrate their own change – thereby providing the example and the potential motivation for others to seek similar change in themselves. The visualizations help to share the story – you need the artist.

boulder

I think that people who are able to express their ideas through pictures are particularly well suited to creating the kinds of compelling visualizations that help convey what change might look like. They don’t have to be technically competent as an artist. Just good enough to draw stick figures and tell a story. Its really not that hard once you stop worrying about what people think.

Can we create people like this? Or are they born to it? I don’t think the hard part is the art. Anybody can do that. It’s how they approach change that matters most.

alligator

Perhaps there are organizations that would be more receptive to change initiatives that aggressively use visualization techniques. I can’t help imagine that visualization can add a compelling element to any transition engagement. I’ve not see much evidence of that sort of approach on agile transition engagements that I’ve been on. I’ve seen the power of what a simple drawing can do to draw people together and generate discussion. Using some sharpies and some butcher paper I can start a conversation that will continue long after I’m gone. I’ve seen it happen. There isn’t a text document in the world that can compete with a good picture. I’m not talking about Visio diagrams either. There is a quality to the hand drawn diagram that invites people to engage in a way that no sterile electronic diagram ever will. I’ve held two versions of the same diagram, one hand drawn and one electronic, side by side and the preference is almost always unanimous – the hand drawn version wins. I think the magic lies somewhere in the the errors and mistakes in the drawing. They must serve to remind us that we are  human. Perfection isn’t necessary, and in fact may be counterproductive.

That’s who I want to help me change the world. Combine the passion for change and the art and I’ll give you a change artist.

periodic


Filed under: Agile, Coaching Tagged: Agile, artist, change, change artist, Transition
Categories: Blogs

The Product Owner Role in Sprint Retrospective

Scrum Expert - Mon, 09/15/2014 - 18:03
The sprint retrospective in an important moment in the Scrum approach where the team think about its software development process and tries to improve it. As on of the three Scrum roles, the product owner has to play its part in this activity. In this blog post, Roman Pichler explains how product owner can play an active role during the retrospective meetings. The sprint retrospective meetings takes place at the end of the sprint after the sprint review meeting and should produce improvement measures. The product owner has to take ...
Categories: Communities

Agile @ Scale (slides from Sony Mobile tech talk)

Henrik Kniberg's blog - Mon, 09/15/2014 - 14:09

Here are the slides from my tech talk Agile @ Scale at Sony Mobile. Full house & very high level of engagement, I was impressed by this crowd! And thanks for the awesome recommendation on LinkedIn :)

 

Some sample pics below:

Visualize and limit WIP

Visual planning

Productivity and motivation

 

Tradeoffs

Categories: Blogs

Getting Starting on #POcampCH -- the Product Owner Camp Switzerland

Scrum Breakfast - Mon, 09/15/2014 - 12:33
Today, the organization team for the first Product Owner Camp in Switzerland, held its first telco. Here is what we decided:
  1. Our target date is March 2015, the alternative is June, 2015.
  2. The open space will be held on a Friday and Saturday.
  3. We want to hold a Product Owner Masterclass, one or two days before the Open Space event.
  4. The audience is experienced Product Owners, Agile Product Managers and Lean Startup Practitioners. This is by practitioners for practitioners, not for beginners.
  5. The event is not profit oriented. 
  6. We are going to get together on skype roughly once every to two weeks to take the event forward. 
We are thinking hotel in the mountains, we will start exploring possibilities once the constraints for the workshop are defined. 
We have created a backlog to organize our work: Our first objective is the find a leader for the MasterClass, reserve some dates, and start working on the website. After that, priority will be the venue...

Several other people expressed an interest in helping to organize, we will welcome them as they confirm their participation :-)!
Are you interested in participating (or even helping out?) Join our google group to stay informed!
Categories: Blogs

How much do you let a new team self organize?

Scrum Breakfast - Mon, 09/15/2014 - 09:00

I have a team of 11 developers and 3 Product Owners. Their ideas about how to organize the team are all over the place. Some want to do 1 week sprints. Others want one month sprints. And we pull in resources people so we can get the right velocity to meet our deadlines. This seems like a mess. How much should I let my beginning team self-organize? -- recently asked on a Scrum Discussion Forum.    Modifying a complex technique before you have mastered it is a failure pattern. So when you are just getting started, try to get as close to Scrum by the book as you can, without obsessing over it... much. I call this Pretty Good Scrum(tm). ;-)

Yes the team self-organizes... and the Scrum Master is charged with teaching the team and helping them improve. When the team is just getting started, it should follow the lead the of Scrum Master, and the Scrum Master should stay close to the book. As they get better, they'll be better able to inspect and adapt themselves.

Successful teams learn quickly. How do you learn quickly? Short answer: Do short sprints. More in a moment.

Remember, never hit anyone with the book! The rules of Scrum are there to help you, not to threaten or punish people. Be sure you can answer why the rule of Scrum is a good answer. Treat everything as an experiment or learning exercise, so they have the security of knowing they can change things later. That's what retrospectives are for.

It will probably take you three or four sprints to get to Pretty Good Scrum. That's why I recommend one week sprints to start. Why learn in four months what you can learn in 4 weeks?

If I were confronted with the situation above, I would ask five questions and help the team(s) and PO(s) find answers that stay within the constraints defined by Scrum.

1. How big is a Scrum team? 7+/-2. To stay in those bounds, you need two teams. Ask your teams how they want divide themselves, respecting that constraint. By giving them the problem, they become responsible for the solution, so they won't come to you anymore with "yes, but..."! If they talk about limited specialists, ask them how to resolve the problem.

2. How many Product Owners does a Scrum Team have? One, though you might also have a Chief Product Owner role in the case of multiple teams. Ask your product owners how they want to split up their work. And yes, the PO is responsible for the Vision. Do they have one, can they communicate it? Is it shared and supported by the Team and other stakeholders?

3. How long is the Sprint? Normally this is negotiated between PO and Team. And... as Scrum Master you are responsible for the process, which gives you the right to intervene to improve the team. Shorter sprints accelerate learning. So I would suggest starting with a couple of one week sprints. Be sure to get your team to agree to this. I have also had great experiences doing 2 or 3 sprints at 59 minutes each (ask me more about this if you're interested).

4. Who estimates and decides how much work can be accomplished in a sprint? The team. Not the math, not the PO, not the stakeholders and not management. Have them estimate the work, and don't let them take on more than they can chew. Think of highways at rush hour if you want to know why this is a good idea.

5. Whose job is it to make sure that wish and reality are in harmony with each other? The Product Owner. If the desired scope does not match up with the team's reasonable forecast of what they can accomplish by the desired release date (aka deadline), whose job is it to fix the problem? The PO. Given your context, conversations about reducing scope and the impact of product-level multitasking on ROI might be quite fruitful!

Back to the original question: "How much do you let a new team self organize?" The answer is "quite a lot!" The trick is setting constraints that cause people to come up with right answers.
Categories: Blogs

“Du nervst!” – Wie man mit Menschen umgeht, die einen in den Wahnsinn treiben

Scrum 4 You - Mon, 09/15/2014 - 07:45

Es gibt sie immer – Menschen, mit denen man nicht gut klarkommt. Seien es Kollegen, Kunden, Berater, Bekannte innerhalb des eigenen Freundeskreises und des öfteren sogar Familienmitglieder. Sie alle sind Teil unterschiedlicher Systeme, in denen man sich bewegt. Jedes Mal, wenn ich eine jener Personen antreffe, merke ich sofort, wie mein Blutdruck ansteigt und ich mich bemühen muss, freundlich und geduldig zu bleiben. Nach jahrelanger Beratertätigkeit, bei der ich schon die unterschiedlichsten Menschentypen angetroffen habe, meine ich nun, ein paar Möglichkeiten gefunden zu haben, um in der Anwesenheit eines (für mich) nervigen Menschen einen kühlen Kopf zu bewahren. Hier meine fünf persönlichen Favourites:

  1. Durch Beobachtung herausfinden, was es ist, das mich nervt. Sei es eine gemeinsame Historie, Handbewegungen, Dialekt, Körperhaltung etc. Egal – der Fantasie sind hier keine Grenzen gesetzt. Dann sollte man sich selbst fragen, weshalb diese Aspekte einen nerven. Es könnte ja sein, dass man Opfer des Resonanzgesetzes geworden ist.
  2. Positives Hinterfragen. Was schätzen gemeinsame Bekannte an dieser Person? Welche Aspekte würden dir fehlen, wenn diese Person nicht mehr da wäre? Was müsstest du an Rollen in eurem System übernehmen? Würden Aufgaben auf dich übergehen? Man kann sich auch absurde Fragen stellen wie: „Wenn ich mich in diese Person verlieben müsste, welche Aspekte wären es, die mich anziehen würden?“
  3. Man könnte versuchen, eine Veränderung im Verhalten der anderen Person herbeizuführen. Dies kann man erreichen, indem man positives Verhalten durch Feedback hervorhebt und bestärkt. Meine Erfahrung ist, dass kontinuierliches Feedback über einen längeren Zeitraum einen wirklichen Unterschied macht.
  4. Offenlegen. Wie wichtig dieser Aspekt ist, hat mich meine Coachingausbildung gelehrt. Hier ist essenziell, dass man ehrlich ist und beim Feedback bei sich selbst anfängt. Richtig wäre „Liebe Caro, ich habe manchmal das Gefühl, dass wir an einander vorbeireden. Oder “Liebe Caro, manchmal scheint es mir, als würden jene Punkte, die ich anmerke, bei dir nicht das Gehör bekommen, das sie meines Erachtens nach bekommen sollten.“ Zu vermeiden sind Floskeln wie „Das ist so“ oder Worte wie „immer“. Denn das stimmt ja nicht – erstens gibt es immer Ausnahmen und zweitens ist es eine persönliche Meinung. Hier ist es auch wichtig, auf die Kultur zu achten – während man in Österreich eher von der Maschekseite kommen würde, geht es in Deutschland zum Beispiel direkter zu.
  5. Nach der Offenlegung die Meinung des Gegenübers abholen: „Siehst du das genauso?“ Und anschließend “was können wir tun, um die aktuelle Situation zu verändern?”

Falls keiner der genannten Punkte funktioniert, würde ich empfehlen, einen Systemischen Business Coach aufzusuchen und das Thema mit ihm durchzuackern.

Mit welcher der fünf Optionen hast du schon Erfahrungen gesammelt? Welchen sechsten Tipp würdest du mir raten, in mein Repertoire aufzunehmen?

Related posts:

  1. Bin ich am Arbeitsplatz zufrieden?
  2. Erinnerung: Scrum Breakfast diesen Samstag im Quadro!
  3. Feedback geben können oder warum auch ein alter Hut gut aussehen kann

Categories: Blogs

Hierarchy vs. Constellation

Agile Tools - Tom Perry - Sun, 09/14/2014 - 21:14

SONY DSC

“Organizations must shift away from repetitive-function hierarchies with rules and enforcement and walls. Instead, we must migrate rapidly to becoming a global ‘team of teams’ that comes together in whatever combination necessary to add the greatest value to the changes underway.” – Bill Drayton

It’s easy to despair that people can not see social structures as anything other than dominance hierarchies. I suppose that makes sense given our primate origins. In college, I spent hundreds of hours observing chimpanzees at the local zoo as part of a research project. It doesn’t take very long to understand the hierarchy within a small colony of apes. The dominant ape spends a significant portion of this time strutting around making sure everyone knows he’s the boss. He uses every tool in the book, from the brutish power of dominance displays, all the way to the subtle selection of who gets to groom him first. He’s the big man on top.

However, the longer you watch, the more you start to detect other hierarchies within the primate social system. Female chimps have their own sub hierarchy that is just as much a power game as that of the dominant male. Within a very short time you are seeing different types of social hierarchy all over the place. I found myself in awe of the number and complexity of the hierarchies that chimpanzees display. I would maintain that the hierarchies and power games played by chimps rivals anything we have in even the most vicious office politics.

Of course, maybe the hierarchy is in the eye of the beholder. Perhaps we humans are wired to categorize things according to certain patterns. Maybe we are just inclined to see everything in terms of hierarchies as some sort of side effect of the way our perceptual systems are set up. I imagine there is some of that at work here. After all, as primates we have been fine tuning our hierarchical behavior for millennia, so it would be no surprise if we tend to see them everywhere we look.

That notion, that hierarchy is a sort of built in default, is a pretty depressing idea if, like me, you aren’t all that fond of hierarchies. There is no doubt that hierarchies have their advantages, but they have disadvantages too. Look how well the hierarchy has worked out for the Chimpanzees. They are well on their way toward extinction, so you could argue that whatever social strategy they are using, it’s not contributing sufficiently to help ensure their survival.

“Male chimpanzees have an extraordinarily strong drive for dominance. They’re constantly jockeying for position.” – Frans de Waal

It may be that because the chimpanzee is so geared toward hierarchy they are unable to utilize other social structures that would allow them to adapt to their changing environment. Perhaps it is their inability to change their behavior that spells their doom. On the one hand, blame the human for killing them. On the other, recognize that this is an adaptive challenge to which the chimpanzee has not found a winning strategy to counter.

Fortunately, humans appear to be capable of a bit more flexibility when it comes to our social and organizational structure. That is, while we still lean strongly toward the hierarchy (call it the default if you will), we seem to be capable of using other ways of organizing ourselves when the need arises.

That’s a good thing, because whether you are a business, or a society, we face a number of challenges as well. Recently a friend introduced me to Ashby’s Law of Requisite Variety,

If a system is to be stable the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled. Ashby states the Law as “variety can destroy variety”

In a nutshell, when a system faces a challenge, the complexity of that system must be equal to the complexity of the threat in order for the challenged system to survive. Let’s take that back to hierarchy now. Hierarchies consolidate decision making and rely on decisions made by the guy at the top. This helps to simplify the number of responses, which can be useful, but may not be the most adaptive strategy when under threat. In a complex environment, a hierarchy is a rather simplistic structure to use. It doesn’t have the requisite variety required to cope with a complex environment where challenges can arise in many different forms. fortunately, nature has provided us with many different models of social organization to choose from.

In a peer network, no one is officially in charge. It doesn’t have a command hierarchy. It doesn’t have a boss. So, all the decisions are somehow made collectively. The control of the system is in the hands of everyone who is a part of it. – Steven Johnson

Take insects, for example, they use a very different structure often described as a swarm. The swarm does not rely on a single individual or a subset of individuals to determine its response to a given challenge. This means that the swarm can use all of the members of its population to dynamically respond to a challenge. This leads to combinatorial explosion of different alternatives, which gives the swarm a huge arsenal of complex responses. It’s probably worth noting that on an evolutionary scale, the insects have been pretty successful using this strategy (and there are those who would argue they are the most likely to win).

Of course people can use these strategies too. Swarming and other social models are much more rarely used by people, but there are examples. Wikipedia is a great example of a swarm where there is no top down direction. Some organizations, like AA are also good examples. While there are not a lot of examples to choose from, with the increasing complexity of our social and business environments one might wonder if we may see an increasing diversity of swarms and other alternative social structures as a result.

Time will tell. I think the recent evolution of various and sundry Agile methods may be a hint that the underlying social structures are broken, and that people see a need for alternative structures to hierarchy in order to meet the challenges of today’s ever more complex challenges. If that is the case, then I expect to see many more of these Agile methods and frameworks arising in the not too distant future.


Filed under: Agile, Process, Swarming, Teams Tagged: Ashby, Behavior, chimpanzees, constellation, dominance, hierarchy, power, swarm, Swarming, variability, variety
Categories: Blogs

Starting Backwards

Agile Tools - Tom Perry - Sun, 09/14/2014 - 08:11

dangerous-fast-force-2438-466x350

If you were to draw a diagram of the entire product development process from start to finish, what would you start with? If you are like me, you’d probably start with the customer, or maybe sales. Then you’d probably pass the idea along to product management and onward to development. Last, but not least, the product would make its way to operations for deployment in production.

It’s pretty straightforward, front to back, end-to-end. Everybody knows how it works. And if we are going to try to improve this process, where do you think we typically start?

At the front? In sales? No.

At the back? With operations? No. Not there either.

Right smack dab in the middle? BINGO! Development always gets the love first.

Now what kind of lunacy is that? Now I’ve been part of a process improvement effort or two, so naturally I start to think I see patterns. Well, hallucinations of some kind anyway. Almost every time we start with the development teams. We do a good job, we get them up and sprinting, train a few scrum masters, console a few managers, and Bob’s your uncle: the dev teams are agile! Then what happens?

Downstream, the operations teams aren’t on board with the whole agile thing. They aren’t going to let you change their release processes just to satisfy some fad. Rapid change? Are you nuts? And what about the other end of the value stream, sales? They’re willing enough if it makes them money, but you’d better deliver (which isn’t happening with the operations guys, so you are screwed).

So lets take a step back and look at the value stream. Where do we typically see the most time spent? It’s not development – we’ve been squeezing development in one way or another for decades. However, you can find the most amazing queues in sales. With the rest of the organization moving so slowly, they naturally develop queues as they wait for the work to get done.

The question is, why don’t we start at the back? Why don’t we make the end of the value stream our focus first? We need to stop starting in the middle. Goldratt would have us chasing the bottlenecks. More power to him. If I speed up operations first, I may not see an immediate increase in productivity, but I have created the runway for success. I have them on board and bought in. Now, we move up the value stream to the Development teams. If we can get them performing, then we have already prepared the runway for them. No longer do we give them a fast car and ask them to drive it into the wall. Now they can deliver and they can do it with proper support from operations.

From there we can continue to move up to Sales and the front end of the value stream. They should be an easy sell at this point. So, the question is, why start in the middle?


Filed under: Agile, Coaching, Process, Teams Tagged: Agile, Process, Transition, value stream
Categories: Blogs

Poaching vs. Collaboration

Agile Tools - Tom Perry - Sat, 09/13/2014 - 08:13

adventure-evening-fun-2029-825x550

No one wants advice, only collaboration. – John Steinbeck

Imagine you are working as part of a team on a project. One day your manager approaches you and says, “There is this really high priority project that has come up and we need you and your expertise on it. We are going to move you onto that team for the duration of the project. Is that OK with you?”

How would you feel about that? I know how I would feel. I would feel jerked around. I would not feel in control or part of the decision making. I might even feel that the value of my membership to the team that I’m already on is being discounted. In short, it would suck.

How do you think your team would feel about it? Would they feel like they were able to participate in, let alone determine, the membership of their team? They wouldn’t feel in control of anything either. In fact, they might even feel victimized by the whole experience. They might be thinking, “Geez, we are screwed. How are we going to finish this project without Joe?” They might even wonder why you were the one who was chosen. That could lead to all sorts of fun misunderstandings.

So what would you do instead? After all, there is this project or team that needs help. It’s a top priority – a higher priority than anything else you are working on now. How can we manage this situation without destroying the integrity of the team?

Instead of moving individuals we could take the problem to the whole team. Perhaps a manager would come and sit down with the team and describe what they need. They could explain the trade offs and the specifics of what the other team needs help with. Then they might ask, “Could you guys help this other team out…as a team.”

This would have all sorts of advantages. If a team needs help and you send them just one guy, you’ve increased your team size by one person. If instead, an entire team pitches in to help, then you get the resources of 6 or 7 guys. Forget whatever multiplier effect you might get from a closely knit team – which solution is going to deliver results faster? That’s right, the team of 7. And there is more benefit besides productivity. By engaging the team in this fashion you are asking them to remain a team, and to help another team. Team’s helping teams – what a great idea!

You don’t hurt morale. You leave the decisions on how to manage the problem to the teams – so they feel like they own the problem. They are engaged, they are helping someone else. It really does have a lot going for it.

So what about that other project you were working on? You know, the one that you had to put down to help out with that other team? What about that project? Wasn’t it important too? Sure, but it wasn’t as high a priority, so it waits. This encourages the kind of organizational focus where everyone is attending to the most important issues first, rather than scattering their efforts across multiple lower priority issues in the name of higher utilization or productivity.

So if you are currently in the habit of pulling people off of teams in order to solve resourcing problems, I’m here to tell you that there is another way. If you are open minded enough to give it a try, you might just find that it may be a better way.


Filed under: Agile, Teams Tagged: Collaboration, control, micro management, poaching, resource management, Teams
Categories: Blogs

Scrum Sense News 09/14 – Adventures in Europe

ScrumSense.com - Peter Hundermark - Fri, 09/12/2014 - 13:38

Welcome to our September newsletter and welcome to summer.

Franschhoek_text_LG_SCRT

 

This is the first Scrum Coaching Retreat in Africa. It is an opportunity for you to collaborate with other coaches, learning from each other and producing valuable outcomes that will have lasting benefit to our community and customers.

The theme of this retreat is “small improvements”, recognising that most big changes are better embarked on, digested and internalised one step at a time. Transforming the world of work is a big endeavour. We can contribute by meeting our customers where they are and helping them take one next step.

For first-time visitors to South Africa we promise you an awesome experience in the winelands surrounding our Mother City. Come early or linger an extra week to experience this special place in high summer. For local coaches we promise you deep interactions with some of the best Scrum coaches on the planet.

More information and registration. Twitter hashtag #scrcpt.

Joanne’s Adventures in Europe

CSM in Denmark with Bent MyllerupShortly after joining Scrum Sense in February this year I started my journey to become a Certified Scrum Trainer (CST). The process includes co-training with other CSTs around the world, so that I can get feedback to improve and, once I am good enough, I can get their recommendations that are essential to acceptance. For the past week I have been lucky enough to travel around Europe and co-train with some of the top CSTs and CSCs (Certified Scrum Coaches) in Europe. It has been a wonderful experience for me….more.

 

 

 

Kanban Training

ddab0739-d764-4739-b47d-b43c56234160The popular Applying Kanban (Foundation) course sold out in record time, and all seats have now been filled. We plan to run another course in May 2015, which we have already started taking bookings for. Reserve your place at the May 2015 Applying Kanban (Foundation) course Kanban foundational course provides insight and visibility to the “why” of doing things – Dean Harvey, Nedbank Ltd. We still have a few spaces available for our Improving & Scaling Kanban(Advanced) certified courses which will be taking place in Sandton on the 23-24 Oct 2014. We are running a 3-for-2 special offer, so be sure to secure your place!

 

 

Other News Lean Agile 2014 SA

Peter Hundermark will be presenting at LeanAgile SA 2014 (#LASA) in October.

Scrum Gathering South Africa  20-21 October

Scrum Sense will be at the Scrum Gathering in full force. Catch us presenting on the following subjects:

We hope to see you there. Last years gathering was awesome and packed with amazing speakers from all around the world.

The post Scrum Sense News 09/14 – Adventures in Europe appeared first on ScrumSense.

Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.