Skip to content

Feed aggregator

x-Banning a process

Improving projects with xProcess - Thu, 09/11/2014 - 13:15
I've just proposed an experience paper for LKUK14 - "x-Ban the process! (or how a product team is improving value delivery rate with Kanban)". Feel free to vote for it by the way here!

Scrumban, Xanpan (XP-ban) - even Prince-ban and DSDM-ban - have all been used as portmanteau words to explain the journeys from a particular named process or framework to a continually evolving and improving process, guided by the principles and practices of Kanban. If you are trying to apply a named process but frustrated by a patchy track-record of improvement, consider the alternative: x-Ban it!

When I was asked in early 2013 if I would work with Clearvision's product development team, they had just adopted Scrum (a matter of weeks before). Their process, like most I've reviewed from teams claiming to use Scrum, was not compliant with a large number of Scrum rules. It was pragmatic, constrained, variably applied and ripe for improvement... but it certainly wasn't Scrum. We had two choices - apply Scrum rules as soon as possible (defining the backlog of necessary changes and a timetable to apply them), or “x-Ban” it (use Kanban to attain evolutionary changes that we kept only if we were confident they resulted in improvements). We did the latter.

There are many lessons I've learned from this experience: some things that worked - and some that didn’t. They're lessons and general principles that others can apply on a similar journey. It has taken much longer to adopt some practices than I expected, the current process is quite different than I expected when I started 18 months ago (it’s more Scrum-like now than when I arrived for example!), but it is a route I would recommend to others.

Start x-Banning your process now!
Categories: Companies

Killing the Buddha

Agile Tools - Thu, 09/11/2014 - 08:41

imagesIJ4EINVG

 

“If you meet the Buddha on the road, kill him!”

This is a popular saying derived from an old Zen koan. When it comes to working with Agile projects I find this saying very appropriate. People who do Agile transformations typically talk about finding the Way (the road) and often speak with almost religious fervor regarding Agile processes.

In fact, Agile is really just one short step away from organized religion. You have daily meetings, attend retrospectives where we examine our patterns of behavior deeply, we worship idols with bizarre names like “Kanban” and “Scrum” and fight (flame) wars over them. We anoint our priests as guardians of that process (yes, I’m talking about you, Scrum Masters), and agonize endlessly over whether we and others are following the right path.

Wow, maybe Agile actually is a religion. That’s pretty scary. I’ve got to go sit down now.

OK, I’m back. What were we talking about? Oh yeah, killing the Buddha. So, given my little digression above, it would be pretty easy to rewrite that old Zen saying like this:

“If you meet an Agile Guru while on your journey (to excellence, improvement, whatever), kill him!”

Now aside from sounding terribly violent, what the heck do I mean by that? It turns out, that having an Agile guru around is pretty limiting when it comes to learning and continuing to grow. Whenever we have a guru like that, what do we do? We defer to his expertise. We wait for him to provide the answer and we stall our own learning journey. Having an Agile guru around can freeze an organization’s development. You end up limited to whatever level the guru is at.

fish

Many organizations have these characters lurking in their midst. Heck, I was one once. I still have a business card with a title of “Though Leader” emblazoned on it around somewhere. I’m here to tell you it can happen to anybody. One day you are a perfectly decent, self-respecting developer and then WHAM! you become an Agile Coach, or a Thought Leader, or a Lean Sensei, or any number of other wacky guru code names.

You become, THAT guy.

And trust me, you don’t want to be that guy. You know the one, the Agile guy? The guy who simply must render an Agile judgment every time he opens his mouth. The guy who everyone defers to when it comes to do all things Agile. To paraphrase the old Life cereal commercial “Is it Agile? Hey, let’s get Mikey. He’ll judge anything!”

…oh brother, I think I just dated myself straight back to the stone age.

