Skip to content


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

Teams 102

Leading Agile - Mike Cottmeyer - Thu, 10/02/2014 - 13:00

Much of my personal journey over the past 8 years has involved unpacking some of the more dense concepts we tend to take for granted when we talk about agile. For me, it’s all about understanding the primitives of these approaches and trying to figure out how to apply them in unique ways. I’m deeply interested in not only how this stuff works, but why it works… and more importantly, why it fails when it fails. 

The time I spent with VersionOne was very formative for me. My gig with V1 was a blend of training, coaching, and helping our customers understand and implement the product. When you are trying to implement software designed to support a very specific process, and the company adopting the process isn’t really built to accommodate it, things can get goofy really fast. For any of you guys that have configured V1, Rally, Jira, TFS, or AgileCraft… you know what I mean. 

I didn’t have this language back when I was with V1, but over the last few years I’ve come to believe that most organizations struggle to adopt agile because agile is incongruent with how they’ve built their companies and what their companies value. It usually centers around how they have chosen to form teams, how they govern their work, and how they measure the performance of their organization. To me… and now to LeadingAgile… those are the things that we need to fix first. Solving this is why I left V1 and started my own company. 

A Brief Perspective on the History of Agile

I’ll admit I’m no historian of agile, and while I’ve gotten to know a few of the original manifesto signers, much of what I’m getting ready to say here are just my impressions based on the things I’ve read and heard over the past few years as a student of this approach. 

I think that many folks new to agile think of agile as a thing… they might even equate agile with Scrum and might not even know there are other approaches out there in practice that are considered agile. I like to talk about agile as a family of approaches that have their roots in the earliest days of software engineering back in the 60’s and 70’s and some of the lean stuff in the 80’s. 

When the Manifesto signatories got together in 2001, they weren’t inventing agile. They were already doing agile, they were just doing agile in many different ways. The Snowbird event wasn’t about invention, it was about discovery. It was about exploring what the various approaches had in common. I think it also might of had something to do with drinking and snow skiing, but I digress. 

The result was in effect a position statement of sorts… The Agile Manifesto. If you’re on this blog, I imagine you’ve been exposed to that document, and I’ll save you the agony of going over it in any detail here. What’s important to this conversation though, is that the Manifesto isn’t a process, it’s a set of values and principles. It guides us on how to think and behave, but doesn’t really tell us what to go do. 

The Manifesto and Teams

The Manifesto says a little about teams. What it does say specifically is that we should support them and trust them and allow them to self-organize. It doesn’t say much about who should be on a team, or how to form a team, or what to do when forming teams is hard. I think the Manifesto assumes teams of a specific sort. When we look the other principles and see that we are supposed to deliver often, get feedback, etc. we start to gather some clues about what it would take to form a team capable of providing that kind of value. 

I don’t think that anyone would disagree that when the Manifesto was written, folks weren’t really trying to apply these principles at scale. They weren’t trying to apply these concepts in the large, super complicated companies that are trying to apply agile today. They were dealing with groups of 5-10 developers, all working in the same office, all with access to decision makers. They were dealing with simpler technology stacks that they fully controlled. When the Manifesto was written, this was they environment they assumed to be in place. 

Culture, Practices, and Teams

This discussion of the Manifesto is important to me because it has clearly shaped much of the conversation around how to adopt agile, and 13 years later, how we should best adopt agile at scale in large enterprises.

Because the Manifesto is a set of values and principles… and doesn’t give much guidance around how to form teams or any guidance around specific practices… agile transformation is quite often approached as a culture change. The idea being that we have to get people to change how they think and how they behave in order to do agile. 

Likewise, because the values and principles outlined in the Manifesto were derived from methodology and practice, many transformations focus on changing the stuff that people do. Be it technical practices or management practices… we recognize that people need to learn new tools and techniques that are necessary to operate in this new way. 

While I believe culture shift in many organizations is a necessary precondition to making change stick, and I think it’s fairly inarguable that solid blocking and tackling around the core agile practices is essential to be a high performing agile team… I’ve come to believe that individually, and even together, culture change and practices are not enough to have an effective agile ecosystem. 

I think it’s what’s implicit in the Manifesto that is actually most important. I think it’s the ability to have complete cross-functional teams that gives us the foundation for a healthy, adaptive, trust-based culture to emerge and for agile practices to become contextually relevant. Cultural messaging and practices outside of a complete cross-functional team just doesn’t make any sense to me. 

Regardless if it makes sense, I don’t fundamentally see this approach work in practice. While culture and practices are essential, they are not sufficient to effect sustainable, large scale transformation in most organizations. We need to have a pattern for forming teams across the organization, guidance for how to intake and coordinate work across teams, and ways to track delivery and communicate progress. Structure, governance, and metrics.

My General Bent

My general bent is that the best way to effect sustainable change, and establish  lasting agile transformations, is to first form teams. After the teams have been formed, you get them executing with precision by teaching the practices that make agile teams really work. Why teams and practices first? Well, by forming teams and teaching practices first, you create safety for the people to change what they believe. 

My take is that it’s hard to get people to change what they think, feel, and believe… especially if they are invested personally in the old way of working. It’s extra hard if people have been punished for coloring outside the lines. If a company wants to go agile, is willing to form teams, create the environment where the practices can generate great results… I believe you will create an ecosystem where a healthy culture can emerge.

Results build trust with the organization and provide safety for the managers which in turn creates safety for the teams. Safety is what allows culture shift to happen. While culture shift is wildly important, it’s not the place you want to start in your agile transformation. 


In this post, I wanted to go just a little deeper on the notion of teams and challenge some of the common thinking around agile and agile transformation.

Don’t get me wrong… there is hard work ahead of us. We haven’t addressed ANY of the barriers yet that make forming teams difficult or what you’d even form a team around if we had permission to go do it.

LeadingAgile starting to discover some really effective patterns, thinking tools, and specific methods for giving guidance on forming teams in large, complex organizations. Furthermore, we are seeing these patterns drive significant gains within the organizations we’re working with. That’s pretty exciting. 

That said, if I don’t get you convinced the forming teams is first problem to solve, maybe even the most important problem to solve, the rest won’t really matter much ;-)

Until next time. 

The post Teams 102 appeared first on LeadingAgile.

