I’m having the opportunity to coach in an organization that isn’t used to agile practices. This is very refreshing and they are constantly challenging me and the ways that I think for granted. Quite often I find myself stumbling to explain practices that I for so long just have assumed that everyone was doing.

A couple of days ago I stumbled upon one of those. Here’s the dialogue that played out (as I remember it at least): Me: You are doing a lot of things at once here… Appointed Product Owner: Yes. But there’s a lot of things that we have promised them to finish by [date] Me: But why don’t you limit your work in process then? That will get stuff done faster and .. PO: Whatever do you mean? We cannot just limit the work. This [pointing to board] is what we are supposed to have done. We better do it now. As...

I’m working for Tradera right now and as I’ve blogged about before we have been splitting a big (40 people) team into smaller ones. Getting this to continue to work and the teams to be effective has been my challenging and very interesting task since then.

I can tell you that without great people that care - this would have been a lot harder. With people that cares you can even allow yourselves to try something, fail and change. That’s great news for someone like me - I fail a lot. And take great pride in doing so, as long as I learn from it.

In this post I thought I’ll describe a particular part of that process that I have had problems getting to work many times; the daily team sync, Scrum of Scrum or Syncro whatever you call it. We call it Daily Sync.

The problem

I have been playing around a bit with MongoDB for the first time of my life. It’s really a very nice experience and have a lot of the “just works”-feeling that I have started to get used to from frameworks like NancyFx and Simple.Data.

But when i pushed it to AppHarbor I ran into problems. That all had with me not reading stuff properly…

AppHarbor has a nice feature that replaces stuff in your .config files on deploy. That could be used for setting Production-environment values to your environment configuration. For example changing the connection string for a database.

The add-on for Mongo DB at AppHarbor has a nice article describing this in detail. But I read it quickly and put the connection string in the -node of the web.config.

It should be added as an . As the documentation clearly points out. So you want this:

...

I’ve built a small application. Just something I threw together with a friend during a hack-session at the client. (It’s a dot voting application and you can try it here, if it’s up :))

As we wanted something out there fast we built it with NancyFx and MongoDB (a first for me) and we host it on AppHarbor with continuous delivery via GitHub. Since all of these (saved Mongo) has served me well in the past I was very surprised when we ran into problem.

When a commit is pushed to AppHarbor the application is compiled and the test (if any) are run. That worked fine for us but then a stage is run that’s called “Site precompilation”.

That failed with the following error: > ``` > error...

At my current client we have split our teams into five smaller (8 people) team. I wrote about that process before, if you want read about that. One of the big concerns that people have had after the split is how we make sure that we don’t miss stuff that “fall between the chairs” for this teams. I think that’s an overstated problem but we sat down together and as always with great people that care - a good solution came out. This post shows our findings and I’ll try to unfold my thinking on why I thought that the problem is overstated as well. Since we’re now brushing on business critical strategies I need to keep this post fairly general, I’ll try my best to make it understandable.

The problem

My client now has five different teams that have separate backlogs and works towards realizing strategical important initiatives...

I have small children (5, 3 and 3 years old). During the winter half of the year that means that they are sick. A lot. No really: like you wouldn’t believe. Ok… like this: last year we had a cold outbreak in october and the next time all three of them was well again was in august. This means that I have from time to time spent some time at the hospital. No - you cannot go during the day since the kids mostly becomes much worse when they have lied down for a couple of hours. Like after sleeping for about 3 hours for example. The people working at SÖS children emergency room is amazing! I very rarely met people that isn’t cooperative and want to do their best, even 0430 in the night. Thanks a bunch for taking care of me and my kids when we...

Today I talked with someone that was about to create her first ever board, for a team. She was a bit worried as she couldn’t fit her normal workflow on the board. We sat down and discussed for a while and her reasoning and where she got it from made me both sad and upset at the same time.

In this blog post I’ll tell you more and then show why I thought that she had got some really bad advice.

Here’s how our dialog played out: Me: “What do you mean: I can’t fit our workflow on the board” She: “Well, it doesn’t fit within Scrum or agile. We have an old way of working, I guess it probably doesn’t work for us.” Me: “Really?! Tell me about it: what do you do first” She: “Ok - we have a Inbox or list of stuff, and then it’s Analytics,...

When I showed the code from the last post to a colleague (@HugoHaggmark), he remarked: Nice - but that no unit test. And he’s absolutely right.

A unit test should test a unit. The tests in the last post, and the test that Nancy.Testing allows us to easily write, flexes the whole stack of our application. In memory (which is super cool) but the full stack. That’s no unit test.

This can still be VERY useful and in this post I’ll show you how to put one of my favorite tools, SpecFlow, in front of what we wrote in the last post, to get an executable specification. Not only that - I’ll do it in a manner that let’s you swap it and hit the HTML page if you wanted to.

Read More

This is the fourth (oh my!) post in my series on Nancy.Testing. This time we will leave the Nancy.Testing specific stuff and let our gal meet a friend of mine: Simple.Data(.Testing). By marrying these kids together we will have a really cool full-stack-in-memory-testing-experience (FSIMTE it’s gonna be a thing!).

I’ll supply you with some background to Simple.Data and it’s (awesome) testing capabilities, and I probably have to explain the title of this blog post, but then it’s just code all the way down.

The other posts in the series can be found here:

1. Intro to testing with Nancy
2. The Configurable bootstrapper
3. The Browser and Response objects
4. Hat and shoeless testing with Simple.Data(this post)
5. SpecFlow and Nancy

Let’s dive right in a say hello to Simple.Data, if you haven’t met him already.

Simple.Data

Simple.Data is a...

I’m in the middle of writing a blog post series on Nancy.Testing and this bit me a bit (sorry, couldn’t resist myself).

I have written a lot about how to test web-responses and all the great stuff that comes with it, but totally forgot about view. I assumed that it “just worked”. And it does but… well read on. It’s really simple.

Keeping the story short - let’s cut to the code: There’s some really important settings to make here. If you don’t you’ll end up with an (as always in Nancy btw) excellent error message, something like this:

Nancy.ViewEngines.ViewNotFoundException: Unable to locate view ‘FariyTaleFigure’

Currently available view engine extensions: sshtml,html,htm,cshtml,vbhtml

Locations inspected: ,,,,,,,,views/SimpleDataModuleWithView/FariyTaleFigure-sv-SE,views/SimpleDataModuleWithView/FariyTaleFigure,SimpleDataModuleWithView/FariyTaleFigure-sv-SE,SimpleDataModuleWithView/FariyTaleFigure,views/FariyTaleFigure-sv-SE,views/FariyTaleFigure,FariyTaleFigure-sv-SE,FariyTaleFigure

Read More