So what do you do when you have an Agile guru? You get rid of him! What if YOU are the Agile guru? Now that’s awkward. Well, your mission is to eliminate that perception. How do you do that?

  1. Keep your mouth shut
  2. Stop telling people what’s Agile (see #1). Use pantomime or something instead.
  3. Bring in, find, unearth or otherwise manufacture someone who has more expertise than you do. Understand that by doing this, you will run the very real risk of learning something. Sorry.
  4. Rinse and repeat until nobody mentions Agile in your presence. Ever.

So if you find yourself or someone you love has become an Agile guru, take heart! There is a cure! The best thing you can do to avoid stifling (and annoying) everyone in your organization trying to get work done is kill the Buddha.


Filed under: Agile, Lean, Process, Scrum Tagged: Buddha, Kanban, Lean, mastery, Scrum, Sensei, Thought Leader
Categories: Blogs

Xcode 6 GM & Learning Swift (with the help of Xebia)

Xebia Blog - Thu, 09/11/2014 - 08:32

I guess re-iterating the announcements Apple did on Tuesday is not needed.

What is most interesting to me about everything that happened on Tuesday is the fact that iOS 8 now reached GM status and Apple sent the call to bring in your iOS 8 uploads to iTunes connect. iOS 8 is around the corner in about a week from now allowing some great new features to the platform and ... Swift.

Swift

I was thinking about putting together a list of excellent links about Swift. But obviously somebody has done that already
https://github.com/Wolg/awesome-swift
(And best of all, if you find/notice an epic Swift resource out there, submit a pull request to that REPO, or leave a comment on this blog post.)

If you are getting started, check out:
https://github.com/nettlep/learn-swift
It's a Github repo filled with extra Playgrounds to learn Swift in a hands-on matter. It elaborates a bit further on the later chapters of the Swift language book.

But the best way to learn Swift I can come up with is to join Xebia for a day (or two) and attend one of our special purpose update training offers hosted by Daniel Steinberg on 6 and 7 november. More info on that:

Categories: Companies

Das Eis brechen – mit Stift, Papier und Visual Scrum

Scrum 4 You - Thu, 09/11/2014 - 07:45

Die beliebte Small-Talk-Frage: „Und was machst Du so beruflich?“ wird für Scrum Coaches, ScrumMaster und Consultants nicht selten zur Bewährungsprobe. „Ich bin ScrumMaster“ erzeugt in unwissenden, weil wenig technischen Berufsgruppen oft nur ein Stirnrunzeln und nicht weniger häufig ein müdes Lächeln ob des ulkigen Fremdwortes – auch gerne begleitet von der Frage, welchen Gürtel man denn da schon habe.
Und dann fängt es im Kopf an zu rattern: Wo fange ich jetzt mit der Erklärung an, bei Adam und Eva? Beim Rugby? Bei Nonaka, Sutherland und Schwaber? Egal, wofür man sich entscheidet, so wirklich trivial wird es selten. Und das obwohl Scrum nichts anderes macht, als die für die Produktentwicklung intuitiv richtigen Dinge in einen Rahmen zu packen und interdisziplinäre Teams in kurzen Zyklen gemeinsam an einer Lösung arbeiten zu lassen.

Hier verhält es sich mit Scrum wie mit jedem anderen Thema auf diesem Erdball: Wenn man nur tief genug drinsteckt, lässt sich der Grad der Komplexität nach Belieben erhöhen und ehe man sichs versieht, hat man die Zuhörer in den Schlaf begeistert. Und nicht nur im privaten Rahmen sind die Erklärungskünste des agilen Prozesshüters gefragt. Es liegt in der Natur seines Berufs, an den Schnittstellen der Scrum-Teams für ein gemeinsames Verständnis sorgen zu müssen und den Prozess weiter ins Unternehmen zu tragen.
Und damit ist es ja längst nicht getan. An dieser Stelle soll die Debatte darüber, ob ein erfolgreicher ScrumMaster technisches Verständnis haben muss oder nicht, nicht angefeuert werden. Fakt ist aber, dass ein Team nicht nur zwischenmenschliche Probleme aus der Welt schaffen muss, um das gemeinsame Ziel zu erreichen.

Wohl demjenigen, der es versteht, Stift und Papier in den Grundfunktionen zu bedienen: schreiben und skizzieren. Es ist kein Zufall, dass sich Boris Gloger Consulting und die Kommunikationslotsen zusammengetan haben, um Scrum Consulting und Visual Facilitation zu einem gemeinsamen Training zu verschmelzen. Für die Teilnehmer bedeutet das: Sie erlernen die bikablo® Grundtechnik und können sie direkt auf ihren Arbeitsalltag im agilen Umfeld anwenden.

Ein Schelm, wer glaubt, hier gehe es lediglich darum, schöne Flipcharts zu malen – getreu dem alten Politiker Schlachtruf „Inhalte überwinden“. Nein, hier geht es darum, sich, seine Teamkollegen, Kunden oder Stakeholder schnell und effektiv zu einem gemeinsamen Verständnis für eine Situation oder der Lösung eines Problems näher zu bringen.

ScrumFlow_VisualScrum

Angenehmer Nebeneffekt: Wenn Sie das nächste Mal jemand fragt, was Sie eigentlich machen, malen Sie es einfach auf!

Tipp: Visualisieren wie ein Meister – mit den Tipps aus unserem Training “Visual Scrum” sind chaotische und inhaltsleere Flipcharts Schnee von gestern. Melden Sie sich hier gleich zum nächsten Termin am 13. & 14. Oktober 2014 in Köln an!

Related posts:

  1. Visual Scrum
  2. The five secrets of a successful Scrum training | May 22nd , Recife, Brazil
  3. Servant Leadership

Categories: Blogs

Adventures in Europe

ScrumSense.com - Peter Hundermark - Wed, 09/10/2014 - 22:41
IMG_5392

Denmark trainees

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

My trip started in Copenhagen, where I spent a wonderful two days with Carsten Feilberg, a friend and an incredible tester. We spent time refining our workshop for Let’s Test Oz where we will be presenting on Communicating Complex Information in Sydney next Tuesday. We have been designing the workshop over mail and Skype for the past couple of months and being together once more re-enforced the Agile principle that face-to-face communication is the best kind. We have come up with a great design and I am really looking forward to our session.

IMG_5393

CSM Aarhus with Bent Myllerup

My next stop was Aarhus also in Denmark. There I met up with Bent Myllerup, a very experienced CST and CSC with agile42. I spent two days co-training a public Certified Scrum Master (CSM) class with Bent in Denmark. Lucky for me the course was delivered in English. We had eight participants and received wonderful feedback. I was able to train some of the modules and learned some new techniques from Bent. I love being in a fresh context, because I can always learn new things and see how different people understand and take in information. It’s also interesting to see the European adoption of Agile, the different industries that are beginning to understand the value of empirical process control and fast feedback loops, and  working with teams instead of individuals. Bent speaks about a truck factor which I thought was a novel way of illustrating the point of resilience. The track factor is the number of people in a team that, if they were hit by a truck or won the lotto and left, the project would have to stop. So if you have only one key team member that knows everything and that information is not shared in some way with the team then you have a truck factor of one. A higher truck factor is better than a lower one. What is the truck factor of your teams?

CSM in Berlin with Andrea Tomasini

CSM in Berlin with Andrea Tomasini

From Denmark I went to Berlin. Berlin is an amazing and crazy city. I arrived early on Saturday morning. Half of the city hadn’t woken up yet and the other half hadn’t been to bed. I was lucky enough to get to explore and see some of the sights. Sunday evening I met up with Andrea Tomasini, another very experienced and talented trainer and coach from agile42. We ran through our course plan for another CSM class on Monday and Tuesday. I got the opportunity to see Andrea in action and to train some of the course modules. I really enjoyed the way that both trainers focused not only on Scrum, but also on how important it is to be Agile. Transformation is difficult and changing your mindset early on is important. It’s also interesting to see how many companies both in South Africa and internationally have similar problems. We had 20 participants from all different backgrounds from gaming to building of aeroplanes. Who said Agile is just for software?

CSM in Berlin with Andrea Tomasini

CSM in Berlin with Andrea Tomasini

It’s amazing to see how many different contexts are interested in the principles and values of Agile and Scrum, and how many people are really keen and eager to learn. The Training from the Back of The Room approach also helps to encourage people to learn on their own and creates an atmosphere of excitement and energy.

All in all it was an amazing experience. I had the opportunity to work with some great coaches and trainers and to learn new things that I can bring home. I love how supportive and encouraging our community is, both in South Africa and internationally. This is a long and tough journey and I feel that this trip has really helped to get me to the next level.

I am looking forward to co-training the next CSPO course in Johannesburg with Peter starting 30 September. Maybe I will see you there. If not I’ll be speaking at the Scrum Gathering in Cape Town in October, or maybe I will catch you at Let’s Test in Australia next week!

The post Adventures in Europe appeared first on ScrumSense.

Categories: Blogs

The Rules Have Changed

Sonar - Wed, 09/10/2014 - 22:34

If you’ve already taken a look at SonaQube 4.4, the title of this post wasn’t any news to you. The new version introduces two major changes to the way SonarQube presents data: the new rules space and the changes to the source viewer.

If you’ve been keeping up version to version, you’ve noticed new styling creeping in to the design. We formed a Web team this year to focus on transforming SonarQube’s interface into something as sexy as the underlying functionality, and the team is starting to hit its stride.

The new rules space is a reimagining of how to interact with rules. Previously, they were accessed only within the context of their inclusion (or not) in a single profile. Want to know if a given rule is present in multiple profiles? Previously, you had to hunker down because it could take a while.

Now rules have their own independent presentation, with multi-axis search.

All the search criteria from the old interface are still available, and several new ones have been added. The rule tags introduced in SonarQube 4.2 become searchable in 4.4, as do SQALE characteristics. And for most criteria you can search for multiple values. For example, it’s now easy to find rules in both “MyFirstProfile” and “MySecondProfile” simply by checking them both off in the profile dropdown.

Conversely, if you want to see all the profiles that include the rule “Unused method parameters should be removed”, simply pull it up in the search.

At the bottom of the rule listing, you’ll see all the profiles it’s included in, along with the severity and any parameters for the profile. If you’re an administrator, you’ll have controls here to change a rule in its current profiles and to add it to new profiles. The search results pane on the left also features bulk change operations for administrators, allowing them to toggle activation in a profile for all the rules in the search results.

It’s also easy now to find clone-able rules such as XPath and Architectural Constraint in Java; they’re called “templates” starting in 4.4, and they get their own search criterion.

I shouldn’t forget to mention the second tier below the search criteria. It represents the categories the search results span: languages, repositories, and tags, and the search results can be further filtered by clicking on the entries there. (A second click deselects and unfilters). For instance, here’s the default search filtered to show C rules that have been tagged for MISRA C++:

The point of this radical overhaul is to give you, the user, a better way to explore rules; to see what rules are available, which rules are used where, and which rules you might want to turn on or ask your administrator to turn on.

One interesting aspect of this is the new ability to explore rule activation across languages. For rules that are implemented directly within a plugin, as opposed to coming from 3rd party tools like FxCop or FindBugs, you’ll see that when the same rule is implemented in multiple languages, it usually has the same key (there are a few historical exceptions.)

So, for example, now you can easily see whether the same standards are being enforced across all languages in your organization.

The new rules space is just one piece of our new attitude toward data. Next time I’ll talk about the complete rework of the component viewer. It’s a reimagining that’s just as radical as this one.

Categories: Open Source

Cloud Changes the Game from Deployment to Adoption

J.D. Meier's Blog - Wed, 09/10/2014 - 17:22

Before the Cloud, there was a lot of focus on deployment, as if deployment was success. 

Once you shipped the project, it was time to move on to the next project.  And project success was measured in terms of “on time” and “on budget.”   If you could deploy things quickly, you were a super shipper.

Of course, what we learned was that if you simply throw things over the wall and hope they stick, it’s not very successful.

"If you build it" ... users don't always come.

It was easy to confuse shipping projects on time and on budget with business impact.  

But let's compound the problem. 

The Development Hump

The big hump of software development was the hump in the middle—A big development hump.  And that hump was followed by a big deployment hump (installing software, fixing issues, dealing with deployment hassles, etc.)

So not only were development cycles long, but deployment was tough, too.

Because development cycles were long, and deployment was so tough, it was easy to confuse effort for value.

Cloud Changes the Hump

Now, let's turn it around.

With the Cloud, deployment is simplified.  You can reach more users, and it's easier to scale.  And it's easier to be available 24x7.

Add Agile to the mix, and people ship smaller, more frequent releases.

So with smaller, more-frequent releases, and simpler deployment, some software teams have turned into shipping machines.

The Cloud shrinks the development and deployment humps.

So now the game is a lot more obvious.

Deployment doesn't mark the finish.  It starts the game.

The real game of software success is adoption.

The Adoption Hump is Where the Benefits Are

If you picture the old IT project hump, where there is a long development cycle in the middle, now it's shorter humps in the middle.

The big hump is now user adoption.

It’s not new.  It was always there.   But the adoption hump was hidden beyond the development and deployment humps, and simply written off as “Value Leakage.”

And if you made it over the first two humps, since most projects did not plan or design for adoption, or allocate any resources or time, adoption was mostly an afterthought.  

And so the value leaked.

But the adoption hump is where the business benefits are.   The ROI is sitting there, gathering dust, in our "pay-for-play" world.   The value is simply waiting to be released and unleashed. 

Software solutions are sitting idle waiting for somebody to realize the value.

Accelerate Value by Accelerating Adoption

All of the benefits to the business are locked up in that adoption hump.   All of the benefits around how users will work better, faster, or cheaper, or how you will change the customer interaction experience, or how back-office systems will be better, faster, cheaper ... they are all locked up in that adoption hump.

As I said before, the key to Value Realization is adoption.  

So if you want to realize more value, drive more user adoption. 

And if you want to accelerate value, then accelerate user adoption.

In Essence …

In a Cloud world, the original humps of design, development, and deployment shrink.   But it’s not just time and effort that shrink.  Costs shrink, too.   With online platforms to build on (Infrastructure as a Service, Platforms as a Service, and Software as a Service), you don’t have to start from scratch or roll your own.   And if you adopt a configure before customize mindset, you can further reduce your costs of design and development.

Architecture moves up the stack from basic building blocks to composition.

And adoption is where the action is.  

What was the afterthought in the last generation of solutions, is now front and center. 

In the new world, adoption is a planned spend, and it’s core to the success of the planned value delivery.

If you want to win the game, think “Adoption-First.”

You Might Also Like

Continuous Value Delivery the Agile Way

How Can Enterprise Architects Drive Business Value the Agile Way?

How To Use Personas and Scenarios to Drive Adoption and Realize Value

Categories: Blogs

Planning Feedback: Don’t Panic!

Agile Tools - Wed, 09/10/2014 - 08:31

Ring the Alarm

So the other day a VP asked our team for an estimate on a project. Now, putting aside whatever feelings you may have about the usefulness of estimates, we did a little planning, a little investigating, a little debating, and came up with an estimate for the project. I brought the estimate back to the VP and then the fireworks began. Apparently he had been thinking of a different number than we had given him. He wanted it done in half the time that we had forecast.

Whoops.

Now at this point in the story a lot of teams will panic and come back with one of two reactions:

  1. Fight – “We can’t do that! That’s not Agile” (or some variation on that tired theme)
  2. Cave – “We have no choice…”

But wait a second, there is a middle path. You can agree, but ask what can be compromised in terms of scope or other project constraints. You see, a new project is not just a learning process for you. Its also  learning process for the customer too. When  you get that first feedback, DON’T PANIC!

There is one important part of the planning process that I often see get lost: iteration. Doing a single round of planning and then presenting it to your customer as “Take it or leave it” isn’t what I’d call much of a dialog.

What we should be doing is some lightweight planning then review with the customer. “That’s horrible!” They cry, and then you say, “So what number were you thinking of?” And they return with something totally preposterous. OK, that’s cool. “Is there functionality we can drop to hit that date?”

No.

Of course not. So you go back, you scratch your head, cut out all the fluff you can find…and you still are way off the desired estimate. So then you take it back to them and say, “Hey look, I know this isn’t what you wanted, but here is the ABSOLUTE minimum we can get away with.” At which point, the customer looks at you with a tear in their eye and says these magic words, “What CAN you give me?”

Now you have a real negotiation! It may not always play out this way, but hopefully you get the point. You can’t freak out when they give you that first reaction. Stay cool – this is the first time they’ve had to test their fantasies against your capabilities. They need to learn too. So give your stakeholders a chance to work together with you on figuring out just what is possible. Negotiate. The more iterations you go through, the better your chances of coming to an agreement that everyone agrees is the best.


Filed under: Agile, Process Tagged: Agile, estimates, estimation, executives, Feedback, panic, Planning, stakeholders
Categories: Blogs

Say Why to Estimates

Bobtuse Bobservations - Bob MacNeal - Wed, 09/10/2014 - 05:33
Agile estimation surfaces a clash of cultures. Broadly speaking the Agile community consists of makers & managers. The clash between makers & managers distills to motivation: Why &...

Bobtuse can be wildly informative
Categories: Blogs

The Battle of the Agile Curmudgeons? Forbes on SAFe

Agile Product Owner - Wed, 09/10/2014 - 00:39

Hi folks,

Forbes was agile enough to interview me and publish this article on SAFe in less than a week! Thanks to Jason Bloomberg, who specializes on covering digital transformation in the enterprise, for this balanced article on SAFe and its role and reception within the Agile community. He briefly describes the history of Agile methodologies, as well as both the benefits and criticisms of SAFe, including a viewpoint from Ron Jeffries, a SAFe critic and one of the creators of XP. Bloomberg reached some interesting conclusions—based on facts, numbers, case studies—that makes this article worth the read for anyone considering or involved in a lean–agile transformation.

So in the battle between “Agile curmudgeons,” Forbes says, “the proof is in the pudding.” I couldn’t agree more. In the end, it’s the business results that matter. That is always our focus.

Stay SAFe,
–Dean

P.S. Those who know me know I’m not a curmudgeon, so he must have been referring to someone else.

Categories: Blogs

Tackling cross-cutting concerns with a mediator pipeline

Jimmy Bogard - Tue, 09/09/2014 - 18:17

Originally posted on the Skills Matter website

In most of the projects I’ve worked on in the last several years, I’ve put in place a mediator to manage the delivery of messages to handlers. I’ve covered the motivation behind such a pattern in the past, where it works well and where it doesn’t.

One of the advantages behind the mediator pattern is that it allows the application code to define a pipeline of activities for requests, as opposed to embedding this pipeline in other frameworks such as Rails, node.js, ASP.NET Web API and so on. These frameworks have many other concerns going on besides the very simple “one model in, one model out” pattern that so greatly simplifies conceptualizing the system and realizing more powerful patterns.

As a review, a mediator encapsulates how a series of objects interact. Our mediator looks like:

public interface IMediator
{
    TResponse Send<TResponse>(IRequest<TResponse> request);
    Task<TResponse> SendAsync<TResponse>(IAsyncRequest<TResponse> request);
    void Publish<TNotification>(TNotification notification) where TNotification : INotification;
    Task PublishAsync<TNotification>(TNotification notification) where TNotification : IAsyncNotification;
}

This is from a simple library (MediatR) I created (and borrowed heavily from others) that enables basic message passing. It facilitates loose coupling between how a series of objects interact. And like many OO patterns, it exists because of missing features in the language. In other functional languages, passing messages to handlers is accomplished with features like pattern matching.

Our handler interface represents the ability to take an input, perform work, and return some output:

public interface IRequestHandler<in TRequest, out TResponse>
    where TRequest : IRequest<TResponse>
{
    TResponse Handle(TRequest message);
}

With this simple pattern, we encapsulate the work being done to transform input to output in a single method. Any complexities around this work are encapsulated, and any refactorings are isolated to this one method. As systems become more complex, isolating side-effects becomes critical for maintaining overall speed of delivery and minimizing risk.

We still have the need for cross-cutting concerns, and we’d rather not pollute our handlers with this work.

These surrounding behaviors become implementations of the decorator pattern. Since we have a uniform interface of inputs and outputs, building decorators around cross-cutting concerns becomes trivial.

Pre- and post-request handlers

One common request I see is to do work on the requests coming in, or post-process the request on the way out. We can define some interfaces around this:

public interface IPreRequestHandler<in TRequest> {
    void Handle(TRequest request);
}

public interface IPostRequestHandler<in TRequest, in TResponse> {
    void Handle(TRequest request, TResponse response);
}

With this, we can modify inputs before they arrive to the main handler or modify responses on the way out.

In order to execute these handlers, we just need to define a decorator around our main handler:

public class MediatorPipeline<TRequest, TResponse> 
    : IRequestHandler<TRequest, TResponse> 
    where TRequest : IRequest<TResponse> {

    private readonly IRequestHandler<TRequest, TResponse> _inner;
    private readonly IPreRequestHandler<TRequest>[] _preRequestHandlers;
    private readonly IPostRequestHandler<TRequest, TResponse>[] _postRequestHandlers;

    public MediatorPipeline(
        IRequestHandler<TRequest, TResponse> inner,
        IPreRequestHandler<TRequest>[] preRequestHandlers,
        IPostRequestHandler<TRequest, TResponse>[] postRequestHandlers
        ) {
        _inner = inner;
        _preRequestHandlers = preRequestHandlers;
        _postRequestHandlers = postRequestHandlers;
    }

    public TResponse Handle(TRequest message) {

        foreach (var preRequestHandler in _preRequestHandlers) {
            preRequestHandler.Handle(message);
        }

        var result = _inner.Handle(message);

        foreach (var postRequestHandler in _postRequestHandlers) {
            postRequestHandler.Handle(message, result);
        }

        return result;
    }
}

And if we’re using a modern IoC container (StructureMap in this case), registering our decorator is as simple as:

cfg.For(typeof (IRequestHandler<,>))
   .DecorateAllWith(typeof (MediatorPipeline<,>));

When our mediator builds out the handler, it delegates to our container to do so. Our container builds the inner handler, then surrounds the handler with additional work. If this seems familiar, many modern web frameworks like koa include a similar construct using continuation passing to define a pipeline for requests. However, since our pipeline is defined in our application layer, we don’t have to deal with things like HTTP headers, content negotiation and so on.

Validation

Most validation frameworks I use validate against a type, whether it’s validation with attributes or delegated validation to a handler. With Fluent Validation, we get a very simple interface representing validating an input:

public interface IValidator<in T> {
    ValidationResult Validate(T instance);
}

Fluent Validation defines base classes for validators for a variety of scenarios:

public class CreateCustomerValidator: AbstractValidator<CreateCustomer> {
  public CreateCustomerValidator() {
    RuleFor(customer => customer.Surname).NotEmpty();
    RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Please specify a first name");
    RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount);
    RuleFor(customer => customer.Address).Length(20, 250);
    RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Please specify a valid postcode");
  }

  private bool BeAValidPostcode(string postcode) {
    // custom postcode validating logic goes here
  }
}

