Skip to content


About SAFe – Lyssa Adkins

Learn more about our Scrum and Agile training sessions on

Lyssa Adkins, the “Agile Coaches’ Coach” has written a fantastic article sharing her feelings and perspective on SAFe.  (Thanks to Gerry Kirk for bringing this article to my attention!)

As you know, dear readers, my colleague Travis and I are at SAFe Program Consultant training with Dean Leffingwell this week in London, UK.  I have lots of notes even after my first day and I will write one or two articles this week giving you my impressions and highlights.  I have already reviewed all the course materials including appendices, ahead of the actual training. I can say this so far: SAFe has a lot of great things in it, and overall, I think it is a fantastic example of a Pragmatic approach to Enterprise Agile Adoption.  I will definitely be writing more on this idea of Ad Hoc, Pragmatic and Transformative approaches.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Getting Small Stories - Tue, 10/07/2014 - 12:04

In a thread about estimation in hours and whether it’s a good idea (IMO it’s not the best idea by far), this morning Robin Dymond tossed me this challenge:

You have advocated for years that teams should be able to slice stories to the point where they can complete a story in a day. My request is that you show the Agile community how to do that in writing and some exercises that use non trivial examples. I would appreciate learning more about how you do this.

Here, off the cuff, is one reply:

Single Acceptance Test

The most elegant way to do this that I know of is to consider acceptance tests for the feature. Then do them one at a time, simplest first. I first became aware of this idea from Neil Killick (one of the #NoEstimates guys), though I’d like to think I’d done it automatically a million times.

But there is another fun way.

One Dumb Idea

I’m often challenged to come up with something that could be done, even in a week, and that would look like the product. It’s rare that I can’t come up with something. But what happens next is what’s interesting. An example, from memory, cleaned up a bit to make the story clear at small expense to the facts:

Chet and I were visiting a cable TV company. Their challenge was about something they had already done, the old way: “What if our product was pay-per-view movies? The viewer has to be able to select any movie from a menu of them, watch the movie, pause it, wind it back, …” They went on and on. Then they said, “There’s no slice of that that could be done in a week.”

We talked a bit. I asked, “At the beginning of this project, did you have the ability to play a movie over a channel?” They said that they did, because (of course) they had movie channels playing all the time.

So I said, “What if the first slice is that you’re playing some movie on some secret channel, all the time, and if the viewer wants to watch it, he clicks that channel. That would nearly be done already.”

Some of them hated that example. Some liked it. There were lots of objections to how one could imagine that as “done”. The objections were all about additional features of pay-per-view: “He doesn’t get to see the movie from the beginning.” “What if he wants a different movie?” “What if we don’t know his credit card?”

Chet and I probably said a few times “Well, rewinding the movie is a new story,” or “Not switching to the secret channel without his credit card is a new story.” I remember that at one point we said “What if we started just using your boss’s credit card for everyone?”

Pretty soon — in minutes, not hours or days — some engineer in the room said “Well, that wouldn’t work, but what we could do is …” and described something they could have done.

That’s what always happens. Someone comes up with a stupid example of a story that could be done in a day or a week, whatever the then-current target is. That someone is usually me, because I am full of stupid ideas and I don’t mind putting them out there.

Suddenly things change. We’ve gone, in one step, from “impossible” to knowing a stupid, but possible, thing to do. The tone of the meeting changes, instantly, from “no way to do that” to improving the idea or bettering it.

Chet and I have done this, time and again, separately or together, in domains of all kinds. One dumb idea that could almost work is enough to switch the team from “can’t be done” to “yeah, but this would be a better way.”

The Real World

Referring to Alistair Cockburn’s “Elephant Carpaccio” exercise, Robin said:

I am familiar with Alistair’s elephant carpaccio, however his exercise uses a calculator, and developers just don’t think the example is applicable to their problems.

They always think that

A million examples, not in their domain, and they’ll still think that.

Yes, but in the real world, we have to deliver every movie ever recorded, to anyone’s house, in real time, together with all the reviews from the major outlets, with or without surround sound, wide or narrow screen, 3D or flat, with subtitles in every known language including FORTRAN, color-enhanced to support red-green color blindness, using every major credit card plus any authorized Canadian grocery store coupons, with the naughty bits either covered or enhanced, with pause and zoom in available, in fast motion and slow motion as well as regular everyday motion, using no wires or cables of any kind, without emitting any electromagnetic radiation on any spectrum, delivering to any television, computer, tablet, phone, watch, or pinkie ring, at any location in the solar system, with zero delay. You can’t do that in the real world.

Yeah, well, we just did. I doubt it took an hour.


All you need is a stupid idea, or one acceptance test. I’d typically start trying to get one story that a PO could imagine was nearly “end to end”, that can be done in a week. A day probably isn’t something the team can do right out of the box.

Or is it? In our CSD class, we do a real application and we run 90 minute Sprints. The teams deliver multiple stories in those Sprints. Not the first Sprint, mind you. :)

Yabbut …

Robin, of course, seemed to be asking for a more comprehensive compendium of ways to slice stories. I think he just wanted me to go away for a while. It might be fun to generate a whole list of examples. They would all have the same characteristics, though. It seems like you have to sit with the team and talk with them, or at least get them to talk among themselves.

My way requires someone to have a dumb idea, which isn’t that hard, but it also requires them to say it, which is harder. And — I’m just guessing here — they have to be respected enough, or enough of a stranger, to get the idea discussed instead of dismissed out of hand.

Neil’s way, doing a single acceptance test, might be better. I’ll know when I’ve tried it a few times. My way is more fun, though. I’m sure of that.

Categories: Blogs

Announcing The Swarming Development Method

Agile Tools - Tue, 10/07/2014 - 07:53


By now, you’ve probably figured out that I’m laying out all the guidance for using Swarming as a legitimate, full-fledged, Agile method. It looks like this:


There you have it. A complete method for swarming. Wrap it up and ship it.

“But wait!” you say, “You’re not a real methodologist, your just some guy with a blog!” You are absolutely right. What gives me the right to propose a new agile methodology? What kind of egomaniac thinks he can just pop up with a completely new method of team development? Well, actually, it’s not that new. I pulled a lot of the material from a variety of existing sources. I copied the format for the Values and the principles from the Agile Manifesto. Nothing here is all that original. After all, if I’m right, bugs have been doing this stuff without the benefit of my genius for millions of years. Why would I do this?

First, I’d like to state this as emphatically as I can: ANYBODY CAN DO THIS! We can all be copying methods and tweaking them – and we should. No real experience is required. After all, that’s how the guys who came up with Scrum, and Kanban, and XP did it. They copied ideas from Takeuchi and Nonaka, Ohno, Demming, Goldratt, and a whole bunch of others. We need to keep doing that – copying and stealing and mixing and removing bits until we find methods that work even better. Take this opportunity to make a methodology that is an expression of your beliefs. Heck, maybe it expresses the vision of your entire team…or company.

Secondly, there just aren’t enough methodologies out there. Having scrum taking over 80% of the agile project management ecosystem is really, really…boring. Ken Schwaber, one of the creators of Scrum, has always maintained that something better will come along one day. I’m sure that’s true, but it won’t happen unless we are creating a vibrant ecosystem of competing methods. Just having Scrum and Kanban isn’t enough.

So feel free to take this methodology – it’s yours. Run with it (careful, it’s pointy), copy it, break it, fix it, and for God’s sake, make something wonderful.

Filed under: Agile, Swarming Tagged: creation, Manifesto, methodology, practice, Swarming, theft
Categories: Blogs

Skalierung aus der falschen Richtung

Scrum 4 You - Tue, 10/07/2014 - 07:45

