MVP is not another word for iterations - it's for learning

In recent years the Lean Startup movement has really taken off. For a great reason as well. It's a really appealing and excellent described framework for how to get validated learning of your startup idea fast.  For me as a Lean-dude it all sounds very nice and fits nicely into my current understanding and beliefs.

But as always ideas like the ones presented in Lean Startup will be stolen, then tweaked "a bit" and then finally declared unsuitable for the things that it didn't was intended to solve in the first place. I've seen it again and again; agile, scrum, specification by example is just a couple of examples that comes out top of mind.

In this post I'll share some things that I've been thinking about around this recently. If I'm wrong about these things I look forward to your comments and further education on the topic.

Let's do something instead!

I'm surrounded by brilliant minds at work. Both at my company (Aptitud), at my clients and in my community. They make me think a lot and quite clearly thinks a lot themselves too.

But sometimes I think we think too much (cannot wait for the reaction to that contradictive sentence :)) - and we should do things instead. It's in doing we learn and see how stuff work out and how well our hypothesis stands up to the reality that we throw them into.

Let me give you a few ... well examples and ideas that have formed my thinking around this.

Part time coaching - some practices that helped me

I'm right now doing two part-time coaching gigs and that has proved tricky before. I've lost track of what I've been doing and where I was in my tasks. This time around I've managed to gain a bit more control through the use of two simple tools that helped me and my clients a lot.

The two gigs are quite different:

• I'm working as an agile coach for Tradera and helping out in 4 different teams, as well as across the board on the organizational-level (yes, that Marcus going management right there - beware!:)). I work for Tradera 3 days a week.
• At Skandia (big Swedish insurance company) I'm acting agile coach in a non-agile environment and trying to helping them to flow stuff faster through their process. This gig is one day a week.

Are you coding for change or stability - the followup post

In my last post I related two stories that I've been a part of and that got me thinking about what we (or me at least) code for: change or stability.

The post got attention (amazing attention for a small time blogger like me, actually almost afraid of writing now :S) and quite a lot of questions was posed. These of course got me thinking even more and I realized that I needed to follow up on the post. So here it is: some thoughts (and some answers) to questions and arguments I've had during the last week.

Are you coding for change or for stability?

Let me tell you a story: when I was in university I took an "advanced" object oriented programming course. This was my first exposure to the topic and I was lost big time. The course was taught in SmallTalk had a very different format; the first day we got an assignment from the professor that ran throughout the 4 week course.

We were very excited since we were going to write a game. An old-school text-input adventure game a la Zork. We teamed up three people in groups and went to the professor smalled crammed room. Here we got the instructions on a single sheet of paper. We almost ran out of there.