We can then plug our validation to the pipeline as occurring before the main work to be done:

public class ValidatorHandler<TRequest, TResponse>
    : IRequestHandler<TRequest, TResponse>
    where TRequest : IRequest<TResponse> {

    private readonly IRequestHandler<TRequest, TResponse> _inner;
    private readonly IValidator<TRequest>[] _validators;
    
    public ValidatorHandler(IRequestHandler<TRequest, TResponse> inner,
        IValidator<TRequest>[] validators) {
        _inner = inner;
        _validators = validators;
    }

   public TResponse Handle(TRequest request) {
        var context = new ValidationContext(message);

        var failures = _validators
            .Select(v => v.Validate(context))
            .SelectMany(result => result.Errors)
            .Where(f => f != null)
            .ToList();

        if (failures.Any()) 
            throw new ValidationException(failures);

        return _inner.Handle(request);
   }
}

In our validation handler, we perform validation against Fluent Validation by loading up all of the matching validators. Because we have generic variance in C#, we can rely on the container to inject all validators for all matching types (base classes and interfaces). Having validators around messages means we can remove validation from our entities, and into contextual actions from a task-oriented UI.

Framework-less pipeline

We can now push a number of concerns into our application code instead of embedded as framework extensions. This includes things like:

  • Validation
  • Pre/post processing
  • Authorization
  • Logging
  • Auditing
  • Event dispatching
  • Notifications
  • Unit of work/transactions

