Skip to content

Feed aggregator

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

Corporate Values: Really Valuable, or Really Just a Poster?

Agile Management Blog - VersionOne - Thu, 10/02/2014 - 17:06

You hear about the agile values and they seem to make sense, but what the heck is a value system? And how do you use value systems in your daily work? Do your values really help you do your job better, or are they really just a poster in your office kitchen?

When I say values, I’m talking about beliefs that guide behavior – as opposed to the term value meaning ‘the benefit of what is being produced.’ In software we use both “agile values” and “business value,” but they represent different things.

Corporate values have peppered company literature for ages.  These value statements are important expressions of the community and culture within a company.  In larger organizations, however, those values are often so abstract that it’s tough to impact a team’s work.

The notion of a value system to guide agile software development emerged in Kent Beck’s inclusion of values with the introduction of Extreme Programming (XP) in the late ‘90s.   A similar set of values was added to Scrum soon afterward. And soon after that, the Agile Manifesto was born. It brought software teams a straightforward value statement that today remains a powerful influence on the behavior and success of agile software development teams all over the world.

The concept of a human value system has been reasonably well studied in psychology since the ‘50s, but before 1999 (when Kent posed the question, “What is it that we value?”), developers simply didn’t talk about values – only the work at hand. People brought abstract, personal values in to work with them, which may have influenced behavior lightly.  This introduction of a value system was one of the most innovative parts of XP.  The XP values are Communication, Simplicity, Feedback, Courage and Respect. With the Agile Manifesto, that contribution expanded to the broader software industry and beyond, opening a new focus on behavior and improving the way we do things.

Let’s back up and define the agile values…

Watch this video: “The Agile Manifesto – 4 Agile Values Explained”

Sound familiar?

You’ve probably seen these agile values introduced in agile training, and they are easy to learn. They also read well on posters. But how do they affect you every day, every sprint, every release?

The utility of the value system is often lost to the intense focus on the agile frameworks and practices. Back when XP was still the most common agile approach, I gave a popular talk that included asking the audience, “What is XP?”  Invariably, it would take many minutes and an awkward silence after all of the practices were exhausted for someone to timidly mention the values.  Most certified Scrum people are not be able to articulate the Scrum values.  Of the roughly 150 words squeezed into the official Scaled Agile Framework® diagram, only one of values, Code Quality, made the cut (alignment, transparency, and program execution are the omitted three).  We have a long way to go to appreciate the important role that values play in enabling teams to be empowered to adapt their practices and maximize their delivery.

So, why are these values so important?  Aren’t we doing OK with the values being the footnote they are?

To see the answer, one needs to look no further than the frustration expressed around the dogma of agile.  A common complaint of Scrum team members is an almost irrational commitment to follow the rules of Scrum blindly.  Ironically, one reaction of the Scrum community to SAFe™ is that it is overly prescriptive in how organizations should scale Scrum.  In both cases, an increased focus and incorporation of the values leads teams to a better place.

In the absence of shared values to guide the adaptation of our practices, teams are left to resort to static rules to guide their behaviors.  We see silly arguments like “Should the Product Owner participate in the Daily Scrum?”  In the context of the Scrum values (Focus, Courage, Openness, Commitment and Respect), a team can answer that question easily and optimally by themselves.  We don’t need to enforce consistent practices, as long as teams apply the values to their situation.

Let’s explore some specifics 

The agile values system can guide daily decisions about working through problems with teams and individuals in a way that corporate values may not be able to.  Any problem we are trying to solve can be addressed with more rules and process, more contracts, more documents, more upfront planning.  Those are our traditional, comfort-zone, status quo solutions.  I can almost guarantee that in an early sprint retrospective with a new agile team, some of the feedback will be, “Had we spent more time documenting up front, we would not have had this problem.”

There will be times where those items “on the right” in the Manifesto will be part of the solution to our challenges.  But a commitment to our values will drive innovative solutions that better support our use of agile.  Examples include the increased use of tele-presence technology with distributed teams — reconstructing our workspaces, reconfiguring teams, and even relocating people — and collaborating with people we didn’t even realize were involved in, or affected by, our work.  The values will guide us to solutions that enhance agile, rather than contradict it.

One of my favorite examples where the values guided the solution to a problem was an SDLC compliance change at a very large financial services company.  Existing SDLC practices required numerous artifacts to be delivered within each phase of a project.  Requirements documents had to be signed off during the requirements phase, prior to design, etc.  The agile advocates needed this process requirement changed to empower agile teams to deliver shippable increments in each sprint.  But this needed to be done in a way that was still compatible with the majority of project teams who were still following the phased approach.