Wer darüber nachdenkt, wie man Scrum in großen Projekten macht, fängt meistens mit dem klassischen Bild an: Der Product Owner erstellt das Backlog und dann wird es priorisiert … bla, bla, bla – das ist euch allen mittlerweile klar. Wenn ich aber darüber nachdenke, wo die meisten Features herkommen, wer die Fehler findet, wer sich im Review mit dem Kunden auseinandersetzt, dann wird schnell klar, dass die meisten Backlog Items von den Entwicklungsteams geschrieben werden. Sie müssen sowieso von ihnen entwickelt werden. Schaut man in den Design Thinking Prozess von IDEO, dann wird auch dort sehr deutlich, dass das Entwicklungsteam sich selbst überlegt, was der Kunde am Ende benötigt.

Die Entwicklungsteams selbst erstellen die Backlog-Einträge und priorisieren sie auch selbst. Obwohl ich mir das Video über IDEOs Shopping Cart bestimmt 100 Mal angeschaut habe, hat es nicht wirklich Click gemacht. Mir fällt sogar auf, dass ich in jedem Training immer wieder sage, dass das Team die eigentlichen Backlog Items schreibt, aber – wie gesagt – das Klick, das Heureka, fehlte. Dabei lag es schon seit Jahren auf der Hand. Der Product Owner war in den meisten Projekten damit überfordert, wissen zu müssen, was das richtige Feature ist. Er weigerte sich auch oft, das Backlog zu priorisieren und wusste häufig nicht, ob die Kunden das Feature wirklich wollen. Er brauchte immer das Entwicklungsteam, damit er die richtigen Entscheidungen treffen konnte. So weit so schön, wir haben dann immer tolle Erklärungen gefunden, warum der Product Owner, obwohl er keine Ahnung von der Materie hat, dem Entwicklungsteam sagen müsste, was es zu entwickeln hätte.

Dieses Bild hat ausgedient – Skalierung funktioniert so nicht!

Das geht nur so lange gut, wie man nicht skalieren muss. Dann fällt das ganze Kartenhaus zusammen – in einem solchen Fall mit Product Ownern zu arbeiten, die sich inhaltlich nicht auskennen und daher keine Entscheidungen treffen können, führt zu den gleichen Effekten wie im klassischen Projektmanagement: niemand will Entscheidungen treffen. Der Klick kam bei mir, als mich ein Kunde etwas fragte. Dafür bin ich ihm wirklich dankbar.

In diesem Projekt hatten wir es mit 150 Beteiligten – Wissenschaftlern, Entwicklern, Programmierern, Managern – zu tun. Wir rangen mit tausenden kleinerer und größerer Probleme, und wir machten das durch das Aufstellen von Backlogs transparent. Weil das Management die Sicht auf das Ganze haben wollte (was verständlich und nachvollziehbar ist), tauchte die Frage auf, ob man denn so etwas wie ein Master Backlog habe und ob nicht mit entsprechenden Filter-Funktionen in JIRA sichergestellt werden könne, dass alles wirklich abgearbeitet wird? Die gängige Erklärung ist: Sicher, das geht! Das findet sich auch in allen vorhandenen Bildern zur Skalierung von Scrum. „Aber wieso eigentlich?“, fragte ich meinen Kunden. Das Master Backlog sei doch keine Input Queue, sondern bilde nur die Realität ab. Wir müssten unbedingt vermeiden, dass der Product Owner des Master Backlogs dieses priorisiert. Die Verwunderung war groß, denn jedes Bild in Scrum suggeriert, dass die Macht beim Product Owner liegt. Er füllt den Sprint. Der Product Owner kann dieses Backlog aber gar nicht in eine korrekte Reihenfolge bringen. Es sind zu viele Einträge. Der Product Owner müsste bei einem großen Projekt gottgleich alles beantworten können. Solche Typen gibt es, sie sind aber sehr selten und ihr Gewicht wird in Gold aufgewogen.

Gleichzeitig gibt es dennoch – ob der Product Owner es kann oder nicht – zwei Fragen zu lösen:

  • Sind die neuen Features sinnvoll – sind es also die richtigen Features?
  • Können die Teams diese Features überhaupt umsetzten?

In großen Projekten ist darüber hinaus drittens auch noch die Frage entscheidend, ob man überhaupt alle Abhängigkeiten zwischen den Teams berücksichtigt hat.

Können die Product Owner diese Fragen nicht selbst lösen, dann müssen sie wohl oder übel die Teams selbst fragen. Doch was, wenn die Product Owner es ihren Teams nicht zutrauen, diese Fragen zu beantworten? Sehr oft haben die Product Owner damit auch recht. Häufig gibt es externe Kollegen in den Teams und die wissen gar nicht all das, was die Product Owner wissen. Sie können es noch gar nicht wissen. Dann bleibt nur, die wenigen Experten in den Teams zu fragen, und schon hat man einen Infinite Loop geschaffen.

Mit Selbstorganisation hat das gar nichts zu tun – nur mit noch mehr Kontrolle

Der Wahn, alles müsste transparent und rückverfolgbar sein, auch nach Monaten oder Jahren müsste noch klar sein, welche Zeile Code von welchem Entwickler geschrieben wurde – dieser Wahn ist heute von vielen Entwicklern umgesetzt worden. Dank JIRA, Bamboo, Team Foundation Server und anderen Tools lässt sich ja alles rückverfolgen. All das hat zu noch mehr Kontrolle und noch weniger Selbstverantwortung der Kollegen geführt. Das Schreiben eines JIRA-Tickets ist einfach – da kann ich als Teammitglied schnell das Denken abschalten, denn es wird ja von einem anderen entschieden, ob ich dann daran arbeiten soll. Wieder wird die Verantwortung nach oben delegiert. Die Entscheidung liegt erneut beim Product Owner, der aber nicht für jede Kleinigkeit geradestehen kann. Wo kommt dieser Anspruch eigentlich her? Denn das sollte er in Scrum gar nie können. Nonaka und Takeuchi hätten nicht beschrieben, wie man einen interdisziplinären, cross-funktionalen Management-Prozess entwickeln kann (den Jeff Sutherland zu Scrum ausgebaut hat), wenn sie dabei gleichzeitig an volle Kontrolle gedacht hätten.

In vielen Scrum-Skalierungsansätzen wird aber genau das Gegenteil propagiert. Was mich dabei erstaunt: In Deutschland sind die Modelle, die das Top-Down-Prinzip in der Skalierung von Scrum erklären (SAF) beliebter als in den USA. Hier werden mehr Bücher dazu gekauft, als in den USA (sagt mein Verlag). Da ist was faul. Übrigens funktioniert es auch nicht. Was gut funktioniert: Skaliert wird durch Abgeben der Verantwortung bei gleichzeitiger Standardisierung, und die Berater verdienen damit viel Geld.

Wenn die Backlogs nicht vom Product Owner und seinen Product-Owner-Kollegen aufgestellt und in die „richtige“ Reihenfolge gebracht werden, wer macht es dann? Genau, die Entwicklungsteams! Skalierung ist dann ganz einfach, denn diese Kollegen wissen sehr gut, was als Nächstes getan werden muss. Sie wissen, ob es heute sinnvoller ist, den Defect zu fixen, oder das nächste Feature anzufangen. Sie haben den Kontakt zu den Usern und können viel besser verstehen, was dort gebraucht wird. Können wir aber den Teams trauen? Wie verhindern wird dann Wildwuchs? Wie verhindern wir, dass Dinge gemacht werden, die niemand braucht? Wie verhindern wir, dass die Entwickler nicht businessgetrieben arbeiten, sich in Lösungen verfangen, einer interessanten Idee nach der anderen nachgehen?

