I was at the hairdresser yesterday. I’m not very particular about my hair but it was starting to look a bit like this. When I want it to be more like this guy to the left. The conversations at most hair dressers in Sweden is not very interested, mostly due to the fact that I’m not interested in hair. Particularly mine. So while I was seated in the chair thoughts from some discussions on prioritization and flow for a team at a client. Low WIP and flow are concepts that are well understood and often implemented as well at this particular client but the implications of such a strategy was interesting. And, oddly enough, I saw some great strategies implemented at my hair dresser. I sat down with some guys and we talked about Mob Programming, as they had read my blog post on the topic. Specifically we talked about the great...

I’m back from AgileSverige - the premier agile conference in Sweden (IMHO) and this year was no exception. Or rather it was - it was exceptionally great from where I sat. One of the talks that really got me thinking was about Mobprogramming by Tobbe Andeberg and Ville Svärd. Not the technique itself but rather the implications of such a team… Mobprogramming is easy to do; put your entire team in a room. Give them a single keyboard. Work together to solve the problem at hand. Then take the next. Then the next. And so on. It’s like pair programming but for an entire team. I’m not sure that a team would benefit by doing mobprogramming all the time but the concept got me thinking, thanks to the great presentation by Tobbe and Ville. What if… In this post I’ll share some ideas and thoughts that sprung from that presentation. No -...

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. MVP The thing from Lean startup that many...

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. Getting to know new people | | |:————————————————————————————:| | | | From http://redstarresume.wordpress.com | I have never been in a situation to hire someone - although I have done A LOT (50+) prospect interviews. This is a ridiculous situation; 1 hour with someone that I never have met and then asked if I...

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. Mindset vs practice What I bluntly failed to convey in the first post was the mindset aspect of it all. For me the difference in approaches was one of mindset in what we develop; do we write the code thinking that it will change or that this is the last time we ever...

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...

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. The Context injection feature (as it’s called in SpecFlow) is one of those “just works”-feature and you don’t have to think to...

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...

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 It’s really quite simple...