So, rather than create a big conflict, demanding that the whole process be changed, a simple change was made.  Audit artifacts are still required for the business, but teams have discretion as to WHEN artifacts get produced.  All of the artifacts are required when they close projects, but the team decides when it is optimal to do it. They don’t have to sign off on a Requirements document in the beginning of a long plan. Requirements can be modified over time, and they can furnish a signed-off Requirements document at the end. This moved the organization closer to the Individuals and Interactions value, while respecting the importance of Process and Tools in the broader organization.  A dogmatic stance on Scrum practices would not have been so open to that solution.  Later, further updates gave teams more discretion of WHICH artifacts were valuable enough to produce, further empowering the teams for continuous improvement.

So, the next time you’re in your Daily Scrum or Retrospective – or even just solving a problem – reflect on what is being talked about. How are teams and individuals working together to identify solutions? As you move across release and process design (teams and programs), pull out the agile values and assess whether your decisions and those of your teams reinforce the agile values or diminish them. Are they helping the organization make decisions that drive working software?  Use the values to guide your solutions and improvements.  If values aren’t helping people do their jobs better, why bother? At that point, they are just poster fodder!

Categories: Companies

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

Putting Down the Tools

Agile Zen - Tue, 09/30/2014 - 21:41

This is a guest post from Marcus Blankenship.

Putting Down the Tools Avoiding the #1 Mistake All New Software Managers Make in a Crisis

Yes, we’ve all done it.

I’ve done it. My managers have done it. And most likely, it’s the default setting for many battle-worn team leads.

In those crisis moments when expectations are high, everything is going off the rails, and the deadline was yesterday, all new software managers will utter one fateful sentence.

"It would be so much faster if I just did this myself."

Then they pick up the IDE, close the office door, and retreat into the code.

What they don’t realize is that they’ve just kicked off a chain reaction of negative work practices that will plague their team for months.

Save Yourself

As you probably understand all too well, the programming world is full of fires to extinguish. No matter what your company’s size or specialty, you are going to hit many, many pressure cooker days.

It’s up to you to anticipate the inevitable before it happens and make a firm, conscious choice not to try to code your way out of a crisis.

Why We Make This Classic Mistake

Making the switch from programmer to team lead can be flat out awkward at times. You’ve gone from playing in the orchestra from leading it, which really shakes up your identity.

The most significant shift comes with the realization that you’re no longer a production unit, but you’re still working in an industry that values production. If you’ve always taken pride in the tidy transaction of being paid for your output, management is a strange new world.

Mixed Messages

First off, while promotions are a much-coveted status symbol, they carry a built-in mixed message. It’s as if your company is saying, "You’re such a great programmer! Now let’s have you do less of that."

Doing less coding often feels like you’re doing less altogether or that you’re not as important to the company, especially when you’re just learning the ropes.

Dependent on Others

Then there’s the new reality of how production happens. As a programmer, your brainpower and clever workarounds could conjure magnificent code from your fingers.

The programs you created could keep manufacturing production humming or bring it to a standstill. Entire businesses hung on your creations.

Now you’re dependent on other people to create the code that works this magic. And making the switch from creating your own technological incantations to supporting other people’s efforts really feels awkward for a while.

It Gets Worse

That clumsy beginner’s feeling gets cranked up when you face the new aspects of team dynamics and the reality of being without your most powerful weapon: your ability to code.

But you really get triggered by array of new expectations staring at you, like:

  • Figuring out your boss’s agenda
  • Assigning work to former coworkers
  • Dealing with morale speed bumps
  • Steering through software quality problems

Stepping into a new management role can feel like stepping into a plane’s cockpit without any flight training. There are all these complicated, unfamiliar dials and gauges you don’t understand, and you don’t know if that blinking light means an engine has failed or the coffee’s ready.

In order to escape this anxiety loop, many new managers fall into one of two patterns:

  • Code less, but indulge their coding desires by putting out fires and debugging whenever possible.
  • Code even more intently, blocking out team members and undermining their credibility as a leader.

Each of these positions is a pattern that will cause you to fail.

Let me say it again. Retreating to the position of "I’ll do it myself" isn’t going to save you any time or frustration. It’s only going to crank up the problems.

## I’ll Do It Myself’: Say Hello to a Cascade of Problems

Once you’ve uttered those fateful words, you are no longer doing the job you were paid to do: leading. And if you’re not doing your job, especially when your team needs your leadership most, then no one is.

If you follow through on your natural desire to just do it yourself, you’ve chosen to avoid doing the following critical items:


Checking in with your team members and other departments is the heart of your work. But chaining yourself to your computer stops that cold. Suddenly, you’ve cut off any team discussions about quality, progress, or individual development. Everyone loses.


Jumping in to correct someone else’s work not only short-circuits their learning process, it teaches them to do substandard work. Pretty soon they only turn in partially completed work because they figure you’ll just redo it anyway.

"Why bother?", they think. They lose their drive, you lose their trust, and projects start to suffer.

It’s like a conductor wrestling the tuba away from the tuba player.


When you move back into production mode, there’s no one available to keep team moving forward. Essential work like status updates, work review, and new project preparation is completely out the window until you pick your head up.

You’ve just traded away hours of non-replaceable time and energy that should have been devoted to doing the job you’re hired to do. And when you get back to the work that’s been piling up on your desk, you’ve got to dig out all over again.


Let’s be honest. It feels great to be a hero, swooping in to save the day with a brilliant solution. But the cost is just too high.

A "quick fix" always takes much longer, turning your one-hour job into six hours (or more!) of mind-numbing panic. While you code up a fix, your resentment and exhaustion build and you’re teaching your team to depend on your last-minute efforts to bail them out instead of their own skills.

Management Skills

Running to your comfort zone feels safe, but it’s a very limited strategy that keeps you from making the changes necessary for you to be a good manager.

Trust me. Take a chance, drop the IDE security blanket and interact with your team instead.

Best Practices for Crises

While you’re waiting for your team to complete their work, you don’t need to sit passively or beat them with the boss stick. Here are a few tips that will keep you sane and your team on track.

Don’t Do it Yourself

If there’s a problem that you desperately need to rework, *don’t do it yourself. Grab a programmer and say, "Let’s review this code together to fix it."

Sure, you just scratched your itch by getting involved, but you’ve also established much-needed rapport and created up a teaching moment–for both of you.


Panicked about a deadline? Get a status update from the programmers, adjust the workload if needed, and contact the client (or your boss) to give them an update.

Once again, you’ve opened lines of communication and placed your focus on the overall project, not just your team’s to-do list or your stress.

OK, Go Ahead And Code…

Can’t keep yourself away from temptation? Fine. Then code. But don’t code anything that will be used in production.

I cannot emphasize this enough. If you absolutely, positively can’t resist, then choose a project that is on the back burner. You don’t want to muck up a project in process.

This Is About the Long Game

Great management practices depend on a solid, thoughtful foundation created outside the heat of crisis. But it’s worth remembering that reputations are earned and character is uncovered during crucial, adrenaline-filled moments.

Remember that your purpose as a manager is to create a team that is capable of producing excellent code.

In those instinct-driven moments, especially in beginner’s panic, please take a step back. Avoid this classic management blunder.

About the Author

Nearly 20 years ago I made the leap from senior-level hacker to full-on tech lead. Practically overnight I went from writing code to being in charge of actual human beings.

Without training or guidance, I suddenly had to deliver entire products on time and under budget, hit huge company goals, and do it all with a smile on my face. I share what I’ve learned here.

Categories: Companies

Test Automation in the Age of Continuous Delivery - Tue, 09/30/2014 - 19:57
  I spend a lot of my time with clients figuring out the minutia of how to implement optimal test automation strategies that support their transition to Continuous Delivery. The goal is typically to be able to release software after each 2-week iteration (Sprint). When faced with such a compressed development and testing schedule, most […]
Categories: Communities

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

Agile Culture

Scrum Expert - Tue, 09/30/2014 - 15:58
If you asked software developers about Agile, there are chances that a majority will discuss it with words like “Scrum”, “sprints” or “retrospectives”. However Agile is not just a collection of techniques and practices, but it is more a state of mind or a culture. This is the topic of this book written by Pollyanna Pixton, Paul Gibson and Niel Nickolaisen. All the people and values aspects of Agile software development are discussed in this book that provides both conceptual material and real life stories. This is a book that I ...
Categories: Communities

Agile Slovenia, Ljubljana, Slovenia, October 10 2014

Scrum Expert - Tue, 09/30/2014 - 14:39
Agile Slovenia is a one day conference focused on Agile and Scrum topics that take place in Ljubljana. Agile Slovenia is an event where you can turn theory in action, meet agile people, listen to agile pioneers, expand your knowledge. It features both local and international Agile experts. In the agenda you can find topics like “Shifting from manufacturing product to creating a service”, “Complex Projects aren’t planable but controllable”, “There’s no such thing as an agile contract”, “How Agile Coaches help us win – the Agile Coach role at Spotify”, ...
Categories: Communities

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

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.