Categories: Blogs

Starting Swarming

Agile Tools - Thu, 10/02/2014 - 07:47


“prattle without practice”
― William Shakespeare, Othello

Enough prattle! All this theory is great, but how do we actually set the conditions for swarming to occur? How can we make it work?

Initiating the Swarm

The problem with a good swarming team is that you can’t control team membership. Swarming requires a dynamic and egalitarian approach where everyone can decide what they want to do with whomever they please. Management has no role in this at all (other than perhaps creating the space). I suppose you could try and provide a few seed ideas to attract people, but you go into it with no assurance that those ideas will be what the groups coalesce around.

There should be some orientation to the values and principles to start with. We need to find a group that is interested in using the process and understands from the start that there are no explicitly defined leaders or followers. Anyone can come up with an idea, and if the idea is a good one, perhaps others will join you.

So the key ingredients to start swarming:

  • People who have been introduced to and understand the swarming values and principles
  • Some ideas
  • A place for the swarming to take place – preferably a place dedicated to swarming
  • Passion

One more note on the people: radical diversity is required. It’s not sufficient to just toss a bunch of developers and QA into a room and tell them to swarm. It must be open to everyone. ABSOLUTELY everyone. That’s right, toss that cute receptionist from the front desk in there too. Customer Service, the guy from the help desk, and the janitor. Throw them all in. And a customer or two – don’t forget them. Oh, and for God’s sake, whatever you do, don’t toss an agile coach in there, they’ll tell everyone how to do it and just screw everything up.

That should get them started. It could be structured like the marketplace in open space. Everyone with an idea goes to the center of the room and writes their idea on a sheet of paper. They stand up and announce the idea, then go to some agreed upon area and wait to see who shows up. Simple. Then let people go wherever their interest takes them. They can be butterflies, bumble bees, whatever makes them happy. If you come up with a new idea (and hopefully people will) then you just write it down and announce it to the group. If there are no takers, no problem: you can decide to continue on your own and develop the idea to the point where it attracts more interest or you can dump it and look at someone else’s idea.

That’s really all there is to it. From here on out you just stand back and let it go. The teams that form will decide how to work together. If someone doesn’t like it, they can move on, make their own team or join another one. No managers. No scrum masters. Just:

Water frequently…

Place in direct sunlight…

And let it grow…

Filed under: Agile, Coaching, Swarming, Teams Tagged: initiation, self-organization, starting, Swarming, team building, team creation
Categories: Blogs

Das mittlere Management ist tot, es lebe das mittlere Management!

Scrum 4 You - Thu, 10/02/2014 - 07:35

Was ist das eigentlich, das mittlere Management? Ich denke, es ist dabei zu verschwinden – zumindest in der Form, wie wir es kennen. Wieso ich das denke? Das gilt es zu zeigen, hier also mein „Beweis“.

Anzug vs. Jeans

Viele mittlere Manager glauben, sie würden dazu dienen, die Kollegen auszusteuern, Anweisungen zu erteilen und dafür zu sorgen, dass die Produktivität in einem Unternehmen erhalten bleibt. Wenn man ihnen aber so zuschaut, stellt man fest, dass das mittlere Management oft 90 Prozent seiner Zeit mit sich selbst beschäftigt ist. Manager reden mit Managern. Als ich diese Beobachtung auf einer Konferenz in einer der Kaffeepausen darlegte, sagte eine Tischnachbarin: „Ja, das Management bildet ein geschlossenes System. Es gibt Management-Veranstaltungen, auf denen Manager sich zu Clubs formieren. Sie gehen zu anderen Veranstaltungen als zum Beispiel die Techniker im Unternehmen.“ Ich stutzte: War da was Wahres dran? Die auffälligste Beobachtung habe ich vor ein paar Jahren bei einem Kunden  gemacht: Dort liefen die Manager ausschließlich in Anzug und weißem Hemd herum, während alle Ingenieure und Software-Entwickler in Jeans und kariertem Hemd unterwegs waren. In der Kantine konnte man die Lager besonders gut erkennen.

Nun darf man aus einer Beobachtung nicht auf die Allgemeinheit schließen, aber die Formulierung der Kollegin machte mich hellhörig. Seitdem beobachte ich in den Unternehmen – nebenbei – wie viel Interaktion, also echtes Zusammenarbeiten, zwischen den mittleren Managern und den Nicht-Managern herrscht. Das ist wirklich faszinierend: Es gibt so gut wie keine. Ein Statusmeeting von 1 bis 2 Stunden pro 60-Stunden-Woche – das sind 2 bis 5 Prozent der Zeit, die das Management mit den Kollegen, die sie führen sollen, aufbringt. Rechnen wir noch die Zeit für das Schreiben von E-Mails hinzu, kommt man vielleicht auf 20 Prozent der Wochenarbeitszeit, also 8 bis 12 Stunden, in denen das mittlere Management mit den Kollegen redet. Doch das bedeutet doch, dass die Kollegin Recht hatte: Das Management baut ein geschlossenes System, das die Realität nur noch aus Erzählungen Chats, Power Point und Reporting-Meetings kennt. Eine Kaste, die gar nicht mehr dazu dient, die Kollegen auszusteuern und ihnen dabei zu helfen, ihre Arbeit zu machen. Das kann am Ende aber nur dazu führen, dass das Management selbst eine aussterbende Spezies ist. Internet, Netzwerke, Plattformen, Tools wie JIRA und Co, die eingeführt werden, um die Sichtbarkeit für das Management zu erhöhen, machen es ja nun möglich, dass das Top Management tagesaktuell sieht, was die Teams liefern. Also braucht es ja kein mittleres Management mehr, dessen Aufgabe darin besteht, für Berichte und Informationsweitergabe zu sorgen. Das mittlere Management ist tot. Q.e.d!

Der neue mittlere Manager: der ScrumMaster

Das mittlere Management wird in dieser Form einfach nicht gebraucht. Das machen Firmen wie Facebook und Co vor. (1) Dort wird man nicht deshalb Manager, weil das die nächste logische Entwicklung zu mehr Macht und Geld ist, sondern weil es tatsächlich einige Funktionen gibt, die es durch dafür geeignete Menschen zu füllen gilt. Diese sorgen dort für Zusammenarbeit. Das funktioniert aber nur, wenn das mittlere Management seine originäre Aufgabe – für die Zusammenarbeit von Teams zu sorgen – wieder erfüllt. Wie das geht?