Pretty much anything you’d consider to use a Filter in ASP.NET or Rails that’s more concerned with application-level behavior and not framework/transport specific concerns would work as a decorator in our handlers.

Once we have this approach set up, we can define our application pipeline as a series of decorators around handlers:

var handlerType = cfg.For(typeof (IRequestHandler<,>));

handlerType.DecorateAllWith(typeof (LoggingHandler<,>));
handlerType.DecorateAllWith(typeof (AuthorizationHandler<,>));
handlerType.DecorateAllWith(typeof (ValidatorHandler<,>));
handlerType.DecorateAllWith(typeof (PipelineHandler<,>));

Since this code is not dependent on frameworks or HTTP requests, it’s easy for us to build up a request, send it through the pipeline, and verify a response:

var handler = container.GetInstance<IHandler<CreateCustomer>>();

var request = new CreateCustomer {
    Name = "Bob"
};

var response = handler.Handle(request);

response.CreatedCustomer.Name.ShouldBe(request.Name);

Or if we just want one handler, we can test that one implementation in isolation, it’s really up to us.

By focusing on a uniform interface of one model in, one model out, we can define a series of patterns on top of that single interface for a variety of cross-cutting concerns. Our behaviors become less coupled on a framework and more focused on the real work being done.

All of this would be a bit easier if the underlying language supported this behavior. Since many don’t, we rely instead of translating these functional paradigms to OO patterns with IoC containers containing our glue.

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