Meine provokante These: Lassen wir doch einfach zu, dass es Schwund und Fehlentwicklungen gibt. Es ist viel billiger, als alles überwachen zu wollen. Die teuren Management-Runden, in denen sich Product Owner erklären lassen, was das Richtige ist, ergeben wenig Sinn. Scrum selbst ist das Korrektiv. Wenn eine Entwicklungsmannschaft nicht liefert, keine Lösungen, keine Ergebnisse, keine neuen Erkenntnisse, wenn sich die Entwicklungsteams ums sich selbst drehen, dann wird das doch im Review sichtbar. Dann kann das Management doch eingreifen. Aber es in die Teams hinein zu kontrollieren, das funktioniert nur bedingt. Dabei wäre das sogar möglich: Wer Qualitätsmanagement als Lernprozess versteht und gefundene Fehler nicht als Versagen von Menschen, sondern als gegebene Realität sieht, wer vergossene Milch als Verlust abschreibt und nach vorne schaut, der kommt auch damit klar, dass Nicht-Liefern eine Information ist. Eine Information ans Management, dass gehandelt werden muss.

Aber das erklärt noch nicht, wie Firmen nun selbstorganisiert skalieren können, oder doch? Ich denke schon! Der Trick besteht darin, sich selbst steuernde, cross-funktionale Teams zu etablieren, die innerhalb eines Kontexts nur auf eine einziges Ziel hinarbeiten können. Dieses Ziel wird durch die Vision geschaffen, doch der Weg dahin bleibt den Teams überlassen. Die Teams müssen sich standardisierte Schnittstellen überlegen. So wie das in der Bauindustrie und in der Elektroindustrie doch auch funktioniert. Diese Übergaben werden trainiert, geschult und zertifiziert. Diese Standards zu verändern ist mühsam, aber so können funktionierende, vielleicht nicht immer perfekte Lösungen gefunden werden. Die Rahmenbedingungen werden von der Organisation gesteckt und die Teams so lange darauf geschult, bis sie die Rahmenbedingungen verstanden haben. Teams, die liefern, werden belohnt und die anderen werden lernen, was erfolgreich ist und werden es kopieren. Gleichzeitig überlässt man mehr und mehr Verantwortung den kleineren Funktionseinheiten, den Teams. Ist das perfekt? Ich weiß es nicht, aber Amazon und Google, Facebook und 3M fahren mit diesem Ansatz ziemlich gut.

Related posts:

  1. 5 min on Scrum | Business Value
  2. Dr. Scrum – antwortet
  3. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight

Categories: Blogs

Toyota Kata

TV Agile - Mon, 10/06/2014 - 19:22
Toyota Kata is a structured way to create a culture of continuous learning and improvement at all levels. It is an organizations daily habits or routines forming its “muscle memory” for continuous learning and improvements. The daily habits/routines help us to strive towards our vision, or our state of awesomeness in small focused experiments. What […]
Categories: Blogs

Conceptual Model vs Graph Model

Mark Needham - Mon, 10/06/2014 - 09:11

We’ve started running some sessions on graph modelling in London and during the first session it was pointed out that the process I’d described was very similar to that when modelling for a relational database.

I thought I better do some reading on the way relational models are derived and I came across an excellent video by Joe Maguire titled ‘Data Modelers Still Have Jobs: Adjusting For the NoSQL Environment

Joe starts off by showing the following ‘big picture framework’ which describes the steps involved in coming up with a relational model:

2014 10 05 19 04 46

A couple of slides later he points out that we often blur the lines between the different stages and end up designing a model which contains a lot of implementation details:

2014 10 06 23 25 22

If, on the other hand, we compare a conceptual model with a graph model this is less of an issue as the two models map quite closely:

  • Entities -> Nodes / Labels
  • Attributes -> Properties
  • Relationships -> Relationships
  • Identifiers -> Unique Constraints

Unique Constraints don’t quite capture everything that Identifiers do since it’s possible to create a node of a specific label without specifying the property which is uniquely constrained. Other than that though each concept matches one for one.

We often say that graphs are white board friendly by which we mean that that the model you sketch on a white board is the same as that stored in the database.

For example, consider the following sketch of people and their interactions with various books:

IMG 2342

If we were to translate that into a write query using Neo4j’s cypher query language it would look like this:

CREATE (ian:Person {name: "Ian"})
CREATE (alan:Person {name: "Alan"})
CREATE (gg:Person:Author {name: "Graham Greene"})
CREATE (jlc:Person:Author {name: "John Le Carre"})
CREATE (omih:Book {name: "Our Man in Havana"})
CREATE (ttsp:Book {name: "Tinker Tailor, Soldier, Spy"})
CREATE (gg)-[:WROTE]->(omih)
CREATE (jlc)-[:WROTE]->(ttsp)
CREATE (ian)-[:PURCHASED {date: "05-02-2011"}]->(ttsp)
CREATE (ian)-[:PURCHASED {date: "08-09-2011"}]->(omih)
CREATE (alan)-[:PURCHASED {date: "05-07-2014"}]->(ttsp)

There are a few extra brackets and the ‘CREATE’ key word but we haven’t lost any of the fidelity of the domain and in my experience a non technical / commercial person would be able to understand the query.

By contrast this article shows the steps we might take from a conceptual model describing employees, departments and unions to the eventual relational model.

If you don’t have the time to read through that, we start with this initial model…

2014 10 07 00 13 51

…and by the time we’ve got to a model that can be stored in our relational database:

2014 10 07 00 14 32

You’ll notice we’ve lost the relationship types and they’ve been replaced by 4 foreign keys that allow us to join the different tables/sets together.

In a graph model we’d have been able to stay much closer to the conceptual model and therefore closer to the language of the business.

I’m still exploring the world of data modelling and next up for me is to read Joe’s ‘Mastering Data Modeling‘ book. I’m also curious how normal forms and data redundancy apply to graphs so I’ll be looking into that as well.

Thoughts welcome, as usual!

Categories: Blogs

Environments for Swarming

Agile Tools - Mon, 10/06/2014 - 08:19


What kind of environment would best suit a swarming team? I just stumbled across something called the SOLE toolkit while researching this topic. SOLE stands for Self-Organized Learning Environment. It’s designed for children (start ‘em young) and provides instructions for setting up this special learning environment. The kit recommends the following:

  • One computer per 4 kids
  • A whiteboard
  • Paper and Pens
  • A name tag

I love this! So our self organizing work environment is configured to encourage shared learning on a single machine (pairing anyone?),  plenty of whiteboards (Yes! information radiators), Paper and pens (do stickies and sharpies count?), and a name tag (team identification perhaps?). These very simple environmental constraints are all that are needed to create a self-organizing learning environment (oh yeah, don’t forget the kids).

These sorts of rules are already pretty common on some Agile teams. The pairing, many whiteboards, and lots of notes are hallmarks of enriched learning environments. So this is a great starting point for creating an environment for swarming too. If you haven’t seen the TED talk and the SOLE Toolkit, you should definitely check it out.


Filed under: Agile, Swarming Tagged: Collaboration, environment, kids, Learning, self-organization, TED
Categories: Blogs

Adaptive Licensing – Zulassung medizintechnischer Produkte als Lernprozess

Scrum 4 You - Mon, 10/06/2014 - 07:30

Wer  ein medizintechnisches Produkt auf den Markt bringen möchte, muss einen langen Atem und viel Geld mitbringen. Die zwei wichtigsten Zulassungsbehörden – die FDA in den USA und die EMA in Europa – verlangen Nachweise dafür, dass das Produkt korrekt funktioniert und dass die Vorteile für die Gesundheit die bekannten Risiken überwiegen.