Toyota führte vor Jahrzehnten das Prinzip des Genchi Genbutsu ein: „Go and See“ – das Management soll dorthin gehen und dort mit seiner Aufmerksamkeit anwesend sein, wo die Arbeit stattfindet. Das bedeutet in den heute wichtiger werdenden wissensverarbeitenden, kreativen Berufen, dass das Management im selben Raum wie Grafiker, Software-Entwickler, Ingenieure, Wissenschaftler sitzen und arbeiten sollte. Also wirklich dort vor Ort sein. Seien wir großzügig: Zu Beginn sollten es wenigstens 50 Prozent der Zeit sein. Sie müssten schauen, was dort geschieht, verstehen ohne zu stören und herausfinden, wie sie dafür sorgen können, dass ihre Kollegen schneller – d.h. produktiver – arbeiten können. Wäre es das, was das Management täte, dann könnte man sich Reporting, Listen und Charts schenken. Sehr viel Zeit würde dadurch gespart und auf diese Weise könnte wieder produktiv an der Sache gearbeitet werden. Trotzdem gäbe es kein Informationsdefizit, denn die Manager wüssten ja aus erster Hand, was geschieht.

Dem geneigten Leser fällt jetzt sicher auf: Das ist die Stellenbeschreibung eines ScrumMasters. Ja, der ScrumMaster ist ein mittlerer Manager. Er sorgt dafür, dass Teams perfekt zusammenarbeiten, löst Probleme und gewährleistet, dass Scrum-Teams liefern. Aus einem ScrumMaster wird schnell wieder ein mittlerer Manager alten Zuschnitts, wenn man ihm Macht über die Teams gibt. Daher gilt die klare Regel: Der ScrumMaster ist nicht personell für die Kollegen verantwortlich. Er bleibt eine laterale Führungskraft, der für sein Team da ist und den Raum aufspannt, in dem gearbeitet werden kann. Es lebe das mittlere Management.


Related posts:

  1. Management in Scrum Organisationen
  2. Scrum Rollen | Der Manager
  3. Servant Leadership

Categories: Blogs

Teams 101

Leading Agile - Mike Cottmeyer - Wed, 10/01/2014 - 18:11

The notion of forming complete cross functional teams is one of the most well understood concepts in the agile community but maybe one of the least implemented in practice. Many folks adopting agile either don’t understand the importance of teams, or if they do… they don’t have the power to influence the organization to build them. Often, there just aren’t enough people with the right kinds of skills and experience to get every team everything they need… so they compromise.

What happens when we compromise this foundational principle of agile?

Assuming for a moment we actually have the ability to create a well-formed backlog… and theoretically the ability to produce a working, tested increment of the product at the end of the iteration… an incomplete team won’t be able to establish velocity, won’t able to communicate progress, won’t be able to validate the product as they go or get any meaningful feedback. Furthermore, they’ll create an indeterminate backlog of unfinished work as they go.

This is a huge problem for organizations, especially those in the early stages of adopting agile.

Why? Well think about what we are asking folks to do. We are asking them to buy into a system of delivery that is not based on heavy up-front planning and one that doesn’t make commitments to delivering a specific scope within a specific time and cost constraint. We are asking people to let us change direction when we learn new information without requiring change control. This is scary for most folks, and viewed as fundamentally irresponsible to others.

The tradeoff we are selling is that our stakeholders will have continuous input into the process, total transparency into the evolving product, the ability to unambiguously validate progress, and the opportunity to put product into market early and potentially realize an earlier return on investment. The deal is this… if you trust me to work in an agile way, I can create better economic outcomes for you in return. That is the agile value prop for our customers.

Now… think about all the things we break in this deal when we don’t form complete cross-functional teams. We cannot be stable. We cannot be predictable. We cannot produce a working tested increment of the product at the end of the sprint. We cannot get meaningful feedback on the emerging product. We cannot release early. We cannot fundamentally honor the contract we have entered into with our customers. We are frozen.

One of the most subversive things about incomplete teams is that they stop believing they can plan an iteration and deliver value for their customers. They stop believing that they can make and meet a commitment. They stop believing that they can do what they say they are going to do. They stop taking responsibility and can’t be held accountable. They go through the motions of doing agile but can’t produce any of the business benefits that come from it.

Here is my take…

There are lot’s of ways to be successful. I’ve run great waterfall projects. I’ve run projects with fundamentally no process at all. With the right people and the right focus you can make just about anything work. That said, if you want to make agile work, you have to form teams. If you are not going to form teams, don’t do agile. The worst thing you can do is adopt a process based around teams without creating the very construct that allows the process to work.

Up next…

1. Teams 102… A quick history of agile and how our beliefs about adoption and transformation might be impacting our ability to form teams

2. Teams 201… a more advanced treatment of what it means to form an agile team, what to do with specialists, and where to put folks that don’t go on agile teams.

3. Teams 301… patterns for forming teams in larger, more complex organizations with legacy platforms, shared services, and shared components


The post Teams 101 appeared first on LeadingAgile.

Categories: Blogs

Neues Buch: Selbstorganisation braucht Führung

Scrum 4 You - Wed, 10/01/2014 - 07:30

Dolores, meine Editorin, sagt: „Es ist das beste Buch, dass du bisher geschrieben hast, weil es dein persönlichstes ist.“ Und obwohl Eigenlob stinkt: Sie hat recht. “Selbstorganisation braucht Führung. Die einfachen Geheimnisse agilen Managements” enthält im Grunde die Erfahrungen, die ich als Führungskraft eines Consultingunternehmens sowohl mit den eigenen Kollegen als auch bei Kunden und mit Kundenteams, mit den Managern und den Mitarbeitern dort gemacht habe. Mir ist klar, dass es eine Gratwanderung ist, wenn man nicht nur seine Erfolge, sondern auch sein Scheitern beschreibt. Aber ich sage ja auch unseren Kunden nicht, dass es ein Spaziergang wird, wenn sie ein agiles Unternehmen aufbauen wollen.