Categories: Blogs

Agile Metrics

Scrum Expert - Tue, 09/09/2014 - 17:54
“You can’t manage what you don’t measure” is an adage that is popular in project management. However, metrics programs are not easy to implement and have their dark sides. In their book “The Agile Culture: Leading through Trust and Ownership”, Pollyanna Pixton, Paul Gibson and Niel Nickolaisen provides some advice about implementing metrics, the Agile way. How do we make sure that the metrics we are using are effective and not just vehicles for giving leaders a feeling of power and control while not achieving anything useful? How do we know ...
Categories: Communities

Decorating A Backbone.Model With Features, For A UI Component

Derick Bailey - new ThoughtStream - Tue, 09/09/2014 - 17:01

I’m a huge fan of component based UI development – the idea of having individual functional things in a UI be an encapsulated “component”. Have a search form? That’s a component. The search results? A separate component. That menu system? You guessed it… a component. There are a lot of benefits to doing things this way. But there are also a lot of challenges to doing things this way. One of those challenges is adding functionality to a model that is shared between components, when only one of those components needs that functionality.

If a single UI component needs to add functionality to a model, but no other component needs that functionality, you shouldn’t be adding that code to the shared model. Heading down that path leads to far too many concerns in the model. You’ll end up with multiple chunks of code potentially in conflict, doing similar things slightly differently, all to make different UI components and behaviors happy. 

Fortunately, there’s an easy solution to this problem (especially easy in JavaScript), the decorator pattern (from Wikipedia):

In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects

Interior decorator pattern

(yes, that’s an “interior decorator”, decorating code :D)

Decorating With A Memento

In my current client project, I have to load up a model and allow it to be edited. Once edits are done they can be saved back to the server. When edits are incomplete, or when the user realizes they don’t want the edits, a cancel button can roll back the changes and close the form without saving anything. This is a problem I solved a long time ago with the Backbone.Memento plugin.

As I said above, I don’t want to include the memento features in the model directly. I want to decorate the model with the memento features only within the “edit” UI component. This will give me the ability to save / rollback the changes in the model, but also keep that save / rollback code isolated to the edit form – no other code in my app will know about this ability, and my model will stay clean and clear of this code. 

It starts with a simple model:

Next, up I have a View and a function to decorate my model with the Memento functionality.

When the view is instantiated, I apply the decorator to the model and tell the view to hang on to the decorated object. 

Now my view can correctly use the Memento methods associated with the cancel button. When someone clicks save, the changes are left in place and the view is closed. But when someone clicks cancel, the changes are rolled back.

Because this View is using a decorator to get the Memento in place, no other code has access to the Memento methods. Any code that uses the model before or after the edit view has been shown, will only have the standard model methods available. 

Sometimes The Right Thing, Not Always

This technique is tremendously useful for more than just save / cancel functionality, too. It’s quite common for validation to be UI specific, for example. One UI will have a model that needs 2 or 3 fields, the next UI will have the same model but need 2 or 3 different fields, etc. Or there may be two very unrelated UI views that both use the same model based on simple variations (admin vs non-admin user, for example). In these cases, validation is going to be specific to the UI and not generic to the model. A decorator can easily add the correct validation code to the model, for the specific view.