Keiner zweifelt an, dass eine solche Qualitätskontrolle in der Medizintechnik notwendig ist. Und doch gibt es in letzter Zeit vermehrt Überlegungen, wie der Zulassungsprozess sinnvoller gestaltet werden kann.
Derzeit werden Zulassungen erteilt, nachdem Nachweise über Funktionsweise und Wirksamkeit vollständig erbracht worden sind. Unter dem Schlagwort “adaptive licensing” wird eine Alternative verfolgt, die von einer stufenweisen Zulassung ausgeht. So könnten Medikamente oder Geräte zu einem frühen Zeitpunkt für eine Zielgruppe freigegeben werden, die davon in besonders hohem Maße profitiert und daher bereit ist, auch ein höheres Risiko einzugehen. Im Gegensatz zu klassischen klinischen Studien, in denen nur wenige Probanden zur Verfügung stehen, würde das Produkt unter produktionsnahen Bedingungen getestet werden. Die Herstellung würde unter Serienbedingungen, die Anwendung in verschiedenen klinischen Umgebungen laufen, und die Wirkung könnte anhand einer breiten, repräsentativen Bevölkerungsschicht getestet werden.

Zulassung als lernendes System

Eine solche, frühe Zulassung in begrenztem Umfang würde aus dem Zulassungsprozess ein lernendes System machen, das nicht eine, sondern mehrere Zulassungsstufen mit unterschiedlichen Akzeptanzkriterien kennt. Die Vorteile dieser Herangehensweise liegen auf der Hand: Patienten, die nicht mehr Jahre warten können, bekämen Zugang zu medizintechnischen Innovationen. Hersteller können bereits vor der finalen Zulassung umfangreiche Informationen zu Funktion und Wirksamkeit sammeln und Anpassungen noch während des Entwicklungsprozesses vornehmen. Und die Zulassungsbehörden bekämen mit jeder Zulassungsstufe ein akkurateres Bild davon, ob das Produkt die Anforderungen für die finale Freigabe erfüllt. Dadurch sollte die Anzahl an Recalls (Produkte, die nach der Zulassung wieder vom Markt genommen werden müssen) sinken. Am Ende profitieren alle davon.

Die Reform des Zulassungsverfahrens wird nicht von heute auf morgen geschehen. Doch das hindert uns nicht daran, die Produktentwicklung schon jetzt so zu gestalten, dass eine stufenweise Zulassung im Prinzip möglich wäre. Mit Scrum haben wir eine iterative und inkrementelle Produktentwicklung, mit der das Produktdesign kontinuierlich validiert werden kann. So ist die Prüfung der Machbarkeit kein Konzept mehr, sondern empirisch nachweisbar. Das Produkt ist zu jedem Zeitpunkt auf einem Stand, auf dem es prinzipiell ausgeliefert werden könnte. Projektfortschritte sind nachvollziehbar und der geschaffene Wert lässt sich beziffern.

Der genaue Weg dorthin wird in den nächsten drei Beiträgen genauer beschrieben:
1) Lieferung von Produkt- statt Komponenteninkrementen
2) Aufbau eines cross-funktionalen Teams, damit 1) machbar ist
3) Einsatz von Reviews, um Validierung nach IEC 62366 zu erlangen

Referenz: If everyone hates the FDA approval process, let’s fix it

Related posts:

  1. Scrum | Level of Done | Die Organisation
  2. 5 minutes on regulations – wie gute Prozesse in der Medizintechnik Innovation verhindern
  3. Was Unternehmen die Zukunft kostet

Categories: Blogs

If you don't care to know about the details of IT, I'm going to bet that your IT is not going to work reliably

In the last while, I've encountered a few large enterprises that had chosen to outsource pretty much all their IT capability.  That is, for the most part, all the actual activity related to IT delivery and IT support are done by third-party vendors.  Full-time staff, for the most part, only manage vendor activities but don't do any of the activities themselves.
From what I can gather, the nominal rationale for the outsourcing is primarily about two things:
  1. Reducing cost: The third party vendor costs less than in-house staff
  2. Delegating risk: The risk moves to the third party vendors
What I suspect is the actual rationale is something along the lines of... 
"We have not been good at IT, we don't know how to fix it BUT if we outsource it, we don't have to think about it."The problem is the subsequent phenomenon that inevitably occurs.  Because, the full-time staff are only managing and not doing, they eventually (and by "eventually", I mean "very quickly") lose the ability to understand what is going on.  Once they lose the ability to understand what's going on, they lose the ability to effectively manage.
Is IT being delivered and supported efficiently?  Can't tell.Is our IT risk being managed effectively? Can't tell.
No reduced (overall) cost.  No shared risk.  No ability to tell this has happened.Martin alludes to this lesson in Utility vs Strategic Dichotomy.
If you don't care to know about the details of IT, I'm going to bet that your IT is not going to work reliably.
Categories: Blogs

Swarming Resources

Agile Tools - Sun, 10/05/2014 - 05:34


Here are some of the books and web sites that researched as part of my investigations into swarming. There are a few that I should probably re-read too. That said, if you are interested in swarming, you could use some of these references for starting points.


The Wisdom of Crowds – James Suroweicki

Suroweicki’s book was my introduction to the power of self-organizing groups. He is a very engaging writer. It’s a fun read and serves as a good starting point for further research.

Bioteams – Ken Thompson

The Thompson book is the first that I found that attempts to apply the theory of swarming to teams of people. It’s oriented to the use of mobile devices and does a good job of positing the simple rules that might be used by swarming teams.

Emergence – Steven Johnson

Steven Johnson’s book is similar to Suroweiki’s, but Johnson’s work is more thorough and academic in tone. He does a great job of explaining some very complicated ideas well.

Micromotives and Macro Behavior – Thomas Schelling

 This guy is a nobel laureate in economics, so I guess he knows what  he’s talking about. I loved the introductory chapters, but after that he lost me. It gets really dense really fast.

The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations – Ori Brafman and Rod Beckstrom

I really loved this book. Brafman and Beckstrom did a fabulous job of writing a very engaging book about self-organizing…organizations. This book does the best job of giving you real examples of groups of people swarming.

Swarm Creativity – Peter Gloor

Peter Gloor’s book is mostly focused on swarming as a way of driving innovation in teams. He also examines ways that we can find collaborative networks (COINS) within existing organizations.

Swarm Intelligence: A Whole New Way to Think about Business – Eric Bonabeau and Christopher Meyer

Bonabeau and Meyer have made the transition from academics to business. They take the principles of swarming and apply them to business problems.

Web sites

BioTeams – Companion to the book

Systems Thinking – A catalog of systems theory and emergent behavior links

CalResCo Complexity Writings – a collection of academic papers on emergent and complex behavior

Swarm Theory –  a great Nat Geo article about swarming

Wikipedia article on swarms

Rules for Flocking Behavior

Boids – If you want to play with simulations of swarming behavior, this is a great start

The Science of Biological Swarms

Swarm Creativity – companion site to Peter Gloor’s book

Research Project from the MIT Center for Collective Intelligence

Links on Complexity, Self-Organization and Artificial Life

Swarm Intelligence – more links

NY Times article on swarming

Filed under: Agile, Swarming Tagged: books, online, research, resources, Swarming, web sites
Categories: Blogs

Project Anarchy

Agile Tools - Sat, 10/04/2014 - 06:23


Recently I’ve been writing a series of posts on a rather radical methodology that I call Swarming. I describe it as a method that enables individuals to become part of whatever team they like and work on whatever they want. They can follow their passions wherever they choose (in fact they must) without interference or even guidance from a hierarchy (managers, coaches – nobody). I’m quite keen on the ideas, but it occurred to me that what I’m advocating might be indistinguishable from anarchy!

