Skip to content

Feed aggregator

Vertical Slice Test Fixtures for MediatR and ASP.NET Core

Jimmy Bogard - Mon, 10/24/2016 - 22:40

One of the nicest side effects of using MediatR is that my controllers become quite thin. Here’s a typical controller:

public class CourseController : Controller
    private readonly IMediator _mediator;

    public CourseController(IMediator mediator)
        _mediator = mediator;

    public async Task<IActionResult> Index(Index.Query query)
        var model = await _mediator.SendAsync(query);

        return View(model);

    public async Task<IActionResult> Details(Details.Query query)
        var model = await _mediator.SendAsync(query);

        return View(model);

    public ActionResult Create()
        return View();

    public IActionResult Create(Create.Command command)

        return this.RedirectToActionJson(nameof(Index));

    public async Task<IActionResult> Edit(Edit.Query query)
        var model = await _mediator.SendAsync(query);

        return View(model);

    public async Task<IActionResult> Edit(Edit.Command command)
        await _mediator.SendAsync(command);

        return this.RedirectToActionJson(nameof(Index));

    public async Task<IActionResult> Delete(Delete.Query query)
        var model = await _mediator.SendAsync(query);

        return View(model);

    public async Task<IActionResult> Delete(Delete.Command command)
        await _mediator.SendAsync(command);

        return this.RedirectToActionJson(nameof(Index));

Unit testing this controller is a tad pointless – I’d only do it if the controller actions were doing something interesting. With MediatR combined with CQRS, my application is modeled as a series of requests and responses, where my requests either represent a command or a query. In an actual HTTP request, I wrap my request in a transaction using an action filter, so the request looks something like:


The bulk of the work happens in my handler, of course. Now, in my projects, we have a fairly strict rule that all handlers need a test. But what kind of test should it be? At the very least, we want a test that executes our handlers as they would be used in a normal application. Since my handlers don’t have any real knowledge of the UI, they’re simple DTO-in, DTO-out handlers, I don’t need to worry about UI dependencies like controllers, filters and whatnot.

I do, however, want to build a test that goes just under the UI layer to execute the end-to-end behavior of my system. These are known as “subcutaneous tests”, and provide me with the greatest confidence that one of my vertical slices does indeed work. It’s the first test I write for a feature, and the last test to pass.

I need to make sure that my test properly matches “real world” usage of my system, which means that I’ll execute a series of transactions, one for the setup/execute/verify steps of my test:


The final piece is allowing my test to easily run these kinds of tests over and over again. To do so, I’ll combine a few tools at my disposal to ensure my tests run in a repeatable and predictable fashion.

Building the fixture

The baseline for my tests is known as a “fixture”, and what I’ll be building is a known starting state for my tests. There are a number of different environments I can do this in, but the basic idea are:

  • Reset the database before each test using Respawn to provide a known database starting state
  • Provide a fixture class that represents the known application starting state

I’ll show how to do this with xUnit, but the Fixie example is just as easy. First, I’ll need a known starting state for my fixture:

public class ContainerFixture
    private static readonly Checkpoint _checkpoint;
    private static readonly IServiceProvider _rootContainer;
    private static readonly IConfigurationRoot _configuration;
    private static readonly IServiceScopeFactory _scopeFactory;

    static ContainerFixture()
        var host = A.Fake<IHostingEnvironment>();

        A.CallTo(() => host.ContentRootPath).Returns(Directory.GetCurrentDirectory());

        var startup = new Startup(host);
        _configuration = startup.Configuration;
        var services = new ServiceCollection();
        _rootContainer = services.BuildServiceProvider();
        _scopeFactory = _rootContainer.GetService<IServiceScopeFactory>();
        _checkpoint = new Checkpoint();

I want to use the exact same startup configuration that I use in my actual application that I do in my tests. It’s important that my tests match as much as possible the runtime configuration of my system. Mismatches here can easily result in false positives in my tests. The only thing I have to fake out are my hosting environment. Unlike the integration testing available for ASP.NET Core, I won’t actually run a test server. I’m just running through the same configuration. I capture some of the output objects as fields, for ease of use later.

Next, on my fixture, I expose a method to reset the database (for later use):

public static void ResetCheckpoint()

I can now create an xUnit behavior to reset the database before every test:

public class ResetDatabaseAttribute : BeforeAfterTestAttribute
    public override void Before(MethodInfo methodUnderTest)

With xUnit, I have to decorate every test with this attribute. With Fixie, I don’t. In any case, now that I have my fixture, I can inject it with an IClassFixture interface:

public class EditTests : IClassFixture<SliceFixture>
    private readonly SliceFixture _fixture;

    public EditTests(SliceFixture fixture)
        _fixture = fixture;

With my fixture created, and a way to inject it into my tests, I can now use it in my tests.

Building setup/execute/verify fixture seams

In each of these steps, I want to make sure that I execute each of them in a committed transaction. This ensures that my test, as much as possible, matches the real world usage my application. In an actual system, the user clicks around, executing a series of transactions. In the case of editing an entity, the user first looks at a screen of an existing entity, POSTs a form, and then is redirected to a new page where they see the results of their action. I want to mimic this sort of flow in my tests as well.

First, I need a way to execute something against a DbContext as part of a transaction. I’ve already exposed methods on my DbContext to make it easier to manage a transaction, so I just need a way to do this through my fixture. The other thing I need to worry about is that with the built-in DI container with ASP.NET Core, I need to create a scope for scoped dependencies. That’s why I captured out that scope factory earlier. With the scope factory, it’s trivial to create a nice method to execute a scoped action:

public async Task ExecuteScopeAsync(Func<IServiceProvider, Task> action)
    using (var scope = _scopeFactory.CreateScope())
        var dbContext = scope.ServiceProvider.GetService<DirectoryContext>();


            await action(scope.ServiceProvider);

            await dbContext.CommitTransactionAsync();
        catch (Exception)

public Task ExecuteDbContextAsync(Func<DirectoryContext, Task> action)
    return ExecuteScopeAsync(sp => action(sp.GetService<SchoolContext>()));

The method takes function that accepts an IServiceProvider and returns a Task (so that your action can be async). For convenience sake, if you just need a DbContext, I also provide an overload that just works with that instance. With this in place, I can build out the setup portion of my test:

public async Task ShouldEditEmployee()
    var employee = new Employee
        Email = "",
        FirstName = "Jane",
        LastName = "Smith",
        Title = "Director",
        Office = Office.Austin,
        PhoneNumber = "512-555-4321",
        Username = "janesmith",
        HashedPassword = "1234567890"

    await _fixture.ExecuteDbContextAsync(async dbContext =>
        await dbContext.SaveChangesAsync();

I build out an entity, and in the context of a scope and transaction, save it out. I’m intentionally NOT reusing those scopes or DbContext objects across the different setup/execute/verify steps of my test, because that’s not what happens in my app! My actual application creates a distinct scope per operation, so I should do that too.

Next, for the execute step, this will involve sending a request to the Mediator. Again, as with my DbContext method, I’ll create a convenience method to make it easy to send a scoped request:

public async Task<TResponse> SendAsync<TResponse>(IAsyncRequest<TResponse> request)
    var response = default(TResponse);
    await ExecuteScopeAsync(async sp =>
        var mediator = sp.GetService<IMediator>();

        response = await mediator.SendAsync(request);
    return response;

Since my “mediator.SendAsync” executes inside of that scope, with a transaction, I can be confident that when the handler completes it’s pushed the results of that handler all the way down to the database. My test now can send a request fairly easily:

var command = new Edit.Command
    Id = employee.Id,
    Email = "",
    FirstName = "Jane2",
    LastName = "Smith2",
    Office = Office.Dallas,
    Title = "CEO",
    PhoneNumber = "512-555-9999"

await _fixture.SendAsync(command);

Finally, in my verify step, I can use the same scope-isolated ExecuteDbContextAsync method to start a new transaction to do my assertions against:

await _fixture.ExecuteDbContextAsync(async dbContext =>
    var found = await dbContext.Employees.FindAsync(employee.Id);


With the setup, execute, and verify steps each in their own isolated transaction and scope, I ensure that my vertical slice test matches as much as possible the flow of actual usage. And again, because I’m using MediatR, my test only knows how to send a request down and verify the result. There’s no coupling whatsoever of my test to the implementation details of the handler. It could use EF, NPoco, Dapper, sprocs, really anything.

Wrapping up

Most integration tests I see wrap the entire test in a transaction or scope of some sort. This can lead to pernicious false positives, as I’ve not made the full round trip that my application makes. With subcutaneous tests executing against vertical slices of my application, I’ve got the closest representation as possible without executing HTTP requests to how my application actually works.

One thing to note – the built-in DI container doesn’t allow you to alter the container after it’s built. With more robust containers like StructureMap, I’d along with that scope allow you to register mock/stub dependencies that only live for that scope (using the magic of nested containers).

If you want to see a full working example using Fixie, check out Contoso University Core.

Categories: Blogs

An Exit Strategy for the Agile Coach

Illustrated Agile - Len Lagestee - Mon, 10/24/2016 - 17:54

The End is Just the Beginning

My entire mission as a coach can be summed up by answering one question: How fast can I make myself no longer necessary? Well, it’s not as extreme as it sounds but from the first moment I begin coaching in an organization, I’m working to foster an environment where the momentum of change and growth is naturally generated from the inside. Every minute, every interaction and every conversation leads to this…a hopeful and proud coach who will need to leave so those I am helping can thrive on their own.

Why do I think about the end before we even begin? One word…


Many organizations are being profoundly challenged to keep up with the volume of change impacting them. Literally, they will not be able to compete unless they can discover new ways to thrive in this ever-changing environment and to quickly deliver the products their customers need. There is an urgent need to help them along this journey of reinvention and discovery.

But more importantly, inside of these challenged companies are many people who are struggling. Some to the point where they become physically ill. Seriously. There are many complex reasons for this but what we know is there is an urgent need to foster a culture where personal health, energy and growth are not sacrificed in this pursuit of quick results (or greater agility).

Beginning with The End

So, in walks a coach (like myself), or many coaches, into the dichotomy of improving speed and agility AND fostering a healthy and thriving culture with a mission to make things better. But how do we know the organization will be better when we leave than when we arrived?

With the “Measuring Impact” post, I discussed how to gauge personal impact of a coach and this post will discuss how to gauge the influence this impact has in creating an environment where long-lasting and meaningful change is starting to bring an organization back to life. Using Stephen Covey’s Second Habit  “Begin With The End in Mind” here are a few of the characteristics of a company I look for to determine if they are gaining agility and resilience:

Self-healing. Are people recognizing when behaviors and systems are not aligned to their new way of working together? Are people doing something about it when it’s not aligned? Are they thriving and getting stronger when challenges emerge?

Sustainable. Has the organization taken ownership of the change? Can they do this on their own? Is there enough internal will and energy to overwhelm existing silos, habits and dysfunctions?

Inventive. Is the company experimenting with new thinking around legacy systems, processes, hierarchies, social norms and behaviors?

Contagious. Could this movement grow naturally and virally throughout the organization without the influence of an outside coach? Can self-healing and inventiveness spread?

Production. Are people focused on delivering value as quickly as possible? Are people and teams often releasing small increments towards bigger goals?

With this rough idea for where we would like to end, our adventure begins. There is nothing earth-shattering about this journey, many coaches are doing much the same thing. But capturing this as a mental model helps me with a “you are here” map as we travel this long and winding road towards this target.

illustrated agile coach exit strategy


Arriving to that awkward and uncomfortable first day of school. A coach meets a welcoming but somewhat skeptical group. As I mentioned in the Impact post, coaching is about relationships and the focus on building new ones, so we start the first minute I arrive.

agile coach arrivingThroughout the first couple weeks I will be actively listening and learning, but what I’m really doing is looking for…catalysts.

People to anchor this change around. They are already modeling some of the behaviors. There are ones excited for the change. They feel the current pain and are ready to do something about it. Catalyts are always out there…perhaps they have just lost their voice so we may need to listen closely for them.

These early days connecting with our newly found catalysts is spent generating excitement and energy around the possibilities of what the “new world” could look like. How much connecting is enough? Just enough to build trust. Trust begins to open the door for what I may have to share.

Filling the Gaps

This means a period of sharing experiences and hopefully teaching new ideas. We can start by teaching our newly found catalysts but I will find any willing audience. Teach one team or many teams. Teach one agile coach teachingperson in a specific role or a whole department. Just start painting a picture of future possibilities with whoever is willing to listen.

What do we teach? The list is endless but we can start with:

  • New values and principles. This will lay the foundation for our new way of working together and how we will treat each other in our new culture. With leaders for example, I may start with the Principles of Servant Leadership.
  • New mental models for how effective organizations work based on these values and principles. Some of these models can be conceptual but this is where we begin to change the language of the organization.
  • New frameworks. This will introduce potential new roles, work products, activities, ceremonies.
  • New skills. The unique capabilities needed for our new framework and roles. For example, a product owner may need to learn how to do product discovery or write user stories.

How much teaching is enough? Just enough to get them started. There is nothing like experiencing this new way of working first hand so I spend as little time as possible here.

Being an Example

With just enough knowledge in hand to be dangerous, it’s time to get people experiencing for themselves how different things will be. During this time I may model certain activities by doing the work with them.

agile coach modelingFor example, if the product owner is learning how to write user stories or create a story map, I might do the first couple drafts or a version myself, but I keep the product owner extremely close. The goal is to hand the marker over as quickly as possible. Similar to teaching, it’s important not to linger here. Look for every opportunity to pass the baton but I’m always close by so my level of interaction remains high until people become comfortable with their new roles.

How much modeling is enough? Just enough to give them confidence to continue on their own.

Watching and Observing

After handing the reins over to a practitioner or a team of practitioners, it’s time to observe and assess their level of confidence. Are they growing into their new roles? Are they  “feeling” what Agile is about? Are the new values and principles being modeled coming to life? Is their new framework become a reality?

agile coach coachingWhile observing, I will offer coaching through real-time feedback but mostly I just encourage and support. As needed, we may jump back to teaching or modeling but this should begin to dwindle.

Over time, people should be performing in their roles without any help and teams should be well-functioning and healthy communities. If they are not, we’ll stay in the teaching, modeling, and coaching cycle for a little longer, just until old habits die and confidence in new habits is emerging.

How much coaching? Just enough to make it their own. There is a temptation to make things “perfect” and try to make sure absolute alignment to a framework or an approach. For me, as long as behaviors and activities are aligned to values and principles, they are free to experiment, create and make it their own.

Building Connections

Throughout the coaching journey, emphasis is placed on building sustainable connections throughout the organization. I was introduced to Communities of Practice as defined by Etienne Wenger from coaching peers a while back. These communities can be role-based or context-based but they become an important piece of my exit strategy.

agile coach connectingBuilding communities is an important element to sustainable change because, as Robert Greenleaf talks about in Servant Leadership, communities are not just a place for people to share, learn and grow, but it is a place of healing. When the communities become this place of healing, people begin to recognize they are in a safe place to experiment within the new framework and others care enough about them to help them gain ability and increase presence.

How much connecting? Just enough so people (everyone) begins to recognize they are in control of their own destiny.

The End is the Beginning

As my time begins to come to a close, I will intentionally shift towards becoming smaller to test how well the communities can thrive on its own. People may come to me with specific requests for suggestions or guidance. I’m always happy to share what I have but I’m mostly interested in challenging and motivating people and teams towards greater things.

agile coach leavingWith communities in place, I will try to be an instigator within the communities to help them have meaningful conversations about meaningful things. This mostly means challenging them to continue to learn from each other and to share with each other.

If I come back to an organization 6 months after leaving and I wanted to understand how well an organization is doing on their journey, I believe my first questions would be “How are the communities doing? Are they still a place of healing and growth?”

Most importantly, are the people I was coaching now doing the things I was doing – teaching, modeling, coaching, connecting – with each other? It should all come full circle. The end is the beginning.

How far do I go? Just far enough away so I am no longer needed but close enough so I can learn from those I have left.

As an end note, I am often asked how do you “scale agile.” My answer is always the same – scale the communities, scale the behaviors, scale around new values and principles. Only then, can you can slowly add the roles, queues and plumbing necessary to organize large efforts around a healthy and vibrant culture. More to come on this soon.

As all of us do, I am standing on the shoulders of giants and I have been blessed to learn from some of the best in the business including Si Alhir and many others. Their influence has affected my ability to coach beyond measure and I will always be grateful.

Sources: Conscious Agility by Si Alhir, Brad Barton, and Mark Ferraro Tribal Leadership by Dave Logan and John King Becoming a Catalyst - Scrum Master Edition

The post An Exit Strategy for the Agile Coach appeared first on Illustrated Agile.

Categories: Blogs

A day in the life of an mbot

Xebia Blog - Mon, 10/24/2016 - 17:44
Today, I managed to find a diary hidden on one of the mbots we have at the office. I couldn't see it in the user interface, but when I was doing some maintenance on the robot a simple 'ls -la' command in the terminal showed me this hidden content. It was so cute that I wouldn't
Categories: Companies

Technical Debt Management Future

Scrum Expert - Mon, 10/24/2016 - 16:39
Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. In a blog post published for the Software Engineering Institute (SEI), Robert Nord has provided the keys points discussed in a seminar Managing Technical Debt in Software Engineering, an event that discussed both the past and the future of managing technical debt. The International Workshop on Managing Technical Debt is organized every year since 2010. Robert Nord starts by describing the landscape of the technical debt issue, the visible and the invisible parts. The event tried to get a better definition of the core concepts of technical debt, producing a conceptual model. It produced also a vision on how to manage technical debt across different perspectives, like software economics or education. The conclusion of the author is that “The convergence of efforts on these multiple fronts is necessary to make software development technically and economically sustainable. Otherwise, the friction that slows down the machinery of software evolution will threaten the discipline’s ability to maintain the code base on which society depends.” Read the full blog post on
Categories: Communities

Are You A Tour Guide?

Manage Well - Tathagat Varma - Mon, 10/24/2016 - 07:40
A lot of us treat our careers, accomplishments, pet projects and interests in a similar manner - taking visitors to a museum or a monument without a tour guide! When you ask them to tell their high points on their last project, you feel as if they are reading the weather bulletin. When you ask them about their passions, you feel they are reading some text from a book on integral calculus.
Categories: Blogs


Agile Tools - Mon, 10/24/2016 - 06:03


Last week I was out on a hunt deep in the Canadian Rockies. It was remote – really remote. There was no cell service, no wi-fi, no cable TV, no Facebook. On this hunt, I was using the services of a guide. He was a guy in his early twenties – much younger than me. Despite his age, he was very accomplished and seemed to know the area pretty well. We had the usual agreement that you typically make with hunting guides – I pay you in advance for a great hunt, and the assumption is you bag the game you are after, or at least greatly increase the likelyhood of that happening by working with a guide. Implicit in that agreement is that there are no guarantees. Hunting is an unpredictable business (at least the good hunts are) and there is no way to know if you will get your quarry or not. These things aren’t cheap though, so there is a lot of money on the line.

So there is some very real pressure to perform in a situation like this. Expectations are quite high. We were three days into the hunt with no luck yet. That’s not a long time by any means, but the game wasn’t dropping in our lap either. We weren’t seeing much, and the doubts were starting to creep in.

So we set off early in the morning on day four, driving off into the darkness. We pulled over on a nondescript logging road and I followed my guide into the bush. We followed a trail for a while that meandered through meadows and around beaver ponds. We wove in and out of dense thickets of alder and spruce, pausing every once and a while to listen to the wildlife awakening around us. At some point my guide pointed off the trail and said that we should go check out a lake deep in the brush off to one side. I shrugged and followed. After all, he’s the guide. That’s what I was paying him to do. So into the thickets we went.

As we scrambled through the brush, climbing over logs and stumbling through willow thickets, I tried to focus on just keeping up. This young guide was having no difficulty at all moving through these obstacles with relative grace. Meanwhile, this particular middle aged guy seemed to be falling down as often as he was standing back up. I finally caught up with my guide, albeit wheezing mightily.

As we paused and looked around I realized that I had been so intently focused on keeping up with the guide that I had completely lost track of where I was. He had lead me on a merry little journey and I was now totally turned around and completely dependent on him. No problem, that’s why I hired a guide in the first place. He looked around, scuffed the ground with the toe of his boot, and we proceeded onward. Another round of scrambling, more spills and recoveries and 20 minutes later we stop again.

Still no lake.

Huh. This lake was proving to be elusive. With an abashed grin my guide looked at me and said, “We might be a little bit turned around.”

I nodded and told him I certainly couldn’t tell where we were. The sky was a perfectly even overcast grey that eliminated any clue regarding the direction the sun might be in. The nearby mountains, impressive as they were, were actually blocked from view by the thick press of small trees that surrounded us on all sides. So there were actually no major landmarks available to work from. Every direction offered the same information: more trees. My guide headed off again, and I followed.

Now I was starting to wonder, just what does, “We might be a little turned around” really mean? Is my guide lost? He doesn’t look lost. He seems like he knows what he’s doing. What about me? What if he is lost? Can I be of any help? After all, I’m a middle aged hunter who has spent more than a little time in the woods. I’ve been lost before. I know a practical thing or two about survival. I’ve watched the discovery channel. I’m no Bear Grylls, but I should be able to help out, right? So now I’m starting to pay attention to my surroundings. Now I’m starting to ask myself questions like: would I go this direction or is there a better route? Why are we taking this approach? What strategy should we be using to get oriented again.

We reach a clearing and my guide pauses once more. He looks at me with that grin again and says rather apologetically, “I got us completely turned around. I don’t know where the trail is. Or the lake.”


Well there it was. My guide had gotten us lost. My reply, “Yes, I’m afraid I’m lost too. I have no idea which direction the trail is in.” My guide checked in with me – asking if I had been lost in the woods before. I had been, so I wasn’t too freaked out. My mind was racing, I was definitely fully engaged now, but I was not too concerned. If anything I was worried that our little side hike was about to become a big adventure if we couldn’t find our way back to that that trail again.

I found myself in what I think of as “information gathering mode” at this point. What landmarks do I have? Well, we were standing in this little clearing. That’s a landmark, I could establish ordinal directions from the clearing (front, behind, left, right) and I could see a little rise nearby. That’s really all we could see. All other landmarks or clues regarding direction were completely absent. So the first thing that we did was go over and climb the small rise to see if we could see anything from the top.


More trees. So we back tracked in the direction that we had entered the meadow from. We encountered another small open spot in the trees. Now we had a little bit of a map in our heads with the meadow as our basis point. We continued to expand outward from the meadow, and soon, much to our mutual relief, we stumbled upon our original trail that we had begun from. Phew!

As we strolled back to the car I couldn’t help but reflect on the similarity of this experience with some of my recent consulting engagements. In many, hopefully obvious, ways a professional guide is very much like a paid coach or consultant. You have contracted with him to achieve a certain objective: transform your development organization, reach a performance goal, hit a financial target, or shoot a moose. It’s usually something pretty specific. It’s something that you might be able to do on your own, but hopefully by hiring the guide you reduce the risk of failure and bring some assurance of success. That’s what you hire them for. They don’t come with a crystal ball, so they can’t guarantee you success (transformations can fail for many good reasons, moose are fickle creatures that may or may not appear), but nevertheless, you hired them on the explicit premise that indeed they can deliver – make no mistake about that. In fact there is usually significant amounts of money on the line – enough money that you feel some urgency to see success, and the guide feels some urgency to deliver. So the contract we take is very similar.

[Lesson: make sure you know exactly what you are being paid to hunt (protip: “being agile” ain’t it)]

The curious thing for me was the experience from the client point of view. I realized that I gave up any of my own competence and ownership for the outcome to the guide the minute he started to do his job. I was a modestly experienced hunter and outdoorsman, and yet as soon as I hired a guide, I stopped paying attention to the landmarks around me and just started following in the footsteps of the guide in front of me. I’ve experienced this phenomena from the reverse perspective as a consultant in the boardroom too. I’ve had clients look at me and say (almost verbatim), “Tom, you’re the expert. You’ve done this many times before. How should we do X?” These are very capable and quite experienced managers who are putting aside their own expertise and asking for mine. Well, perhaps not putting aside their own experience, but let me put it like this: these are smart, experienced people who are treating me as if I have more experience than they do. Perhaps I do. Maybe I don’t. My guide on that hunt was literally half my age. Yet I was expecting him to lead me on a hunt and achieve a better outcome than someone with twice his age and experience. Admittedly, I didn’t have his experience in the local area, but nevertheless, I was deferring years of expertise to a guide who may or may not have had years of experience in this particular area. In fact, for all I know, I could have been his first client.

[Lesson: your guide may not know more than you do – don’t give up your expertise and competence and follow in their footsteps blindly. As the client, it’s important to keep your wits about you so that you can help assure a successful outcome.]

I’ve found that one of the harder things to do when getting lost is admitting that you are really lost. I remember clearly that feeling of denial as I was following my guide. “Really? We’re lost? Seriously? Are you kidding me? I left my compass in the car? AAaargh!” It’s hard for the client to admit they are lost to begin with, because it’s a threat to their perceived competence – you feel stupid and nobody likes that.

And what about the guide? When you are the guide, admitting that you are lost is crazy hard. Getting lost is probably the one thing the customer is paying you NOT to do. So there is a lot of pressure on a guide to never admit they are lost. But here’s the thing, as a guide you ARE being paid to find something. When the going gets tough you take chances. You look in obscure corners. You go places you haven’t gone before. You experiment. You take risks. You might get a little lost.

So I expect that of my guide. If we are not getting results, I want them to push the envelope a bit. I think many of us do. And with that comes some risk of getting lost. Similarly, organizational transformation can be very disorienting too. As a consultant, it’s terribly easy to get lost in the bewildering forest of people, politics, and technology that you typically find in any given organization of even modest complexity. Let’s face it: there are days when I’m lucky if I can find the restroom.

So I really appreciated the guides honesty with me when he realized that he was lost. That only increased my trust in his ability. As a result, I didn’t get frustrated or upset. I just wanted to get back on track as quickly as possible.

[Lesson: if your guide admits he is lost, it’s a positive reflection of character. Help them get back on track so that you can both be successful again quickly]

The other thing that I noticed was that my guide was pacing himself according to my own abilities. This kid was a veritable mountain goat. He was easily capable of climbing a ridge covered in dense thickets and downed logs without even breaking a sweat. Following him, I felt like I was following an obstacle course designed for American Ninja. He’d be there at the top of the ridge, waiting patiently every time. He was capable of doing much more, but he paced himself according to my own capabilities.

Given his youth and individual capability, he might actually have been able to deliver on the hunt much faster on his own. But when he’s bringing along some middle-aged desk jockey, things are just going to have to go at a slower pace. That’s what a good guide does – he moves at the client’s pace. Maybe he urges them on a bit, but there is a limit. The client may even have unreasonable expectations. For instance, I might like to finish the hunt in a single day, but I’m probably not capable of the physical demands necessary to do that.

In a similar fashion, as a consultant there have been some clients I’ve had who’ve expressed a desire to speed up their transformation. That’s fine unless I’m looking at an organization that is the equivalent of a 80 year old: with slow, brittle processes, a staff resistant to change, riddled with dysfunction. If you try and get them to change too quickly, you risk an organizational heart attack. So you pace things accordingly, because you want them a little winded, not wiped out and gasping for air.

[Lesson: a good guide paces themselves according to the clients capabilities. That implies that the abilities of the client – not the guide, play a large role, perhaps the most important one, in the speed of achieving the objective. A good guide recognizes those limitations and sets expectations accordingly.]

All things considered, it all ended up working out very well. Experiences like this always leave me with a great deal of respect for guides, whether they work in the woods or the silicon jungle. They work extraordinarily hard to try and deliver success for their clients. This guide was putting in nearly 16 hour days with work that was both physically and intellectually demanding. That’s got to be comparable to the amount of time your average millennial in silicon valley puts in behind a desk. OK, I take that back. Maybe it’s not comparable – this guy was working a LOT harder than that. And he had to keep a geek like me entertained. I was really impressed at the kind of dedication he had to the work he was doing. You really have to love it to work that hard. The hunt was a success, and afterward I left feeling like I had a really great guide who had taught me a valuable lesson about being a much better guide for my clients.

Filed under: Agile Tagged: client, consulting, customer, guide, leading, Lost
Categories: Blogs

New Case Study: SAFe at AstraZeneca—Expediting Time-to-Value Delivery

Agile Product Owner - Mon, 10/24/2016 - 03:29

“We’re delivering faster with greater quality and less manpower—resulting in substantial financial benefits from the teams that have adopted Agile to date. We expect to double our adoption of Agile this year.”
—Patty Sheehan, AZ Agile Cultural Change Lead and Coach


Change doesn’t come easily for many organizations, especially at global, highly-regulated enterprises. But in our latest case study, AstraZeneca proves that it’s possible and well worth the effort.

When AstraZeneca (AZ) began implementing SAFe, it created a network of Agile Culture Leaders focused on securing executive-level buy-in. They also discussed culture change in every SAFe course.

To align governance, procurement and regulatory processes with SAFe, leaders defined an approach with the internal Quality Management group, allowing AZ Agile teams to deliver validated software solutions that support regulatory requirements. Additionally, the legal and procurement teams at AZ are now revising the contractual arrangements and procurement processes to align with SAFe.

Finally, PI planning events were crucial to syncing large, offshore teams. AZ held some PI planning events onsite while others used video conferencing, with a requirement for face-to-face planning at the launch of a new Agile Release Train.

To date, AstraZeneca has come a long way in its SAFe journey:

• Twenty large teams have adopted Agile
• Over 1,000 staff members have been trained and supported through a robust coaching regime
• Agile delivered substantial financial benefits in the first year
• Teams expedited time-to-value delivery
• Team sizes are reduced
• Quality of outputs improved over previous solutions
• The company applied an organizational change management approach
• An outsource and offshore model is aligned with SAFe

You can view the study here.

Many thanks to Patty Sheehan, Agile Cultural Change Lead and Coach at Astra Zeneca, and Justine Johnston of PA Consulting for sharing their SAFe story with us.

Stay SAFe,


Categories: Blogs

The Simple Leader: Respect

Evolving Excellence - Sun, 10/23/2016 - 10:32

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen

If you want to be respected, you must respect yourself.
– Spanish Proverb

Respect for people is one of the two pillars of Lean. However, “people” doesn’t just mean the people that report to you, but everyone else in your organization, including your team, your boss, your customers, your suppliers, your community, and your- self. The “respect for people” concept from Toyota is more accurately translated as “respect for humanity.”

To respect people, you must take into account that there is a brain attached to each pair of hands in your company. In addition to the cost of the pair of hands that is represented on traditional financial statements, those brains hold tremendous value. As a leader, your job is to figure out what environment, both physical and organizational, is necessary to optimize and leverage that value. You increase the value by soliciting and using people’s ideas, creativity, experience, and knowledge.

When dealing with people, don’t forget that respect can also mean being up-front with
them, in an appropriate manner, giving them areas for improvement, or even letting the person know he or she is not the right fit for a position. Remember to be respectful in how you give such feedback, however. One of my early bosses had a favorite saying: “Are you incapable, or just incompetent?” When he offered me that choice, I didn’t know what to say. But I did know I wouldn’t grow in such an environment, so I soon left to join a different company on the other side of the country. (The man treated everyone, high performers and otherwise, with such disdain, and wondered why his group had such high—and expensive—turnover.)

We must also remember to treat people with dignity. A couple years ago, I read an article on the power of calling people by their names. Using someone’s name creates a connection that can be very powerful. Instead of yelling “hey you!” to someone, learn their name and use it to address them. When you write emails, greet them before launching into the subject. Do the same when talking in person and on the phone. Great leaders are able to connect with their workers by taking a little time to acknowledge them first, before getting down to business.

Categories: Blogs

3 Reasons to Be Excited About Agile This Fall!

BigVisible Solutions :: An Agile Company - Fri, 10/21/2016 - 18:00


The trees changing color is usually top of the list of reasons to love fall, while crummy weather is right there are the bottom. Luckily we have three more reasons for you to love this fall (and to get out of bed when the rain and clouds sap your motivation)!

  1. SAFe Partner Summit (Denver, CO)
  2. Southern Fried Agile (Charlotte, NC)
  3. Lean Startup Week 2016 Livestream (Chicago, IL)

That means more of your favorite Agile Amped podcasts!

SAFe Summit 2016

We’re excited our partnership with Scaled Agile has continued to grow and this year we will be capturing all the action at the SAFe Summit conference! This conference aims to provide a place where SAFe practitioners, coaches and thought leaders can share their knowledge and thus create a richer experience for the entire industry. Agile Amped will sit down with many of the speakers and event panelist, so if you’ve got SAFe on the brain, don’t forget to subscribe (below)! Follow the action with #SAFeSummit and @ScaledAgile!

Southern Fried Agile

What’s not to love about an Agile conference that spends the day helping Agilists connect and share knowledge fried chicken? Agile Amped will be on site at Southern Fried Agile, speaking to the industry’s leading thinkers including several of our own consultants. Here’s what you can expect from our speakers:

The list of speakers features many new voices as well as some crowd-pleasers that have already graced the Agile Amped podcast, including Christopher Avery, Kent Graziano and keynote Esther Derby. Don’t forget to check out @sthnfriedagile to see what’s happening before, during and after the event!

Lean Startup Week 2016 Livestream

The first week of November is Lean Startup Week in San Francisco, and this year SolutionsIQ is partnering with Lean Startup Week and WeWork to bring a livestream experience to Chicago! Attendees will be able to watch the full livestream from the conference, ask SolutionsIQ consultants and coaches for advice on Lean Startup, enterprise innovation and Agile, and then tour the WeWork facilities. Lunch and beer is included with your free registration! But be quick about it: space is limited and it’s already filling up.

Learn More or Register

If that’s not enough reason, stay tuned for an invitation to our upcoming webinar on the mysterious “innovation colonies”!


The post 3 Reasons to Be Excited About Agile This Fall! appeared first on SolutionsIQ.

Categories: Companies

Leading to Real Agility – Leader Responsibilities

Learn more about transforming people, process and culture with the Real Agility Program

Leading an organization to Real Agility is a complex and difficult task.  However, the core responsibilities of leaders attempting this are simple to describe.  This video introduces the three core responsibilities of the senior leadership team as they lead their organization to Real Agility.

The video presents three core responsibilities:

  1. Communicating the vision for change
  2. Leading by example
  3. Changing the organization

Future videos in the series will elaborate on these three core responsibilities.

Real Agility References

Here are some additional references about how leaders can help their organizations move towards Real Agility:

Please subscribe to our YouTube channel to receive notifications when each new video is published! (There are 15 more videos coming in this series, and more beyond that on other topics!)  You can also find the summary article that helps you find all the videos and additional references here: Leading to Real Agility – Introduction.

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BESTEIG Real Agility logo


Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Leading to Real Agility – Leader Responsibilities appeared first on Agile Advice.

Categories: Blogs

Contoso University updated to ASP.NET Core

Jimmy Bogard - Fri, 10/21/2016 - 17:33

I pushed out a new repository, Contoso University Core, that updated my “how we do MVC” sample app to ASP.NET Core. It’s still on full .NET framework, but I also plan to push out a .NET Core version as well. In this, you can find usages of:

It uses all of the latest packages I’ve built out for the OSS I use, developed for ASP.NET Core applications. Here’s the Startup, for example:

public void ConfigureServices(IServiceCollection services)
    // Add framework services.
    services.AddMvc(opt =>
            opt.Conventions.Add(new FeatureConvention());
            opt.ModelBinderProviders.Insert(0, new EntityModelBinderProvider());
        .AddRazorOptions(options =>
            // {0} - Action Name
            // {1} - Controller Name
            // {2} - Area Name
            // {3} - Feature Name
            // Replace normal view location entirely
            options.ViewLocationExpanders.Add(new FeatureViewLocationExpander());
        .AddFluentValidation(cfg => { cfg.RegisterValidatorsFromAssemblyContaining<Startup>(); });

    services.AddScoped(_ => new SchoolContext(Configuration["Data:DefaultConnection:ConnectionString"]));
    services.AddHtmlTags(new TagConventions());

Still missing are unit/integration tests, that’s next. Enjoy!

Categories: Blogs

Targetprocess v.3.10.2: Redesigned Projects-Teams Selector, Batch Add Comment

TargetProcess - Edge of Chaos Blog - Fri, 10/21/2016 - 16:50
Redesigned Projects-Teams Selector

We expect this release to reduce the system's complexity quite a bit, as we have redesigned the projects-teams selector. Previously, your selection of projects and teams would be globally applied for all views that you opened. This caused some confusion, especially when users with different projects-teams selections collaborated on public views.

To remedy this, we've made the projects-teams selector a part of each view's settings. All users will now see views with a predefined projects-teams selection applied. This predefined selection is set by the view's owner.

You can still look at any view through any projects-teams context that you want by clicking on the selector. When you change the selection for a view, the selector will be highlighted yellow, like this:


This highlighting attracts your attention to the fact that you have changed the projects-teams selection for this view, and so you are looking at a different set of data than other users. There is a handy 'revert' option to quickly sync the view's projects and teams back to its public settings.

For more information, see our dedicated blogpost on this change, or check out the Projects-Teams Selector article in our User Guide.

Batch Add Comment

You will now be able to batch-add brief comments from the Batch Actions Panel to a group of selected items on a Board view.

batch add comment

Minor Features
  • Modified Date as lanes
  • Emojis in the Tags lane
  • Batch update of checkbox custom fields
  • Epics added to the Process Control chart, Cycle Time Distribution and Relations network diagram
Fixed Bugs
  • 'Open in new tab' doesn't work properly in Safari Version 10.0 for MacOS
  • Login page sometimes did not accept valid emails
Categories: Companies

Projects-Teams selector redesign

TargetProcess - Edge of Chaos Blog - Fri, 10/21/2016 - 16:44

Our upcoming release (v.3.10.2) will contain a complete redesign of the projects-teams selector. To reduce complexity, we've made the selector a part of views (rather than a global setting found on the top bar). It will now be clear if a view is displaying data from the default project-teams selection made by the owner of the view, or data from the projects and teams selected by you.

Old version:


New version:


We made these changes to solve two main issues. The first is that data in views would unexpectedly change because of unintended projects-teams selections. This happened when you navigated through views with and without predefined selections by the view owners. It was sometimes unclear why certain projects and teams were displayed in certain views.

The second issue would occur when users collaborated on views. It was often unclear for users that they were seeing different data than their teammates because they had set a different selection of projects and teams. To fix this, we've made the projects-teams selector as straightforward as we can. You will now always know what data you're looking at on the view and why.

By default, a view will show the selection set by the view owner in View Setup. 

You can still make a view display data from any projects and teams that you need to see. When you modify the set of projects and teams shown on the view, the selector will be highlighted.


These changes are applied only for you; other users will still see the view with the predefined projects and teams selected by the view's owner. 

Once you set projects and teams for a view, your selection will be saved for that view. You can easily revert back to the predefined selection by clicking the revert button.


If the view's owner hasn't set a projects-teams selection for the view, then the revert action will not work because there is nothing to revert to.

For more information, visit the Project and Teams Selector article in our User Guide.

Categories: Companies

Being An Agile Security Officer

Xebia Blog - Fri, 10/21/2016 - 14:31
Whenever I give a presentation, training, or just talk to security teams, it becomes clear that over the years a gap has been created between application security and development. A gap we created consciously and with intent and that became painfully visible with the introduction of Agile and DevOps. Suddenly exhaustive information security policies with
Categories: Companies

Agile Testing Sketchnote

Growing Agile - Fri, 10/21/2016 - 13:54
Categories: Companies

Working Remotely in an Agile Team

TV Agile - Fri, 10/21/2016 - 10:20
This is story of how adopting Agile practices helped Olly Brand work remotely from Cornwall as part of a global team at IBM. Lessons learned on the journey adopting Agile. How to use Agile methods to deliver across different time zones, working in a global market place. In a world that requires us to be […]
Categories: Blogs

The Geek Guide to Leading Teams

Scrum Expert - Fri, 10/21/2016 - 10:14
This presentation uncovers a number of key principles and useful tools to help you better skills as a geek who leads Agile and Scrum teams. The most challenging aspects to software development are always the people issues. Picking the right data structures, finding the right testing approaches are simple compared to building an effective software team. Most organisations fail to support developer promoted into technical leadership roles so where do you go to uncover the secret skills behind this important role. Watch this video to discover practical tips for leading technical teams. Video producer: In this talk, we will
Categories: Communities

Technical Debt Is A Systemic Problem, Not A Personal Failing

NetObjectives - Fri, 10/21/2016 - 09:22
One of the underlying themes of the work we do at Net Objectives is, Agile by itself is not enough. Agile needs something that connects the transformation of the team to the activities and concerns of the larger organization. Nowhere is that more clear than technical debt. You need to nestle Agile within a larger operational approach, such as Lean, to deal effectively with a problem like...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

The Strategic Planning Cycle

Agile Elements - Fri, 10/21/2016 - 06:07

Some think of strategic planning as a one time or every 3 years exercise. In my experience, it is most beneficial to think about it as a yearly cycle.

This time of year is when many organizations refresh strategic objectives and tune longer term plans. Finishing strategic planning efforts by October allows for those deliverables to feed into the annual planning cycle and prevents conflict between the two efforts. I like to think of strategic planning as an on-going process that is evaluated and refined every quarter, but also has a specific focus each quarter. A typical cycle is:

Q1 – Detail Department Plans (focus on Product Road-map and Sales Enablement)

Q2 – Talent Management (MBO’s, Talent evaluations, Comp review, Key resource needs)

Q3 – Strategic Planning (3-5 yr SWOT, Themes, Objectives, Metrics, Goals, Initiatives)

Q4 – Annual Operations Budget and Staffing

Using a strategic planning cycle ensures the strategy stays relevant and gets translated into execution more effectively.


Categories: Blogs

Focus – my keynote at AgileByExample, Warsaw

Henrik Kniberg's blog - Thu, 10/20/2016 - 09:52

Here is my slide (yes, it’s just one slide) from my keynote at AgileByExample in Warsaw. And a video of the talk. Scroll down for a written summary.


And a couple of photos:

Flow demo

A live demo of flow vs resource utilization. Assisted by my two youngest kids

Categories: Blogs

Knowledge Sharing

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