While the decorator pattern is useful when you need to isolate behavior, it is not always the right thing to do. Sometimes the behavior really should exist inside of the model (or whatever the object is). When dealing with behavior that is specific to a UI, though, a decorator is a great way to add behavior as needed and not have to think about it in any other context.

     Related Stories 
Categories: Blogs

Acceptance Criteria

Leading Agile - Mike Cottmeyer - Tue, 09/09/2014 - 16:47
Acceptance Criteria


Did We Build the Right Product? And, Did We Build the Product Right?

Acceptance criteria are an important yet, in my experience, often overlooked or undervalued aspect of the iterative planning process. Acceptance criteria are super important because projects succeed or fail based on the ability of the team to meet their customers documented and perceived acceptance criteria. When we clearly define acceptance criteria up front, we avoid surprises at the end of a sprint, or release, and ensure a higher level of customer satisfaction.  In other words we’re able to answer these two important questions: Did we build the right product? And, Did we build the product right?

What are Acceptance Criteria?

Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of Done”, and by done I mean well done.

We’re not talking about horsheoes here, and there is no partial acceptance: either the acceptance criteria is met or it is not.

When are Acceptance Criteria defined?

A trap that I encourage my teams to avoid is writing acceptance criteria after development has started. This leads to merely verifying that the functionality built works rather than verifying that the functionality meets user needs and expectations. If we write and review acceptance criteria before implementation begins, we’re more likely to capture the customer intent rather than the development reality.

What makes good Acceptance Criteria?

Acceptance criteria define when a work item is completed and working as expected. Acceptance Criteria should be expressed clearly, in simple language the customer would use, without ambiguity regarding the expected outcome. This sets our testers up for success, since they  will be taking our acceptance criteria and translating them into automated test cases to run as part of our continuous integration build.

What. Not how.

Another trap that I coach my teams to avoid is ‘The how trap.’ Acceptance Criteria should state intent, but not a solution (e.g., “A user can approve or reject an invoice” rather than “A user can click a checkbox to approve an invoice”). The criteria should be independent of the implementation, and discuss WHAT is expected, and not HOW the functionality will be implemented.

Acceptance Criteria Formats

The Given/When/Then format is helpful way to specify acceptance criteria:

Given some precondition When I do some action Then I expect some result

When we write acceptance criteria in this format, it not only provides a consistent structure, but we are also helping testers determine when to begin and end testing for that specific work item.

Sometimes it’s difficult to construct acceptance criteria using the given, when, then, format. Particularly when dealing with system level user stories. In those cases, I’ve found that using a verification checklist works well.

Another advantage to Verification checklists is that they are also simple to individually mark as complete as we implement functionality.

What are some of the challenges or techniques you’ve found when writing acceptance criteria?

The post Acceptance Criteria appeared first on LeadingAgile.

Categories: Blogs

Agile Manifesto and Enterprise – Rant and Rave (Session Proposal)

Learn more about our Scrum and Agile training sessions on WorldMindware.com

I’ve proposed a session called “Agile Manifesto and Enterprise – Rant and Rave” for the Toronto Agile Community’s conference “Toronto Agile and Software“.  The session is based loosely on my earlier article “The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization“, as well as some of the things that I do in the 2nd day of my Certified Scrum Master training session.  If you are thinking of coming to the conference, I would greatly appreciate your votes or feedback on my session proposal!

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!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Cost, Value & Investment: How Much Will This Project Cost? Part 1

Johanna Rothman - Tue, 09/09/2014 - 14:48

I’ve said before that you cannot use capacity planning for the project portfolio. I also said that managers often want to know how much the project will cost. Why? Because businesses have to manage costs. No one can have runaway projects. That is fair.

If you use an agile or incremental approach to your projects, you have options. You don’t have to have runaway projects. Here are two better questions:

  • How much do you want to invest before we stop?
  • How much value is this project or program worth to you?

You need to think about cost, value, and investment, not just cost when you think about about the project portfolio. If you think about cost, you miss the potentially great projects and features.

However, no business exists without managing costs. In fact, the cost question might be critical to your business. If you proceed without thinking about cost, you might doom your business.

Why do you want to know about cost? Do you have a contract? Does the customer need to know? A cost-bound contract is a good reason.  (If you have other reasons for needing to know cost, let me know. I am serious when I say you need to evaluate the project portfolio on value, not on cost.)

You Have a Cost-Bound Contract

I’ve talked before about providing date ranges or confidence ranges with estimates. It all depends on why you need to know. If you are trying to stay within your predicted cost-bound contract, you need a ranked backlog. If you are part of a program, everyone needs to see the roadmap. Everyone needs to see the product backlog burnup charts. You’d better have feature teams so you can create features. If you don’t, you’d better have small features.

Why? You can manage the interdependencies among and between teams more easily with small features and with a detailed roadmap. The larger the program, the smaller you want the batch size to be. Otherwise, you will waste a lot of money very fast. (The teams will create components and get caught in integration hell. That wastes money.)

Your Customer Wants to Know How Much the Project Will Cost

Why does your customer want to know? Do you have payments based on interim deliverables? If the customer needs to know, you want to build trust by delivering value, so the customer trusts you over time.

If the customer wants to contain his or her costs, you want to work by feature, delivering value. You want to share the roadmap, delivering value. You want to know what value the estimate has for your customer. You can provide an estimate for your customer, as long as you know why your customer needs it.

Some of you think I’m being perverse. I’m not being helpful by saying what you could do to provide an estimate. Okay, in Part 2, I will provide a suggestion of how you could do an order-of-magnitude approach for estimating a program.

Categories: Blogs

Management Tips from Waffle's Andrew Homeyer

Rally Agile Blog - Tue, 09/09/2014 - 14:00

This post, an interview between Grokky co-founder Dan Abdinoor and Rally engineer Andrew Homeyer, originally appeared at the Grokky blog on September 8. Andrew is product lead and engineering manager of Waffle, a Rally Innovation Labs project created in 2013. Andrew currently manages a team of six and his manager is Rally’s Chief Technology Officer. 

Dan: Andrew, please introduce yourself!

Andrew: I’m an intrapreneur and engineer. As for titles I sometimes go by Chief Waffle Maker. In truth, I balance my time between leading the team building Waffle.io and trying to still do a bit of development myself.

Dan: Waffle is part of Rally Software; what's the story behind that?