So I hustled over to wikipedia to look up anarchy. Here’s what I found:

The word anarchy comes from the ancient Greek ἀναρχία, anarchia, from ἀνan, “not, without” + ἀρχόςarkhos, “ruler”, meaning “absence of a ruler”, “without rulers”).

Oh my. That is what I’m talking about! One of the fundamental rules of swarming is there is no single controlling entity or “ruler”. So swarming could indeed be described as a form of anarchy by this definition. Now it turns out that anarchy has more than one definition, and in common parlance, the word seems to be mostly associated with the political definition:

Proponents of anarchism (known as “anarchists”) advocate stateless societies based on what are sometimes defined as non-hierarchical organizations, and at other times defined as voluntary associations.

That’s interesting. That is pretty much what I have been advocating. Maybe I am an anarchist after all. But I’m from Seattle, and here in the Northwest we know what anarchists are. We have a bunch of them around here. Anarchists are gangs of masked hooligans that roam the streets and break shop windows whenever the WTO comes to town. They’re a real pain in the ass. I’m not one of those clowns.

However, strangely enough, as I become more experienced with software development projects, the less I find myself trusting traditional management institutions. I yearn for a place that is free of hierarchy (non-hierarchical organizations), where we have the opportunity to pursue whatever tickles our fancy.

But allow me to make this argument: Swarming does have very simple rules. I don’t think of anarchy as having rules, so I don’t believe that Swarming can be called anarchy. Actually there is a variant of anarchism that fits my notion of Swarming rather well: anarcho-syndicalism.

Syndicalists consider their economic theories a strategy for facilitating worker self-activity and as an alternative co-operative economic system with democratic values and production centered on meeting human needs.

Ooh! That’s much more like it! What a mouthful. I especially like the “meeting human needs” part. Wow. So that’s what I am. Damn, I guess Brian Marick was right.


Filed under: Agile, Swarming Tagged: anarchy, freedom, non-hierarchical, politics, Swarming
Categories: Blogs

delar0cha: adsdata: 2014 Ads+Data design offsite. The talent...

Business Craftsmanship - Tobias Mayer - Fri, 10/03/2014 - 19:39



2014 Ads+Data design offsite. The talent at this table is immeasurable.

A colleague and collaborateur is moving on to new pastures. Farewell, Leonardo. I shall miss you, and our inspiring idea-building conversations.

Categories: Blogs

Partnership & Possibilities – Episode 1, Season 6

Partnership & Possibilities - Diana Larsen - Fri, 10/03/2014 - 17:30

Partnership & Possibilities: A Podcast on Leadership in Organizations

What are you seeing in your organization relating to women’s experience in the workplace? How are you involved in the growing conversation?

Leave a comment on this blog or email us at


[Intro] Subject of “Women in Agile” still a hot topic at Agile 2014 Conference in Orlando.

[03:20] “…this is the first year that the Agile Alliance has been very overt about their anti-harassment policy…”

[04:35] Agile conferences have a much higher proportion of women attending than any other kind of technical conference.

[07:03] It’s time to bring back conversations about “Gender Intelligence” and the often differing working styles between men and women.

[9:50] Attendees are more open and feel safer about having these kinds of conversations at Agile conferences.

[12:50] It is a courageous thing for a young woman to decide to stand out in the technical world due to very real danger of death threats, rape threats, and so on.
[17:20] The sense of male entitlement, and the belief that “I got to where I am because I’m so smart.”


[Agile 2014 Orlando Session] Women in Agile: Creating Teams That Embrace Diversity (Diane Zajac-Woodie, Doc Norton)

Categories: Blogs

The Agile Reader – Weekend Edition: 10/03/2014 - Kane Mar - Fri, 10/03/2014 - 12:51