Just as we reached the door of the room he called us back (I'm sure he had time that call to perfection):

"Oh yeah, almost forgot. Two weeks from now I will come by and change something fundamental of that game description. Continue as you were."

Context injection of driver object in SpecFlow

SpecFlow is a wonderful tool. With a lot of hidden gems inside of it. I have been using and coding on it now for about 4 years and still I often forget about features and extension points that Gaspar and the community has put in there.

For example: did you know that there's an inversion of control framework built right into SpecFlow? Now you do and in this post I wanted to show you one way that you could use that feature to make your step definitions more maintainable.

I found this feature (again, i had heard about it before) when Gaspar mentioned it too me after my presentation at CukeUp 2013 and the usage is part of "Pushing the HOW down" which I wrote at length on before.

Cucumber / SpecFlow pro tip: push HOW down

I've just attended my first ever CukeUp conference, that is given by Skillsmatter each year. It's organized by Aslak Hellesoy that created Cucumber five years ago. It attracts a nice audience and community that share a lot of interest with me. For me it was extra fun to meet some of my heros and friends that I've followed and interacted with for quite some time (Matt Wynne and Gaspar Nagy to mention a few).

As always at conferences the learning is plentiful, even though my focus and nervousness was at my talk for a few hours. I especially like Matt Wynnes talk on Cucumber Pro Tips. There's two excellent books (The Cucumber Book and Cucumber recipes) that Matt and friends has written that contains loads of tips and pragmatic hands-on descriptions for any Cucumber user. His talk was an extract from the books.

The biggest thing that stuck in my mind was: push HOW down. He has been talking about that before (very funny here) to great effect in this excellent talk called "BDD - as it was meant to be done!". That point was then something that run through almost every talk (including my in fact) on the conference. At least the once that I heard so far.

Limit WIP doesn't mean doing less

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 fast as we can.

There's two things that I have missed to explain here; the use of WIP (what is it good for) and why they (the stakeholders) shouldn't and probably doesn't care about your WIP.

Daily Sync for five teams - and get something out of it

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.

Get MongoDB running on AppHarbour - it's an AppSetting thing

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, Nancy and the Could not load file or assembly 'Nancy.ViewEngines.Razor.BuildProviders' error

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.

"Between the chairs" some thoughts on backlogs and things outside them

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.

Suggested visualization for the SÖS Children Emergency

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 have been in dire straits.

However ... I miss some visualizations on my waiting progress. Last time I was there I started to think and I came up with something really, really simple that could help me as a patient a lot. Who knows - the nurses and doctors might find it useful too.

In this blog post I wanted to share my thoughts, from a pure client perspective. I known nothing about the inner workings and process at the ER, other than having been there about 15 times the last 2 years.

The "I'm not allowed to do columns like that"-problem

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.

Nancy.Testing - executable specifications through the full stack, in memory

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.

As the tradition calls - let's look in wonder at Nancy's silhouette.
If you came here and want to read up on what we have spoken about so far, 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
5. SpecFlow and Nancy(this post)

In this post I'll introduce you, short - very short, to Specification by example and SpecFlow and some practices that makes automating your application ... bearable   

Nancy.Testing - no hat, no shoes with Simple.Data

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. 

Nancy.Testing - testing (razor) views

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.

Nancy.Testing - test-dialogues with Requests and Response

This is the third post in my series on Nancy.Testing. It will focus a lot of the Browser and the Response object. Together with the Browser (and it's ConfigurableBootstrapper) these objects makes up the entirety of the Nancy.TestingFramework.

Let's do the logo thing again, shall we?

The other posts can be found here:

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

By now you're probably just looking for the code so let's dive right in.

www.marcusoft.net - 800 posts and counting

I've just published my 800th post!

Can't really understand that. I know that some of them haven't been all that great but there's some nuggets of information in there. At least for me.

That's how I started to blog: to make myself write stuff down to remember and formalize my knowledge.

800 posts, six years, 163 000 pageviews. That's not a lot for many blogs out there but it means a lot to me.

Thank you for reading my blog. Even though I started to write it for myself - comments and reactions is  what kept me going on for 6 years! I cannot promise 6 more but right now I'm on a roll. 

Pickles - generate SpecFlow documentation from MsBuild and PowerShell

If your doing specification by example or BDD you will soon realize that the tooling still points towards developers. WIth that I mean, that Cucumber and SpecFlow allows you to write your (executable) specifications in plain text, but you still check it into the source repository. This is of course a good thing since you'd want to version the specification with your code - but it also effectively hides it and keeps the spec out of reach for any non-developing member of the team.

Make no mistake here: the .feature-file is the master and original. That's how it should be since it's versioned together with the code. But we want everyone in the team to be able to read the specifications and see the test result easily. So we generate documentation off the .feature-files.

Pickles is a nice OSS framework that helps you solve this problem by generating documentation in a variety of formats from your specifications. This can be done in build scripts to keep the site up to date.

In this blog post I'll show you two easy ways to include the generation of an HTML-site from your features with Pickles: via PowerShell and via MSBuild. Let's start with the latter since I know that the best.

If you want to skip ahead you can download my code here.