Andrew: Waffle.io is an Enterprise Lean Startup; that is, we’re a small team building Waffle like a startup inside Rally Software, following lean startup principles. We’re a team of six today, distributed between Boulder, Colorado, and Raleigh, North Carolina. But our humble beginnings go back to the summer of 2013 when Waffle started as a team of interns, exploring a new market segment for two months.

Dan: How has your management style evolved from when you started Waffle?

Andrew: To borrow from Reid Hoffman’s The Start-Up of You, I’m always iterating on myself. My management style changes every time I interact with different types of individuals, to meet them where they are and to make my team the most effective it can be together.

Recently I’ve been learning from Dan Pink’s ideas of Autonomy, Mastery, and Purpose, taught to me by some great leaders at Rally. What does it look like for you to discover the internal motivation for your team members? What drives them? These questions have caused me to change the way I interact with my team.

Dan: How do you run your one-on-one meetings?

Andrew: First rule of 1:1 meetings is to be consistent, and frequent. I do them weekly, for both remote and local team members. You start building trust and respect, one of our core values, when you put the time into it. Even when there aren’t any burning topics to discuss, it’s worth the investment of a 20-minute meeting every week.

As for the structure, I try to shy away from talking about the work we’re doing. In some cases that’s what we discuss; but talking about team dynamics, personal goals, frustrations and excitements — those are the things that help me discover what someone cares about and how to make our team more effective together.

Dan: What are some of your management suggestions for others?

Andrew: There’s a difference between technical leadership and people leadership. If you’re managing others, make that separate from your role of technical leadership. Yes, mentor others when you’re more experienced and capable at certain things. But, when I’m wearing my people management hat, my goal is to help someone discover what skills they want to nurture and how they can best contribute to the team’s shared vision.

Management ties closely to hiring. If you hire well, it changes how you manage. The question I ask myself when hiring someone is whether they currently are, or have the potential to be, better than me in some given role. If that’s true, then the role of leader becomes to uplift their skillsets or mentor them to fulfill their potential.

I always put the person first. It’s a careful balance between meeting business objectives and a person’s desires, so hire and fire based on building a team that can have that overlap. If you can encourage an individual based on their internal motivation, and help them achieve their personal goals, your team and business will benefit from their dedication and commitment.

Dan: Have you ever had a moment where you felt that you had completely failed as a manager? What have you learned from it?

Andrew: Sure. Several times come to mind when I’ve decided to take personal responsibility for a piece of work, because I’m not satisfied with the quality my team produced. It usually builds frustration and distrust, when I should work with the team to figure out how we can produce better quality work on the right schedule together. One way we work towards this is with a high focus on pairing, whether it be on code or non-dev work. It’s a great way to improve quality and share learning.

Dan: What challenges are you still figuring out as a manager?

Andrew: Realizing that everyone is unique, and not motivated by the same things. How do you create a shared vision that each person takes personal responsibility to accomplish?

Also, I’m always looking for ways to work with remote team members better. Travel helps; if you don’t see each other face-to-face often enough, you forget who they are as a person and it’s easy to jump to blame when things go wrong. It’s something I try to be aware of and work towards improving.

 

Andrew Homeyer
Categories: Companies

Running unit tests on iOS devices

Xebia Blog - Tue, 09/09/2014 - 10:48

When running a unit test target needing an entitlement (keychain access) it does not work out of the box on Xcode. You get some descriptive error in the console about a "missing entitlement". Everything works fine on the Simulator though.

Often this is a case of the executable bundle's code signature not begin valid anymore because a testing bundle was added/linked to the executable before deployment to the device. Easiest fix is to add a new "Run Script Build Phase" with the content:

codesign --verify --force --sign "$CODE_SIGN_IDENTITY" "$CODESIGNING_FOLDER_PATH"

codesign

Now try (cleaning and) running your unit tests again. Good chance it now works.

Categories: Companies

“Worum geht’s hier eigentlich?” – Mit der inneren Landkarte erfolgreich kommunizieren

Scrum 4 You - Tue, 09/09/2014 - 07:48

"Und das ist alles nur in meinem Kopf." Andreas Bourani

In kritischen Gesprächen stellt man sich häufig die Frage, was im Kopf des Gegenübers denn so vorgeht. Wie kommt der/die dazu, so aggressiv zu reagieren, sich trotzig zurückzuziehen, oder alles wieder mal ganz anders zu „sehen“ als ich. Keine Einigung in Sicht, aneinander vorbei reden. Eskalationsgefahr, Frust und du stehst auf dem Schlauch. Deinem Gegenüber aber geht es vielleicht ganz genauso. Wenn Du nicht jemand bist, der dem anderen schnell die Schuld an den Schwierigkeiten in die Schuhe schiebt, stellst Du Dir vielleicht einige (selbst-) kritische Fragen. Zumindest im Nachhinein: Was lief da schief? Was hat der/die andere wohl gedacht? Bin ich ihm/ihr ungewollt auf die Füße getreten? Was war dem/der wirklich wichtig? Und wie ging es mir eigentlich selbst in dem ganzen „Ping Pong“? Warum habe ich so und nicht anders reagiert, evtl. effektiver?

Kleines Beispiel Teil 1: Ein Teamleiter führt spontan zwischen “Tür und Angel” ein Gespräch mit einer Mitarbeiterin. Er kommuniziert seiner relativ neuen Mitarbeiterin sehr sachlich seine Einschätzung, dass ihre Leistung in der ersten Jahreshälfte bei Weitem nicht ausreichend gewesen sei (war schon vor einem Vierteljahr Thema), er aber die deutliche Steigerung im zweiten Halbjahr ganz super finde. Zwei Tage später erfährt er über eine andere Mitarbeiterin, dass die Kollegin ganz geknickt ist und sich von ihrer Führungskraft nicht richtig anerkannt fühlt. Evtl. herrscht Demotivationsgefahr. Er ist sehr erstaunt und kann sich die Reaktion nicht erklären, er wollte doch eigentlich nur loben und stärken.

Gelungene Kommunikation lebt vom gegenseitigen Verständnis. Das heißt, die jeweils vorhandenen subjektiven Informationen und Botschaften möglichst auf einen gemeinsamen Nenner zu bringen. Ein „gläserner Kopf“, die Möglichkeit des Blicks in die Gehirne der Gesprächspartner wäre hier sehr hilfreich, aber das bleibt ein frommer Wunsch. Oder vielleicht Menschenkenntnis? Obwohl, ich bin seit weit mehr als zwanzig Jahre ein durchaus erfolgreicher Coach, weiß aber bis heute nicht, ob ich eine besonders gute Menschenkenntnis habe. Eher die Fähigkeit, im direkten Kontakt schnell in etwa zu erfassen, was den anderen bewegt (oder bewegen könnte, auch Unausgesprochenes, ja Unbewusstes) und mich meinerseits klar auszudrücken, halbwegs eindeutige Botschaften zu senden. Statt Menschenkenntnis, Menschenerkenntnis. Mir hilft hier z.B. immer das Kommunikationsmodell der „inneren Landkarte“ als Orientierungsrahmen weiter. Es hilft mir, genau hinzuhören, genau hinzuschauen, genau wahrzunehmen.

