A fantastic thing has happened to me.

A couple of months ago I got the strangest mail sent to me. It was from Manning Publications and asked me if I would be so kind as to phone a person called Michael there. I understood it as if Manning was going to launch a book on Kanban and if I could come with some ideas or suggestions on the proposed content.

Mike and I talked for awhile. What have I done around Kanban? Could I please describe it in 5 minutes for a total newbie (not that Mike was that :))? What would I see in a book on Kanban? questions like that for about 45 minutes.

Then - all of a sudden - the final question (just about the time as my twins were tearing down the door and entering the room, I might add):

Would I...

Right now I’m doing a lot of education and presentations. I find that the doesn’t supply me with as much blogging material sadly. But I have had a small nagging thought about a blog post I feel needs to be written. Here it is:

There’s a lot of buzz around Kanban as you sure know and one way you really see that is that a lot of teams are taking up Kanban… and sadly misuse it. Just as with many other methodologies I think that people interpret what they think is correct without really taking the time to learn the theory behind it. I have a hunch that we will hear about Kan-but in the near future. This is both sad and very strange as well; Kanban in itself is really super simple. In fact you could sum it up as Janice Linden-Reed does on the...

Right now I’m very impressed with the way that two my colleagues (Hugo Häggmark and Tobias Karlsson) has introduced BDD or rather Specification by example at their client. They have in a very short time gone from people not speaking to each other (analysts and developers) to collaboration around the scenarios of their specifications and demos running from those specs. I’m officially impressed! Another colleague even threw together a speech engine integration that speak the SpecFlow features as they are run. Silly but …Coolness! I got a very interesting and I think common question from Hugo that I thought I’ll share here, since the answer might be useful to others.

Hugo asked me if I update my specifications with any bugs found later on. Or if not – where do I keep them?

The reason for adding bugs in the same .feature file...

I haven’t done “proper” Scrum in quite some time now, with the Kanban-ery going on. So when I got thrown into a sprint planning meeting the other day I was happy to see that I still remember how I used to do my sprint planning. Thought I write it down if I need to get back to it later.

I will probably upset some people as well… and might even get some feedback that can help me improve.

And of course, this is not my own thoughts – I’ve picked up some tricks here and there over the years and probably forgot about as many. Thanks everybody that I’ve learned from, especially Öystein Stave who helped me find my lost excel-sheet that we created together a long time ago.

Time boxing and the three constraints

As everything in Scrum I plan sprints as a time box....

At my current client I have been asked to suggest some KPI’s (that’s Key Performance Indicators for us non-business people). This is a bit scary for me of two reasons – I don’t feel to at home with the task and I don’t feel at easy with many of the KPI’s that I hear is being used.

Let’s read up on them first and then I’ll talk about the one I suggested and why.

What is a KPI anyway?

From the Wikipedia page we learn that it’s a “type of performance measurement” and that “KPIs are commonly used by an organization to evaluate its success”.

Ok – later down they actually had a section for IT that cited commonly used KPI’s as; Availability, Mean time between failure, Mean time to repair, Unplanned availability.

So far it sounded alright and sound to me. But...

I have been talking about Kanban a lot the last couple of years. Sometimes to the point where I think that I must have talked a hole in the head of the those closest to me. But from time to time you get great response, for example;

Anna (an Avega Group colleague) attended one of my Kanban introductions and became inspired. She started to implement parts of the practices I’ve suggested at her client and soon ran into some questions. She sent me an email and asked for my suggestions on how to act in certain situations.

I of course answered but also felt the questions was not only good, they were also common. So I thought that I’ll share my suggestions here. Bear in mind, as I also told Anna, that Kanban is really just a couple of simple rules – how you apply them...

I have been working as a contractor for the better part of my career. Due to the nature of consultancy and the IT-business in general I’ve seen a lot of colleagues come and go. Brilliant people in many cases, people that you miss so bad when they have quit. So when the ubiquitous “Thank you for the time here”-mail comes I always try to write them a short sentence saying that I’ve really appreciated their company, competence and just being around them. And it hits me every time; why didn’t I say anything of this while we were colleagues? It’s so stupid. It’s so simple. And it takes about 5 minutes to write. I always find the time when they send the notice that they will quite.

So I will try this out – send people a “If you quit today … I would love to have said this first”-note...

About a year ago, my project manager asked me to “just give a quick intro and overview; What is agile? 20 minutes or so…” At first, this didn’t seem too bad. But when I got home and started preparing, I realized how challenging it is to sum up agile!

For me, agile has become almost a lifestyle. Much of what I advocate or oppose relates to agile principles or practices. Now that agile is 10 years old, the buzzword has evolved, and almost anything good or innovative in software is branded with agile ™.

Is TDD agile? If you’re not doing TDD, are you not agile? Standups? Boards? The list goes on and on, and I couldn’t come up with a definitive answer. Either everything had to be included to be agile, or nothing was left.

Like the story of the old woman who collects wood:

She went...

I’m rereading a great book – Switch by the Heath Brothers and it inspires me. The last time I read this book it inspired me to write a post and it’s happening again.

The book is about change, how to accomplish change and especially in situations where you are not in power or control. In short – how to talk to and influence others to understand the need for change and follow through on it.

One very smart thing is that you can download a cheat sheet that contains the ideas in a nutshell – the Switch Framework – for free. Of course it’s not much use if you haven’t read the book, so you better do that first. Could very well be the best book you read.

I thought I would apply the reasoning in the framework to a real life situation and...

We have been chasing some strange logging bugs for a while in my current project. We are using log4net to do our logging and it works fine … until a couple of weeks ago. Some logging didn’t occur, in another case we didn’t get new files…

The fix is, very simple, but quite surprising and I thought I’ll share something on what we did to fix it.

We are using a RollingFileAppender and common strategy for how to handle the log files; we’re creating a new file for each new date. In order to achieve this we have set the following configuration:

 <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender"> <file value="{a path here}" /> <appendToFile value="true" /> <rollingStyle value="Date" /> <datePattern value="yyyyMMdd" /> <layout...