You can get the Weekend Edition delivered directly to you via email by signing up

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture in #Kolkata
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM), apply now! (#Mumbai) #job
  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture (#Hyderabad)
  • #Accenture is hiring! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Bangalore, apply now! #job
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Gurgaon, apply now at #Accenture! #job
  • What does the Scrum Master actually do in agile projects? –
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Mumbai. #Accenture
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Mumbai, apply now! #job
  • #JOB: Wir suchen motivierte und engagierte Coaches (m/w) für #agile Projekte #Scrum #Kanban
  • #JOB: Wir suchen motivierte und engagierte Coaches (m/w) für #agile Projekte #Scrum #Kanban
  • #JOB: Wir suchen motivierte und engagierte Coaches (m/w) für #agile Projekte #Scrum #Kanban
  • Business Analyst – Ecommerce / Agile / Scrum / Web Applications – Searchability – Chester Job Chester
  • Agile Tools – Tom Perry: Disappearing Radiators #agile #scrum
  • New #job opening at #Accenture in #Mumbai! Agile Methods (Scrum/FDD/XP/Crystal/DSDM)
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM), apply now! (#Mumbai) #job
  • RT @yochum: Agile Tools – Tom Perry: Disappearing Radiators #agile #scrum
  • Certified #Scrum Master weekend course in London – 1-2 Nov – £895 price expires at midnight – #agile
  • What Characteristics Make Good Agile Acceptance Criteria? –
  • Don’t Underestimate Discipline: The Real Key to Agile Development #nearshore #agile #scrum #software #development
  • New #job opening at #Accenture in #Mumbai! Agile Methods (Scrum/FDD/XP/Crystal/DSDM)
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Mumbai! #job
  • New #job: Senior Project Manager (Agile/Scrum) Location: London Salary: GBP55kpa – GBP65kpa .. #ITjobs
  • RT @technofeliz: Scrum et Agilité is out! Stories via @TheAgileNetwork @ShirlyRonenRL @lyssaadkins
  • RT @technofeliz: Scrum et Agilité is out! Stories via @TheAgileNetwork @ShirlyRonenRL @lyssaadkins
  • #Agile – How does Planning Poker work in Agile? –
  • Computer People: Senior Project Manager (Agile/Scrum) #ITjobs #technologyjobs #jobs
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Kolkata, apply now! #job
  • How I Helped Start the Agile/Scrum Movement 20 Years Ago via @wordpressdotcom #Agile #Scrum
  • RT @mikewcohn: Don’t equate story points to hours: #agile #Scrum
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM), apply now! (#Kolkata) #job
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Mumbai! #job
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Bangalore. #Accenture
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Gurgaon. #Accenture
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #NewDelhi, apply now at #Accenture! #job
  • RT @AgileSparrow: Our program is featured on @Hurriyet, and here is the link: #agile #scrum
  • How to Plan an Agile Sprint Meeting? –
  • RT @mikewcohn: Don’t equate story points to hours: #agile #Scrum
  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture in #Chennai
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Mumbai! #job
  • How Avanade develops #agile coaches to be change agents to drive #awareness & #adoption #scrum
  • RT @AgileSparrow: Our program is featured on @Hurriyet, and here is the link: #agile #scrum
  • Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • RT @yochum.Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • RT @yochum: Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • RT @yochum: Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • RT @yochum: Key Principles for Reducing Continuous Integration Build Time #agile #scrum
  • #Accenture is hiring! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Pune, apply now! #job
  • #Accenture is hiring! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Chennai, apply now! #job
  • Scrum Framework Explained: #scrum #agile
  • Categories: Blogs

    Making System Interventions with Kanban Thinking

    AvailAgility - Karl Scotland - Fri, 10/03/2014 - 10:00

    This post pulls together a number of ideas on interventions into a single place, and will become the content for a page on Interventions on the Kanban Thinking site.

    What is an intervention?

    An intervention is an act of becoming involved in something in order to have an influence on what happens. It is an active and participatory action, as opposed to a passive and observational instruction. Thus in Kanban Thinking, interventions are ways of interacting with a kanban system with the intent of improving it and having a positive impact.

    There are 5 types of Kanban Thinking intervention, which can be considered as heuristics to help the discovery of appropriate practices and techniques for a system’s context. These heuristics may point to the purpose behind known and proven practices, or they may lead to the identification of new and alternative practices. They are:

    • Study the Context
    • Share the Understanding
    • Stabilise the System
    • Sense the Capability
    • Search the Landscape
    Study the Context

    What could be done to learn more about customer and stakeholder needs, the resultant demand and how that demand is processed?

    Kanban Thinking is based on a philosophy of “start where you are now” and the foundation for this evolutionary approach is Studying the Context. In his book “The New Economics”, W. Edwards Deming famously said, “there is no substitute for knowledge”, and it is the acquisition of this knowledge about the current situation that leads to an appreciation of how to improve it.

    Various practices are widely used to study different aspects of the system. Empathy Mapping is one way of learning more about customer and stakeholder needs. The work that they request as a result of those needs can be studied with demand analysis and profiling to determine classes of service and response. The way that work is then progressed, from concept to consumption, can be examined using forms of value stream mapping.

    Share the Understanding

    What information is important to share, and how can tokens, the inscriptions on them, and their placements, provide a single visual model?

    Sharing the Understanding of the current situation, typically in the form of a kanban board, creates an environment where people are more intrinsically motivated. The ability to see what needs work provides autonomy, the ability to see where improvements can be made provides mastery, and the ability to see where to focus provides purpose.

    Potentially, lots will have been learned from studying the context, so it is important to decide what is the most relevant information to share to avoid being overloaded with too much noise. That information can then be visualised using various patterns based on the acronym TIP; Token, Inscription, Placement. Tokens are the cards, stickies or other tangible representations of the work, where aspects such as shape, size, colour or material can represent different information. Inscriptions are items of information added onto the tokens, where words, dates, pictures or symbols can all be used with suitable formatting. Placements are the Tokens are placed on the board to convey information, where horizontal, vertical and relative positioning can all be meaningful.

    Stabilise the Work

    What policies could help limit work in process, and remove unnecessary or unexpected delays or rework?

    A kanban system which is stable is more likely to be able to evolve and have resilience in the face of change. Systems can be considered to have boundaries or constraints, and those with too loose constraints will devolve into chaos, whereas those with too tight constraints will become brittle with bureaucracy. Stabilising the Work is achieved with enabling constraints, open enough to avoid restriction and prescription, yet limiting enough to stimulate expansion and new possibilities.

    Defining work in process limits is a primary means of stabilising the work. One approach is to start with the current work in process (WIP), and look to gradually reduce it. Alternatively, the WIP could be drastically reduced to stabilise quickly, and then gradually increased to a more optimal level. A middle ground could be to base an initial WIP in the size of the team, such as one work item per person. How WIP is spread across the system is also a factor, from a single limit covering everything (CONWIP) to a different limit per stage or column.

    WIP is a form of explicit policy, and other common forms are Definitions of Ready and Done and similar, simple quality criteria. Additionally, Test Driven Development can be considered an explicit policy on how software is written to create a stable code-base.

    Sense the Capability

    What measures and meetings might create insights and guide decisions on potential interventions?

    As well as acquiring knowledge on what the work is, and how it gets done, it is also important to know how well it gets done. Sensing the Capability of a kanban system involves getting a feel for its performance by both measuring and interacting with it. Metrics provide an objective, quantative sense of capability. Meetings, and other feedback cadences, provide a subjective and qualitative sense of capability.

    Measures should be derived from the desired impact, and the outcomes which would make the impact. If Flow is the desired impact, being more responsive might be a good outcome, and thus Lead Time might be a good measure. Additionally, the subsequent behaviours, both good and bad, which a measure might drive should be considered, and trade-offs can be made by having a set of balancing metrics. A focus on Lead Time might result in a reduction in Quality by cutting corners, so measuring Released Defects could help balance that trade-off.

    Meetings provide a cadence with regular interactions can generate feedback. A simple metronomic cadence can tie various events such as planning, reviewing and retrospection to a single rhythm, or a polyrhythmic cadence can decouple these events into multiple rhythms. Another option is for some events to be asynchronous and triggered by the work rather than time-driven.

    Search the Landscape

    What small experiments could be run to safely learn the impact of different interventions?

    Searching the Landscape of a kanban system involves looking at a range of possible interventions and experimenting to discover what impact they have. Those that have a positive impact should be pursued and amplified. Those that turn out to have a negative impact should be reversed and dampened. This searching can be thought of as exploring the evolutionary potential of the present state, as opposed to defining a future state and trying to move towards it.

    Defining an experiment involves proposing a hypothesis that has a rationale behind it, can be measured in order to validate or falsify it, and can be easily recovered from in case of unanticipated results. The intentional act of documenting the experiment, using formats such as A3s, encourages disciplined thinking and avoids falling into the trap of retrospective coherence to explain results.

    Searching the Landscape is an exercise in continual curiosity about how to evolve and improve the kanban system, increasing impact through further insights, interactions and interventions.

    Categories: Blogs

    Selbstorganisation braucht Führung: Sich selbst und andere begeistern

    Scrum 4 You - Fri, 10/03/2014 - 07:33

    Mittlerweile schreibe ich meine Beiträge für den Blog mit echter Begeisterung. Und ich stelle fest: Dieser Zustand wirkt sich sehr positiv auf die Ergebnisse und den Schreibprozess aus. Mehr Spaß und Engagement beim Verfassen und schnellere und meiner subjektiven Einschätzung nach auch immer bessere Ergebnisse. Erfolgreiche Arbeit und Begeisterung scheinen in einem unmittelbaren Zusammenhang zustehen.

    In meinen ScrumSupplement Trainings fragen mich Teilnehmer immer wieder, wie sie die Motivation ihrer Teams oder einzelner Mitarbeiter wirkungsvoll verbessern können. Frage ich genauer nach, scheinen mir die Teams eigentlich durchaus motiviert. Sie machen ihren fachlichen Job, praktizieren mehr oder weniger brav Scrum. Was den Führungskräften bei ihren Teams und Mitarbeitern fehlt, ist in der Regel eindeutig (mehr) Begeisterung für die “gute Sache”. Auf weiteres Nachfragen verbinden meine Teilnehmer mit dem Phänomen Begeisterung hohes Engagement, Herzblut, positive Stimmung, Teamgeist, Spaß, weniger Widerstände und natürlich in erster Linie eine optimale Performance. Es geht ihnen also darum, grundsätzlich motivierte Menschen im Arbeitsprozess in einen Zustand der Begeisterung zu bringen. Ein durchaus verständliches und legitimes, aber auch anspruchsvolles Anliegen von Führung.

    Doping für Geist und Gehirn

    Der Duden definiert Begeisterung als “Zustand freudiger Erregung, leidenschaftlichen Eifers und hohen Engagements”. Klingt natürlich gut und erklärt, warum der Zustand der Begeisterung in verschiedensten Zusammenhängen so attraktiv erscheint. Der berühmte Hirnforscher Gerald Hüther meint dazu: “Das ist der Grund, warum wir bei all dem, was wir mit Begeisterung machen, auch so schnell immer besser werden. Jeder kleine Sturm der Begeisterung führt gewissermaßen dazu, dass im Hirn ein selbsterzeugtes Doping abläuft. So werden all jene Stoffe produziert, die für alle Wachstums- und Umbauprozesse von neuronalen Netzwerken gebraucht werden. So einfach ist das: Das Gehirn entwickelt sich so, wie und wofür es mit Begeisterung benutzt wird.” (Gerald Hüther, “Begeisterung ist Doping für Geist und Hirn” offizielle Webseite) Kleine Kinder sind 20-50 Mal pro Tag in einem Zustand großer Begeisterung und lernen dabei meist rasend schnell. Als frisch gebackener Großvater einer Enkelin kann ich das nur bestätigen. Wir Erwachsenen haben diese natürliche Begeisterungsfähigkeit im Laufe unserer Biografie (individuell allerdings sehr unterschiedlich) leider stark abgebaut, aber nicht grundsätzlich verlernt, wie jeder bei sich selbst immer wieder erleben kann. Es besteht also Hoffnung.

    Um andere Menschen mit Begeisterungshormonen zu “dopen” muss man:

    1. Selbst begeistert sein, sich selbst begeistern können. Nur wer selbst begeistert ist, kann andere wirklich begeistern, oder um mit Augustinus Aurelius (354-430, römisch-karthagischer Philosoph, Rhetoriker und Theologe) zu sprechen: “Nur wer selbst brennt, kann Feuer in anderen entfachen.” Will ich andere begeistern, muss ich mir also die Frage stellen, ob ich von (m)einer Sache wirklich selbst begeistert bin. Das Entscheidendste für die eigene Begeisterung ist es, dass das, worum es geht, von großer Bedeutung, von hoher Wichtigkeit für mich ist und dass ich es selbst und aus eigener Motivation gewählt habe. Dass es meine Wahl und ureigene Entscheidung war und etwas bei mir auslöst, das da heißt, ich will das unbedingt tun/haben (nicht “ich muss”). Sich selbst für etwas begeistern heißt, die Möglichkeit darin zu sehen, sich selbst verwirklichen und seine Fähigkeiten und Stärken optimal einsetzen zu können. Dies bedeutet ein attraktives Spielfeld für sich zu generieren, um erfolgreich sein zu können und die Aussicht auf Freude am Tun und im Idealfall Erfolg zu haben. Begeisterung heißt auch, sich von anderen unabhängig zu machen. Darum gilt es im “Ernstfall”, das eigene Begeisterungslevel zu prüfen und sich zu fragen, ob es ausreicht, um andere mitzunehmen und anzustecken. Und wenn nicht: Was hindert mich und was brauche ich als Führungskraft noch?
    2. Dialoge inszenieren. Begeisterung bei anderen entsteht in erster Linie nicht durch einseitige Monologe, sondern durch Austausch im Dialog. Das bedeutet, sich nicht nur für mich und meine eigene aktuelle Begeisterung, sondern sich auch für den anderen zu interessieren, adäquat auf ihn zu reagieren und ihm zuzuhören. Empathie und Einfühlungsvermögen sind hier die Stichworte um a) das Gegenüber einschätzen zu können, und es b) nicht zu überfordern, ihm nichts mit aller Macht überzustülpen. Begeistern kann man den, der bereit ist (bewusst/unbewusst), sich begeistern zu lassen. D.h. manchmal brauchet es erst Zeit zur Vorbereitung. Nur so wird er meine Sache mit der Zeit zu seiner machen. Denn nur wenn er meine zu seiner Sache macht, entsteht seine Begeisterung (siehe oben).
    3. Gezielt Emotionalität antriggern, eine “emotionale Epidemie” auslösen. Begeisterung ist in einem hohen Maße ein positiv-emotionales Phänomen. Um die emotionale Ebene bei anderen anzusprechen, empfiehlt sich eine lebendige Sprache mit Metaphern und Sprachbildern. Auch der intensive Einsatz von Visualisierung weckt Emotionalität – aber nicht unbedingt Power Point, sondern selbst gemalte Flipcharts, Fotos und Bilder mit hoher Aussagekraft usw. Es empfiehlt sich, die eigene Gefühlslage offenzulegen und seine positiven, animierenden Emotionen, wie Freude, Lust, Neugier, Stolz etc., anzusprechen. Und natürlich kann die gesamte Palette wirkungsvoller Rhetorik gezielt eingesetzt werden. Dazu findet man jede Menge schlauer Ratgeber in Form von Büchern oder im Netz. Emotionen haben wissenschaftlich nachweisbar den Charakter von Viren, d.h. sie sind sozial äußerst ansteckend. Es empfiehlt sich also, in Situationen die man emotional aufladen will, zuerst bei besonders empfänglichen Personen anzufangen und auf den Ansteckungseffekt zu setzen. Werden diese zu begeisterten “Missionaren”, können sie eine gewünschte “Epidemie der Begeisterung” unterstützen. In Berichten über besonders erfolgreiche Führungskräfte, ob in Sport oder Wirtschaft, kann man dieses Phänomen immer wieder nachlesen. Sie können in besonderem Maße andere mit ihrer Begeisterung infizieren.
    4. Die Individualität meiner Gegenüber gezielt berücksichtigen und nutzen. Erwachsene Menschen haben biographisch sehr unterschiedliche Begeisterungsmuster. Ich zum Beispiel bin ein sehr begeisterungsfähiger Mensch und daher schnell und ausdauernd von allem Möglichem begeistert und zu begeistern. Meiner lieben Frau gehe ich damit immer wieder mal auch gehörig auf die Nerven, denn sie braucht deutlich länger, um sich für etwas zu begeistern und hat auch ein anderes Intensitätsniveau. Es gilt also im Dialog herauszufinden, wo beim anderen die Ansatzpunkte Sinne von Begeisterung liegen, an denen er erreichbar und ansprechbar ist. Braucht er Visionen, ein klares Ziel, Herausforderung, Sicherheit, Erfolg, Struktur, Freiräume? Ist es eher Emotionalität oder Rationalität, will er spielerisch handeln können, ernsthafte Aufgaben übernehmen, braucht er Erfolgsorientierung, Prozessorientierung, Bedenkzeit, Ehrgeiz, usw.? Und, manchmal hilft alles nichts, es entwickelt sich kein Begeisterungspotential. Vielleicht genügt dann auch die “gewöhnliche Standardmotivation”.

    Fazit: Selbstorganisation braucht Führung. Führung in der Selbstorganisation braucht Begeisterung. Für Management und Führung ist es eine zentrale Aufgabe, Anstöße zu geben, Bewegung zu erzeugen, die zu eigendynamischen Prozessen von Selbstorganisation führen. Hohe Motivation, im Idealfall echte Begeisterung, gewährleistet optimal, dass erwünschte Ziele und Ergebnisse auch erreicht werden können. Kein Team wird Weltmeister, wenn es sich nicht an seinen Aufgaben berauscht, in einen Flow kommt und begeistert alle seine Ressourcen nutzt und einsetzt.

    Literaturtipp: Boris Gloger; Dieter Rösner: Selbstorganisation braucht Führung. Die einfachen Geheimnisse agilen Managements. Hanser 2014.

    Related posts:

    1. Über das Schreiben | Leidenschaft
    2. Neues Buch: Selbstorganisation braucht Führung
    3. Führung ja, nein, jein?

    Categories: Blogs

    Disappearing Radiators

    Agile Tools - Fri, 10/03/2014 - 07:24


    A little while ago I wrote an article sharing all the amazing information radiators that you can find in a 1st grade classroom. It’s been a while since that eye opening experience and I found myself at “curriculum night” at her middle school. As I wandered from class to class, listening to teachers drone on about their teaching philosophy, I found myself once again staring at the walls, and yet again they seemed to be telling me a story.

    In my first article I was astonished by the richness and variety of information radiators that you find in the typical elementary school classroom. Nary a square inch of wall space is wasted. Middle school, as it turns out, is somewhat different. In middle school there was still information on the walls, but it was more subdued and there was less of it. You can actually find bare stretches of wall space. Not many, but definitely more than what you see in elementary school.

    As I sat there in those dreadful little plastic chairs, I wondered, “Do we put less information up on the walls as we get older?” What will I find in the classrooms when my daughter is in high school? In college? I remember the classrooms in my college well, and there were often entire rooms with nothing at all on the walls. Why is that?

    So here I am today, living like a nomad in that information radiator desert we call a corporation. Simply asking people to put a task board up on the wall is a revolutionary idea. What happened to us? Do we stop learning? Do we not require as much information?

    I don’t think so. Working in technology, all we do is learning: about our customers, about technology, about the business domain. If anything, we are required to learn at what feels like an ever faster rate with each passing year. For instance, I know C/C++, which qualifies me as a Jurassic techno-dinosaur. I know Java too, which probably brings me up to the Cretaceous period (Woolly Mammoth?). These days there are functional languages that just completely leave me in the dust. The lizard brain just can’t keep up. We live in a world now where our ability to learn is being constantly tested. With each new silicon valley startup, the pressure increases.

    So, why on earth do we leave all those wonderful, rich, learning environments behind? Do our inner worlds become so abundant and complex that we no longer benefit from the additional input from the external world? I doubt it. I feel like I need to start a campaign to bring back the information radiator. Agile task boards are a good start, but there is so much more we could be doing.


    Filed under: Agile Tagged: class, classroom, data, information, information radiators, Learning, school
    Categories: Blogs

    Management Feedback: Are You Abrasive or Assertive?

    Johanna Rothman - Thu, 10/02/2014 - 15:37

    Let me guess. If you are a successful woman, in the past, you’ve been told you’re too abrasive, too direct, maybe even too assertive. Too much. See The One Word Men Never See In Their Performance Reviews.

    Here’s the problem. You might be.

    I was.

    But never in the “examples” my bosses provided. The “examples” they provided were the ones when I advocated for my staff. The ones where I made my managers uncomfortable. The examples, where, if I had different anatomy, they would have relaxed afterwards, and we’d gone out for a beer.

    But we didn’t.

    Because my bosses could never get over the fact that I was a woman, and “women didn’t act this way.” Now, this was more than 20 years ago. (I’ve been a consultant for 20 years.) But, based on the Fast Company article, it doesn’t seem like enough culture has changed.

    Middle and senior managers, here’s the deal: At work, you want your managers to advocate for their people. You want this. This is a form of problem-solving. Your first-line and middle managers see a problem. If they don’t have the entire context, explain the context to them. Now, does that change anything?

    If it does, you, senior or middle manager, have been derelict in your management responsibility. Your first-line manager might have been able to solve the problem with his/her staff without being abrasive if you had explained the context earlier. Maybe you need to have more one-on-ones. Maybe all your first-line managers could have solved this problem in your staff meeting, as a cross-functional team. Are you canceling one-on-ones or canceling problem-solving meetings? Don’t do that.

    Do you have a first-line manager who doesn’t want to be a manager? Maybe you fell prey to the myth of promoting the best technical person into a management position. You are not alone. Find someone who wants to work with people, and ask that person to try  management.

    We all need feedback. Managers need feedback, too. Because managers leverage the work of others, they need feedback even more than technical people.

    If you think a manager on your management team is “too” abrasive or assertive,” ask yourself, is this person female? Then ask yourself, “Would I say the same thing if this person looked as if she could be a large sports figure, male attributes and all?”

    You see, the fact that I have the physical attributes of a short, kind-of cute woman has not bothered me one bit. I feel seven feet tall. I often act like it. I am not afraid to take chances or calculated risks. I am not afraid to talk to anyone in the organization about anything. How else would I accomplish the work that needs to be done? (You may have noticed that I write tall, too.)

    Abrasive and assertive are code words for fearless problem solvers. Don’t penalize the women—or the men—in your organization who are fearless problem solvers.

    Categories: Blogs

    NServiceBus 5.0 behaviors in action: routing slips

    Jimmy Bogard - Thu, 10/02/2014 - 14:57

    I’ve wrote in the past how routing slips can provide a nice alternative to NServiceBus sagas, using a stateless, upfront approach. In NServiceBus 4.x, it was quite clunky to actually implement them. I had to plug in to two interfaces that didn’t really apply to routing slips, only because those were the important points in the pipeline to get the correct behavior.

    In NServiceBus 5, these behaviors are much easier to build, because of the new behavior pipeline features. Behaviors in NServiceBus are similar to HttpHandlers, or koa.js callbacks, in which form a series of nested wrappers around inner behaviors in a sort of Russian doll model. It’s an extremely popular model, and most modern web frameworks include some form of it (Web API filters, node, Fubu MVC behaviors, etc.)

    Behaviors in NServiceBus are applied to two distinct contexts: incoming messages and outgoing messages. Contexts are represented by context objects, allowing you to get access to information about the current context instead of doing things like dependency injection to do so.

    In converting the route supervisor in my routing slips implementation, I greatly simplified the whole thing, and got rid of quite a bit of cruft.

    Creating the behavior

    To first create my behavior, I need to create an implementation of an IBehavior interface with the context I’m interested in:

    public class RouteSupervisor
        : IBehavior<IncomingContext> {
        public void Invoke(IncomingContext context, Action next) {

    Next, I need to fill in the behavior of my invocation. I need to detect if the current request has a routing slip, and if so, perform the operation of routing to the next step. I’ve already built a component to manage this logic, so I just need to add it as a dependency:

    private readonly IRouter _router;
    public RouteSupervisor(IRouter router)
        _router = router;

    Then in my Invoke call:

    public void Invoke(IncomingContext context, Action next)
        string routingSlipJson;
        if (context.IncomingLogicalMessage.Headers.TryGetValue(Router.RoutingSlipHeaderKey, out routingSlipJson))
            var routingSlip = JsonConvert.DeserializeObject<RoutingSlip>(routingSlipJson);

    I first pull out the routing slip from the headers. But this time, I can just use the context to do so, NServiceBus manages everything related to the context of handling a message in that object.

    If I don’t find the header for the routing slip, I can just call the next behavior. Otherwise, I deserialize the routing slip from JSON, and set this value in the context. I do this so that a handler can access the routing slip and attach additional contextual values.

    Next, I call the next action (next()), and finally, I send the current message to the next step.

    With my behavior created, I now need to register my step.

    Registering the new behavior

    Since I have now a pipeline of behavior, I need to tell NServiceBus when to invoke my behavior. I do so by first creating a class that represents the information on how to register this step:

    public class Registration : RegisterStep
        public Registration()
            : base(
                "RoutingSlipBehavior", typeof (RouteSupervisor),
                "Unpacks routing slip and forwards message to next destination")

    I tell NServiceBus to insert this step before a well-known step, of loading handlers. I (actually Andreas) picked this point in the pipeline because in doing so, I can modify the services injected into my step. This last piece is configuring and turning on my behavior:

    public static BusConfiguration RoutingSlips(this BusConfiguration configure)
        configure.RegisterComponents(cfg =>
            cfg.ConfigureComponent(b => 
        return configure;

    I register the Router component, and next the current routing slip. The routing slip instance is pulled from the current context’s routing slip – what I inserted into the context in the previous step.

    Finally, I register the route supervisor into the pipeline. With the current routing slip registered as a component, I can allow handlers to access the routing slip and add attachment for subsequent steps:

    public RoutingSlip RoutingSlip { get; set; }
    public void Handle(SequentialProcess message)
        // Do other work
        RoutingSlip.Attachments["Foo"] = "Bar";

    With the new pipeline behaviors in place, I was able to remove quite a few hacks to get routing slips to work. Building and registering this new behavior was simple and straightforward, a testament to the design benefits of a behavior pipeline.

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    Categories: Blogs