Abgesehen von meinen eigenen Erfahrungen behandelt das Buch aber vor allem die Frage: Wie kann der Manager von heute Menschen in die Selbstorganisation führen? Mir selbst ist dabei klar geworden: Selbstorganisation ist kein Selbstzweck, sondern sie schafft die Grundlagen für extreme Produktivitätssteigerungen bei allen Arten von Teams. Wichtig war und ist mir, Führung so zu definieren und zu gestalten, dass sie tatsächlich lebbar wird. Ich wollte keine agile Führungstheorie entwerfen, die im Abstrakten bleibt. Was ihr in diesem Buch nachlesen könnt, sind Praktiken, die Dieter Rösner und ich selbst erst auf die manchmal harte Tour in unseren Führungsrollen erlernen mussten und wir geben uns nicht der Illusion hin, dass wir bereits ausgelernt haben. “Einfach” sind die Geheimnisse des agilen Managements aus unserer Sicht deshalb, weil Führung in ihrer besten Form unserer Meinung nach auf keinen illustren Theorien beruht, sondern ganz einfach auf Grundregeln des menschlichen Zusammenlebens. Zuhören, mein Gegenüber wahrnehmen, es als ebenbürtig anzuerkennen und wertzuschätzen, ein simples “gut gemacht” aussprechen – in vielen Situationen braucht es gar nicht viel mehr, um Menschen zu motivieren. Und trotzdem passiert es so oft nicht.

Mein Dank geht an Dieter Rösner, der sein großes Wissen zum Thema Systemische Führung und seine große Erfahrung in das Buch eingebracht hat. Und natürlich danke ich meinem ganzen Team von Boris Gloger Consulting und all den vielen Menschen, ohne die das Buch nicht hätte entstehen können.

Ob es gelungen ist, müsst ihr beantworten – die ersten Stimmen zum Buch waren schon sehr positiv. Ich freue mich auf euer Feedback!

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

Cover Selbstorganisation braucht Führung

Related posts:

  1. Mehr wissen! Moderationstraining
  2. Freelancer
  3. Vom Glauben und sich Einlassen

Categories: Blogs

This is the Way Scrum Ends

Agile Tools - Wed, 10/01/2014 - 06:38

Processed with VSCOcam with x1 preset

This is the way the world ends This is the way the world ends This is the way the world ends Not with a bang but a whimper.

- T.S. Eliot

Did you ever wonder if this is the future of Scrum? Will it eventually go out with a whimper? I think a lot of people fear this fate for everyone’s favorite framework. Go to a conference or follow your favorite luminary on Twitter and you hear a chorus of “That’s Scrumbut!”, “It’s FrAgile”, or “Welcome to Scrummerfall!” And maybe that’s the way it has to be. Perhaps all great new ideas eventually become diluted in a sea of mediocrity.

I think I hear a longing in some to fight such dissolution. To resist the forces of corporate entropy. Rather than try to fit in, they urge us to confront and overturn the system. You know, subvert the dominant paradigm? Confronting this dissonance is the difference between making a living and actually living.

I wonder if that’s the difference between those who “fire” their customers and those who stay and work within the system. Are those consultants who give up and declare, “These clowns aren’t ready for Scrum.” going out with a bang? And what about those who stay? Are they afraid to make the big moves and just content to fit in? Whimper. Or are they more subtle than that? Can you embrace your client and still change them? Perhaps the “bang” approach is quicker, and more decisive. And maybe, just maybe, remaining engaged is very, very hard, but yields results in the end.

I know, I know…why so bleak? Well, I feel this tension a lot in our weird little community. I’ve been on both sides of the engagements where a respected consultant has tossed their hands in the air and walked away from the engagement because “They just don’t get it.” or “They’re not ready yet.” And I’ve been that poor fool, laboring away within the system, living on a meager diet of optimism and the occasional conference, trying to make change happen. I won’t pretend to know which approach is right, or even when to use these strategies, but I think it would be worthwhile to understand this issue better.

Filed under: Agile, Scrum Tagged: Agile, change, change management, consultant, decline, fragile, framework, mediocrity, Scrum, Scrumbut, Waterfall
Categories: Blogs

The Dangers of Visual Project Management

Leading Answers - Mike Griffiths - Wed, 10/01/2014 - 02:58
(Or how a picture can divert 1,000 eyes) This post was first written for who were doing a series on Visual Project Management at the time. I was excited when I heard about the theme since I am a... Mike Griffiths
Categories: Blogs

R: A first attempt at linear regression

Mark Needham - Wed, 10/01/2014 - 00:20

I’ve been working through the videos that accompany the Introduction to Statistical Learning with Applications in R book and thought it’d be interesting to try out the linear regression algorithm against my meetup data set.

I wanted to see how well a linear regression algorithm could predict how many people were likely to RSVP to a particular event. I started with the following code to build a data frame containing some potential predictors:

officeEventsQuery = "MATCH (g:Group {name: \"Neo4j - London User Group\"})-[:HOSTED_EVENT]->(event)<-[:TO]-({response: 'yes'})<-[:RSVPD]-(),
                     WHERE (event.time + event.utc_offset) < timestamp() AND IN [\"Neo Technology\", \"OpenCredo\"]
                     RETURN event.time + event.utc_offset AS eventTime,event.announced_at AS announcedAt,, COUNT(*) AS rsvps"
events = subset(cypher(graph, officeEventsQuery), !
events$eventTime <- timestampToDate(events$eventTime)
events$day <- format(events$eventTime, "%A")
events$monthYear <- format(events$eventTime, "%m-%Y")
events$month <- format(events$eventTime, "%m")
events$year <- format(events$eventTime, "%Y")
events$announcedAt<- timestampToDate(events$announcedAt)
events$timeDiff = as.numeric(events$eventTime - events$announcedAt, units = "days")

If we preview ‘events’ it contains the following columns:

> head(events)
            eventTime         announcedAt                               rsvps       day monthYear month year  timeDiff
1 2013-01-29 18:00:00 2012-11-30 11:30:57                                   Intro to Graphs    24   Tuesday   01-2013    01 2013 60.270174
2 2014-06-24 18:30:00 2014-06-18 19:11:19                                   Intro to Graphs    43   Tuesday   06-2014    06 2014  5.971308
3 2014-06-18 18:30:00 2014-06-08 07:03:13                         Neo4j World Cup Hackathon    24 Wednesday   06-2014    06 2014 10.476933
4 2014-05-20 18:30:00 2014-05-14 18:56:06                                   Intro to Graphs    53   Tuesday   05-2014    05 2014  5.981875
5 2014-02-11 18:00:00 2014-02-05 19:11:03                                   Intro to Graphs    35   Tuesday   02-2014    02 2014  5.950660
6 2014-09-04 18:30:00 2014-08-26 06:34:01 Hands On Intro to Cypher - Neo4j's Query Language    20  Thursday   09-2014    09 2014  9.497211

We want to predict ‘rsvps’ from the other columns so I started off by creating a linear model which took all the other columns into account:

> summary(lm(rsvps ~., data = events))
lm(formula = rsvps ~ ., data = events)
    Min      1Q  Median      3Q     Max 
-8.2582 -1.1538  0.0000  0.4158 10.5803 
Coefficients: (14 not defined because of singularities)
                                                                    Estimate Std. Error t value Pr(>|t|)   
(Intercept)                                                       -9.365e+03  3.009e+03  -3.113  0.00897 **
eventTime                                                          3.609e-06  2.951e-06   1.223  0.24479   
announcedAt                                                        3.278e-06  2.553e-06   1.284  0.22339   
event.nameGraph Modelling - Do's and Don'ts                        4.884e+01  1.140e+01   4.286  0.00106 **
event.nameHands on build your first Neo4j app for Java developers  3.735e+01  1.048e+01   3.562  0.00391 **
event.nameHands On Intro to Cypher - Neo4j's Query Language        2.560e+01  9.713e+00   2.635  0.02177 * 
event.nameIntro to Graphs                                          2.238e+01  8.726e+00   2.564  0.02480 * 
event.nameIntroduction to Graph Database Modeling                 -1.304e+02  4.835e+01  -2.696  0.01946 * 
event.nameLunch with Neo4j's CEO, Emil Eifrem                      3.920e+01  1.113e+01   3.523  0.00420 **
event.nameNeo4j Clojure Hackathon                                 -3.063e+00  1.195e+01  -0.256  0.80203   
event.nameNeo4j Python Hackathon with py2neo's Nigel Small         2.128e+01  1.070e+01   1.989  0.06998 . 
event.nameNeo4j World Cup Hackathon                                5.004e+00  9.622e+00   0.520  0.61251   
dayTuesday                                                         2.068e+01  5.626e+00   3.676  0.00317 **
dayWednesday                                                       2.300e+01  5.522e+00   4.165  0.00131 **
monthYear01-2014                                                  -2.350e+02  7.377e+01  -3.185  0.00784 **
monthYear02-2013                                                  -2.526e+01  1.376e+01  -1.836  0.09130 . 
monthYear02-2014                                                  -2.325e+02  7.763e+01  -2.995  0.01118 * 
monthYear03-2013                                                  -4.605e+01  1.683e+01  -2.736  0.01805 * 
monthYear03-2014                                                  -2.371e+02  8.324e+01  -2.848  0.01468 * 
monthYear04-2013                                                  -6.570e+01  2.309e+01  -2.845  0.01477 * 
monthYear04-2014                                                  -2.535e+02  8.746e+01  -2.899  0.01336 * 
monthYear05-2013                                                  -8.672e+01  2.845e+01  -3.049  0.01011 * 
monthYear05-2014                                                  -2.802e+02  9.420e+01  -2.975  0.01160 * 
monthYear06-2013                                                  -1.022e+02  3.283e+01  -3.113  0.00897 **
monthYear06-2014                                                  -2.996e+02  1.003e+02  -2.988  0.01132 * 
monthYear07-2014                                                  -3.123e+02  1.054e+02  -2.965  0.01182 * 
monthYear08-2013                                                  -1.326e+02  4.323e+01  -3.067  0.00976 **
monthYear08-2014                                                  -3.060e+02  1.107e+02  -2.763  0.01718 * 
monthYear09-2013                                                          NA         NA      NA       NA   
monthYear09-2014                                                  -3.465e+02  1.164e+02  -2.976  0.01158 * 
monthYear10-2012                                                   2.602e+01  1.959e+01   1.328  0.20886   
monthYear10-2013                                                  -1.728e+02  5.678e+01  -3.044  0.01020 * 
monthYear11-2012                                                   2.717e+01  1.509e+01   1.800  0.09704 . 
month02                                                                   NA         NA      NA       NA   
month03                                                                   NA         NA      NA       NA   
month04                                                                   NA         NA      NA       NA   
month05                                                                   NA         NA      NA       NA   
month06                                                                   NA         NA      NA       NA   
month07                                                                   NA         NA      NA       NA   
month08                                                                   NA         NA      NA       NA   
month09                                                                   NA         NA      NA       NA   
month10                                                                   NA         NA      NA       NA   
month11                                                                   NA         NA      NA       NA   
year2013                                                                  NA         NA      NA       NA   
year2014                                                                  NA         NA      NA       NA   
timeDiff                                                                  NA         NA      NA       NA   
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
Residual standard error: 5.287 on 12 degrees of freedom
Multiple R-squared:  0.9585,	Adjusted R-squared:  0.8512 
F-statistic: 8.934 on 31 and 12 DF,  p-value: 0.0001399

As I understand it we can look at the R-squared value to understand how much of the variance in the data has been explained by the model – in this case it’s 85%.

A lot of the coefficients seem to be based around specific event names which seems a bit too specific to me so I wanted to see what would happen if I derived a feature which indicated whether a session was practical:

events$practical = grepl("Hackathon|Hands on|Hands On", events$

We can now run the model again with the new column having excluded ‘’ field:

> summary(lm(rsvps ~., data = subset(events, select = -c(
lm(formula = rsvps ~ ., data = subset(events, select = -c(
    Min      1Q  Median      3Q     Max 
-18.647  -2.311   0.000   2.908  23.218 
Coefficients: (13 not defined because of singularities)
                   Estimate Std. Error t value Pr(>|t|)  
(Intercept)      -3.980e+03  4.752e+03  -0.838   0.4127  
eventTime         2.907e-06  3.873e-06   0.751   0.4621  
announcedAt       3.336e-08  3.559e-06   0.009   0.9926  
dayTuesday        7.547e+00  6.080e+00   1.241   0.2296  
dayWednesday      2.442e+00  7.046e+00   0.347   0.7327  
monthYear01-2014 -9.562e+01  1.187e+02  -0.806   0.4303  
monthYear02-2013 -4.230e+00  2.289e+01  -0.185   0.8553  
monthYear02-2014 -9.156e+01  1.254e+02  -0.730   0.4742  
monthYear03-2013 -1.633e+01  2.808e+01  -0.582   0.5676  
monthYear03-2014 -8.094e+01  1.329e+02  -0.609   0.5496  
monthYear04-2013 -2.249e+01  3.785e+01  -0.594   0.5595  
monthYear04-2014 -9.230e+01  1.401e+02  -0.659   0.5180  
monthYear05-2013 -3.237e+01  4.654e+01  -0.696   0.4952  
monthYear05-2014 -1.015e+02  1.509e+02  -0.673   0.5092  
monthYear06-2013 -3.947e+01  5.355e+01  -0.737   0.4701  
monthYear06-2014 -1.081e+02  1.604e+02  -0.674   0.5084  
monthYear07-2014 -1.110e+02  1.678e+02  -0.661   0.5163  
monthYear08-2013 -5.144e+01  6.988e+01  -0.736   0.4706  
monthYear08-2014 -1.023e+02  1.784e+02  -0.573   0.5731  
monthYear09-2013 -6.057e+01  7.893e+01  -0.767   0.4523  
monthYear09-2014 -1.260e+02  1.874e+02  -0.672   0.5094  
monthYear10-2012  9.557e+00  2.873e+01   0.333   0.7430  
monthYear10-2013 -6.450e+01  9.169e+01  -0.703   0.4903  
monthYear11-2012  1.689e+01  2.316e+01   0.729   0.4748  
month02                  NA         NA      NA       NA  
month03                  NA         NA      NA       NA  
month04                  NA         NA      NA       NA  
month05                  NA         NA      NA       NA  
month06                  NA         NA      NA       NA  
month07                  NA         NA      NA       NA  
month08                  NA         NA      NA       NA  
month09                  NA         NA      NA       NA  
month10                  NA         NA      NA       NA  
month11                  NA         NA      NA       NA  
year2013                 NA         NA      NA       NA  
year2014                 NA         NA      NA       NA  
timeDiff                 NA         NA      NA       NA  
practicalTRUE    -9.388e+00  5.289e+00  -1.775   0.0919 .
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
Residual standard error: 10.21 on 19 degrees of freedom
Multiple R-squared:  0.7546,	Adjusted R-squared:  0.4446 
F-statistic: 2.434 on 24 and 19 DF,  p-value: 0.02592

Now we’re only accounting for 44% of the variance and none of our coefficients are significant so this wasn’t such a good change.

I also noticed that we’ve got a bit of overlap in the date related features – we’ve got one column for monthYear and then separate ones for month and year. Let’s strip out the combined one:

> summary(lm(rsvps ~., data = subset(events, select = -c(, monthYear))))
lm(formula = rsvps ~ ., data = subset(events, select = -c(, 
     Min       1Q   Median       3Q      Max 
-16.5745  -4.0507  -0.1042   3.6586  24.4715 
Coefficients: (1 not defined because of singularities)
                Estimate Std. Error t value Pr(>|t|)  
(Intercept)   -1.573e+03  4.315e+03  -0.364   0.7185  
eventTime      3.320e-06  3.434e-06   0.967   0.3425  
announcedAt   -2.149e-06  2.201e-06  -0.976   0.3379  
dayTuesday     4.713e+00  5.871e+00   0.803   0.4294  
dayWednesday  -2.253e-01  6.685e+00  -0.034   0.9734  
month02        3.164e+00  1.285e+01   0.246   0.8075  
month03        1.127e+01  1.858e+01   0.607   0.5494  
month04        4.148e+00  2.581e+01   0.161   0.8736  
month05        1.979e+00  3.425e+01   0.058   0.9544  
month06       -1.220e-01  4.271e+01  -0.003   0.9977  
month07        1.671e+00  4.955e+01   0.034   0.9734  
month08        8.849e+00  5.940e+01   0.149   0.8827  
month09       -5.496e+00  6.782e+01  -0.081   0.9360  
month10       -5.066e+00  7.893e+01  -0.064   0.9493  
month11        4.255e+00  8.697e+01   0.049   0.9614  
year2013      -1.799e+01  1.032e+02  -0.174   0.8629  
year2014      -3.281e+01  2.045e+02  -0.160   0.8738  
timeDiff              NA         NA      NA       NA  
practicalTRUE -9.816e+00  5.084e+00  -1.931   0.0645 .
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1
Residual standard error: 10.19 on 26 degrees of freedom
Multiple R-squared:  0.666,	Adjusted R-squared:  0.4476 
F-statistic: 3.049 on 17 and 26 DF,  p-value: 0.005187

Again none of the coefficients are statistically significant which is disappointing. I think the main problem may be that I have very few data points (only 42) making it difficult to come up with a general model.

I think my next step is to look for some other features that could impact the number of RSVPs e.g. other events on that day, the weather.

I’m a novice at this but trying to learn more so if you have any ideas of what I should do next please let me know.

Categories: Blogs

Neo4j: Generic/Vague relationship names

Mark Needham - Tue, 09/30/2014 - 18:47

An approach to modelling that I often see while working with Neo4j users is creating very generic relationships (e.g. HAS, CONTAINS, IS) and filtering on a relationship property or on a property/label at the end node.

Intuitively this doesn’t seem to make best use of the graph model as it means that you have to evaluate many relationships and nodes that you’re not interested in.

However, I’ve never actually tested the performance differences between the approaches so I thought I’d try it out.

I created 4 different databases which had one node with 60,000 outgoing relationships – 10,000 which we wanted to retrieve and 50,000 that were irrelevant.

I modelled the ‘relationship’ in 4 different ways…

  • Using a specific relationship type
  • Using a generic relationship type and then filtering by end node label
  • Using a generic relationship type and then filtering by relationship property
    (node)-[:HAS {type: "address"}]->(address)
  • Using a generic relationship type and then filtering by end node property
    (node)-[:HAS]->(address {type: “address”})

…and then measured how long it took to retrieve the ‘has address’ relationships.

The code is on github if you want to take a look.

Although it’s obviously not as precise as a JMH micro benchmark I think it’s good enough to get a feel for the difference between the approaches.

I ran a query against each database 100 times and then took the 50th, 75th and 99th percentiles (times are in ms):

Using a generic relationship type and then filtering by end node label
50%ile: 6.0    75%ile: 6.0    99%ile: 402.60999999999825
Using a generic relationship type and then filtering by relationship property
50%ile: 21.0   75%ile: 22.0   99%ile: 504.85999999999785
Using a generic relationship type and then filtering by end node label
50%ile: 4.0    75%ile: 4.0    99%ile: 145.65999999999931
Using a specific relationship type
50%ile: 0.0    75%ile: 1.0    99%ile: 25.749999999999872

We can drill further into why there’s a difference in the times for each of the approaches by profiling the equivalent cypher query. We’ll start with the one which uses a specific relationship name

Using a specific relationship type

neo4j-sh (?)$ profile match (n) where id(n) = 0 match (n)-[:HAS_ADDRESS]->() return count(n);
| count(n) |
| 10000    |
1 row
|             Operator |  Rows | DbHits |                 Identifiers |                 Other |
|         ColumnFilter |     1 |      0 |                             | keep columns count(n) |
|     EagerAggregation |     1 |      0 |                             |                       |
| SimplePatternMatcher | 10000 |  10000 | n,   UNNAMED53,   UNNAMED35 |                       |
|      NodeByIdOrEmpty |     1 |      1 |                        n, n |          {  AUTOINT0} |
Total database accesses: 10001

Here we can see that there were 10,002 database accesses in order to get a count of our 10,000 HAS_ADDRESS relationships. We get a database access each time we load a node, relationship or property.

By contrast the other approaches have to load in a lot more data only to then filter it out:

Using a generic relationship type and then filtering by end node label

neo4j-sh (?)$ profile match (n) where id(n) = 0 match (n)-[:HAS]->(:Address) return count(n);
| count(n) |
| 10000    |
1 row
|             Operator |  Rows | DbHits |                 Identifiers |                            Other |
|         ColumnFilter |     1 |      0 |                             |            keep columns count(n) |
|     EagerAggregation |     1 |      0 |                             |                                  |
|               Filter | 10000 |  10000 |                             | hasLabel(  UNNAMED45:Address(0)) |
| SimplePatternMatcher | 10000 |  60000 | n,   UNNAMED45,   UNNAMED35 |                                  |
|      NodeByIdOrEmpty |     1 |      1 |                        n, n |                     {  AUTOINT0} |
Total database accesses: 70001

Using a generic relationship type and then filtering by relationship property

neo4j-sh (?)$ profile match (n) where id(n) = 0 match (n)-[:HAS {type: "address"}]->() return count(n);
| count(n) |
| 10000    |
1 row
|             Operator |  Rows | DbHits |                 Identifiers |                                            Other |
|         ColumnFilter |     1 |      0 |                             |                            keep columns count(n) |
|     EagerAggregation |     1 |      0 |                             |                                                  |
|               Filter | 10000 |  20000 |                             | Property(  UNNAMED35,type(0)) == {  AUTOSTRING1} |
| SimplePatternMatcher | 10000 | 120000 | n,   UNNAMED63,   UNNAMED35 |                                                  |
|      NodeByIdOrEmpty |     1 |      1 |                        n, n |                                     {  AUTOINT0} |
Total database accesses: 140001

Using a generic relationship type and then filtering by end node property

neo4j-sh (?)$ profile match (n) where id(n) = 0 match (n)-[:HAS]->({type: "address"}) return count(n);
| count(n) |
| 10000    |
1 row
|             Operator |  Rows | DbHits |                 Identifiers |                                            Other |
|         ColumnFilter |     1 |      0 |                             |                            keep columns count(n) |
|     EagerAggregation |     1 |      0 |                             |                                                  |
|               Filter | 10000 |  20000 |                             | Property(  UNNAMED45,type(0)) == {  AUTOSTRING1} |
| SimplePatternMatcher | 10000 | 120000 | n,   UNNAMED45,   UNNAMED35 |                                                  |
|      NodeByIdOrEmpty |     1 |      1 |                        n, n |                                     {  AUTOINT0} |
Total database accesses: 140001

So in summary…specific relationships #ftw!

Categories: Blogs

Going to SAFe Program Consultant Training – London England

Learn more about our Scrum and Agile training sessions on

Travis Birch and I are going next week to the SAFe Program Consultant (SPC) training with Dean Leffingwell.  For Berteig Consulting, this will be an opportunity to expand our knowledge and to, perhaps, offer some new services including training and consulting.  Of course, there have been many articles written about SAFe from a Scrum perspective, but I’m hoping to write an article about it from an enterprise Agility perspective.  I have been involved as a coach and consultant in a number of such transformations, and I’m interested to see what I can learn from SAFe and perhaps how it can help to improve our Real Agility Program.  I currently consider SAFe to be a “pragmatic” approach to enterprise Agility vs. a “transformative” approach.  This perspective is based on some light reading and 3rd party reports about SAFe… clearly not a good enough base of knowledge!  I’m looking forward to bridging that gap!

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

Large Scale Scrum (LeSS)

Agile World - Venkatesh Krishnamurthy - Tue, 09/30/2014 - 13:52

Last week, I had the opportunity to speak about Large Scale Scrum (LeSS) at Agile PM meet up group  in Melbourne.  It was really an honor to speak with such an incredibly experienced, knowledgeable audience. At the end of the session, we had very engaging Q&A.

As part of the session, I shared some of the challenges of  scaling Agile and possible solutions as well. One of the solution being, applying the Large Scale Scrum(LeSS). 

Based on my experience of working on several large scale Agile projects, I have come to realize the following 4 types of challenges common across large enterprises.  They are People, Process, Tools/Technology and Org Structure/Culture. 

I have summarized the challenges into this diagram


Even though these challenges are common in small Agile projects but gets amplified while scaling Agile.

The popular  Scaling Frameworks are as follows:   Spotify,  XScale, SAFe, DAD (Disciplined Agile Delivery).


In addition to the above,  Large Scale Scrum(LeSS) by Craig Larman is popular as well.  I have personally applied this while working with Craig Larman during 2006 at Valtech India. LeSS and LeSS Huge are two variants for large scale projects.  LeSS huge can be depicted as shown in the diagram below:


LeSS is based on some of the proven principles around Queuing Theory,  Systems Thinking  and Empirical Process Control  as shown below.


If you want to learn more about  applying Large Scale Scrum on your projects, do drop me an email and happy to share the ideas.

Categories: Blogs

Swarming Context

Agile Tools - Tue, 09/30/2014 - 07:12

The application of Swarming as a method can be broken down into four main contexts. For each context the process of swarming is different. Allowing for different contexts makes sense, because we really can’t expect the same process to work equally well in every situation. Even the simplest animals are able to exhibit variations in behavior based on the context, so why shouldn’t our processes? We change our behavior to match the circumstances. That is, unless we are using fixed methods like Scrum or Kanban. If you are using fixed methods, the proscription is to treat the process in a fractal fashion, repeating it everywhere. Practically speaking, by having only one process these methods ignore the context.

So what are the four contexts of Swarming? Here they are in no particular order:

  • Emergencies
  • Shifting Gears
  • Innovation
  • Building

Emergencies represent the simplest context for swarming. When a crisis occurs, it’ all hands on deck. Everyone joins the conversation and brings whatever specific expertise they have to the party. The group self-organizes to enable those present to contribute to solving the problem. You see this a lot in production operations environments when a “P1″ defect occurs or, heaven forbid, the production system goes down. When this happens, everyone swarms on the problem. Some are gathering information, some are listening and integrating the information, and some are taking action to try and remedy the situation. All of this is happening dynamically in the moment without central organization. All of these activities are critical to the success of the swarm. During a crisis, nobody is going to stop what they are doing for a standup meeting, and they sure as hell aren’t interested in seeing your Kanban board.

Shifting gears refers to when the system is in transition. The corporate ecosystems that we are all a part of are changing faster with every passing day. New products are coming to market and disrupting the old ones. It’s not enough to simply work within the existing system. You can’t keep up that way. These days corporations have to match their structure to the complexity of the environment. That’s hard, and that’s where swarming comes in. Like when honey bees form a swarm, the corporation reaches a critical mass where a new structure is necessary. Up until this point, the hive has been a stable and reliable structure, but with the presence of a new queen everything changes. A cascade of events takes place where the hive moves on. This can also happen with companies. When they reach a certain size, they can spin off subsidiaries, divisions, and even teams. We see this when teams reach critical mass and split into two teams (meiosis). On swarming teams, we use simple rules to enable groups to decide on their own when division should take place (Team size of 7 plus or minus 2). We use the swarming values and principles to help guide who works on each team – always leaning toward letting individuals decide based on where their own passions take them.

In swarming, Innovation is treated as foraging. We are foraging for new information and new ideas. In this context we are actively using our social networks to recruit new people and new ideas to our cause. This can be initiated as part of a special state (shifting gears) or it can be part of the ongoing activities of the team. When ants are foraging, they tend to follow the strongest pheromone trails to a food source. However this rule is not universal. There are ants who wander off the pheromone trail from time to time. These solitary explorers are the ones who have the unique opportunity to wander off the beaten path and potentially find rich new sources of food. So too, we want people on our team not to follow the team too closely. It’s best if they can wander off and explore side avenues and blind alleys. This isn’t something that is dictated, it’s a natural part of teams with rich diversity. People make these decisions on their own and either bring them back to the original team or they form a new team.

Building takes place when we are trying to strengthen our networks. As a team is growing it uses it’s social networks to strengthen bonds both within and without the team. This can be as simple as increasing the number of social “touches” on a team. Social touches are things like: greeting each other, going out to lunch together, supporting each other’s work. There are some people who are stronger at this than others. Some people tend to form many lightweight social contacts (which is very useful). On the other hand, there are those who only have a few deep, strong relationships. A good swarming team is composed of a healthy balance of both types of people.

In summary, swarming is used differently based on the context you are in. Understand the context, and you are prepared to take advantage of the power of swarming.


Filed under: Agile, Swarming, Teams Tagged: animals, building, context, emergencies, innovation, Kanban, methods, Scrum, shifting gears, Swarming, Teams
Categories: Blogs

PostgreSQL: ERROR: column does not exist

Mark Needham - Tue, 09/30/2014 - 00:40

I’ve been playing around with PostgreSQL recently and in particular the Northwind dataset typically used as an introductory data set for relational databases.

Having imported the data I wanted to take a quick look at the employees table:

postgres=# SELECT * FROM employees LIMIT 1;
 EmployeeID | LastName | FirstName |        Title         | TitleOfCourtesy | BirthDate  |  HireDate  |           Address           |  City   | Region | PostalCode | Country |   HomePhone    | Extension | Photo |                                                                                      Notes                                                                                      | ReportsTo |              PhotoPath               
          1 | Davolio  | Nancy     | Sales Representative | Ms.             | 1948-12-08 | 1992-05-01 | 507 - 20th Ave. E.\nApt. 2A | Seattle | WA     | 98122      | USA     | (206) 555-9857 | 5467      | \x    | Education includes a BA IN psychology FROM Colorado State University IN 1970.  She also completed "The Art of the Cold Call."  Nancy IS a member OF Toastmasters International. |         2 | http://accweb/emmployees/davolio.bmp
(1 ROW)

That works fine but what if I only want to return the ‘EmployeeID’ field?

postgres=# SELECT EmployeeID FROM employees LIMIT 1;
ERROR:  COLUMN "employeeid" does NOT exist
LINE 1: SELECT EmployeeID FROM employees LIMIT 1;

I hadn’t realised (or had forgotten) that field names get lower cased so we need to quote the name if it’s been stored in mixed case:

postgres=# SELECT "EmployeeID" FROM employees LIMIT 1;
(1 ROW)

From my reading the suggestion seems to be to have your field names lower cased to avoid this problem but since it’s just a dummy data set I guess I’ll just put up with the quoting overhead for now.

Categories: Blogs