Jeder hat seine inneren Landkartenmuster

In der Kommunikation geht es immer um einen ganzheitlichen Erfahrungsprozess. Beide Gesprächspartner sehen, hören, denken, fühlen und wollen in jedem Moment des Kommunikationsprozesses, ob ihnen das bewusst ist oder nicht. Die sinnlichen Wahrnehmungen werden an das Gehirn weitergeleitet, dort verarbeitet und als situative oder mehr oder weniger dauerhafte Erfahrungs- und Wissensinformationen abgespeichert.“ Diese „inneren Landkartenmuster“ konstruieren wesentliche Elemente der Realität, können jedoch niemals das gesamte Gebiet in seiner Komplexität abbilden. Sie wirken und aktualisieren sich in jedem Gesprächsmoment in höchst subjektiven, gefilterten und selektierten Abbildungen der Realität! Willst Du also etwas über Dein Gegenüber erfahren, erforsche seine „innere Landkarte“. Willst Du ihm/ihr Einblick in Deine „Welt“ geben, sprich über deine „innere Landkarte“. Wenn die Bilder, Worte, Gedanken, Gefühle, Intentionen für euch beide transparent und nachvollziehbar werden, entsteht gegenseitiges Verstehen und Verständnis.

compass-429772_1280

Welches sind nun hilfreiche Elemente der „inneren Landkarte“, um Kommunikation im Sinne von gegenseitigem Verständnis zu bereichern? Um nachvollziehen zu können warum andere so und nicht anders handeln, reagieren, agieren, brauchen wir Wahrnehmungen, Denken, Gefühle, Intentionen.

Unsere Wahrnehmungen in Kommunikationsprozessen sind die Informationen, die wir von außen aufnehmen – also das, was wir in einer Situation sehen, hören, spüren. Unsere Sinnesorgane liefern uns allerdings selektierte und gefilterte Informationen. Wir können überhaupt nur einen Bruchteil der möglichen externen Informationen aufnehmen und bewusst oder unbewusst speichern. Diese Impulse von außen treffen natürlich nicht auf ein „leeres Blatt“, sondern auf bewusste und unbewusste Informationen, die wir über die Jahre unserer Biographie gesammelt und gespeichert haben, und die sozusagen ein „beschriebenes Blatt“ ergeben.

Diese Kombination aus äußeren und inneren Informationen bestimmt nun folgerichtig unser Denken in Form von mehr oder weniger komplexen Assoziationen, Hypothesen, Deutungen, Phantasien etc. Gebe ich in einem meiner Kommunikationstrainings zehn Teilnehmern z.B. den Begriff Italien vor, erhalte ich spontan mindestens sieben unterschiedliche Assoziationen von Pizza, über Strand bis hin zu Amore? Die Wahrnehmungen und Gedanken aktivieren wiederum unsere Gefühlswelt oder umgekehrt. Und Gefühle haben eine immens hohe Bedeutung für so ziemlich alles, was uns bewegt und zum Handeln bringt. Allerdings, bevor wir handeln, schalten sich unsere Intentionen, unser Wollen und Wünschen zu. Und meist mit mehreren bewussten und unbewussten Optionen. Was ist mir wichtig, was erwarte ich, welche Optionen habe ich zur Auswahl. Jede Information von Bedeutung durchläuft diesen inneren Prozess und gestaltet ganz situativ unsere subjektive „innere Landkarte“. Kompliziert und oftmals schwierig wird das Ganze, da sich dabei sowohl bewusste als auch unbewusste Informationen vermischen.

Was könnte der Umgang mit dem Modell der „inneren Landkarte“ nun für unser Beispiel oben heißen?

Hätte der Teamleiter seine junge Mitarbeiterin genauer wahrgenommen, hätte er vielleicht einschätzen können, dass ihre „innere Landkarte“ allgemein oder auch situativ eher auf Kritik als auf Lob reagiert oder situativ reagiert hat und sie daher eher negative Hypothesen entwickelt. „Der ist unzufrieden mit mir, dem kann ich es nicht recht machen. Ich bin ihm zu langsam.” Damit wechselt sie schnell in einen negativen Gefühlszustand. Dies hätte er evtl.an ihrem Sprachmuster oder ihrer Körpersprache erkennen können. Also wäre es eventuell besser gewesen, den Hinweis auf das kritische erste halbe Jahr ganz wegzulassen und nur Anerkennung auszusprechen. Oder er hätte zuerst nachfragen können, wie sie selbst ihre Leistung über den entsprechenden Zeitraum einschätzt. Oder ob jetzt der richtige Zeitpunkt für ein teils kritisches Feedback ist. So hätte er Informationen über ihren aktuellen Zustand, ihre aktuelle „innere Landkarte“ bekommen. Die viel besprochene Empathie ist hier vielfach hilfreich, um das Feedback danach auszurichten – vielleicht sogar zu verschieben, weil es im Moment ihre Intention war, jetzt damit in Ruhe gelassen zu werden. Hätte er seine innere Landkarte gecheckt, hätte ihm sein Bauchgefühl einen stimmigen Hinweis gegeben. Denn Feedback ist vor allem dann effektiv, wenn es “richtig” ankommt und eine Perspektive im Sinne von Entwicklung anstößt.

Fazit: Seid in Euren Kommunikationsprozessen Forscher – Erforscher der „inneren Landkarten“ eurer Partner und Partnerinnen und eurer eigenen. Und nehmt Euch die Zeit, um mit Aufmerksamkeit und Empathie euch und den anderen Chancen zu geben, ein gemeinsames Verständnis für das nicht immer eindeutig und transparent Gesagte, aber Gemeinte, Gedachte, Gefühlte, Gewünschte zu erreichen.

Tipp: Geführte Expeditionen auf das Gebiet der inneren Landkarten bietet das Training “Discussion plus” - Informationen dazu gibt es hier

Related posts:

  1. Die wertvolle Meetingzeit sinnvoll nutzen, effektiv kommunizieren (Teil 2)
  2. Stürmische Zeiten – über den Umgang mit den eigenen Emotionen in Konflikten
  3. Mit dem Inneren Team Probleme lösen

Categories: Blogs

Knowledge Sharing


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