This is the second part (read the first part) of my trying to get inspiration from the Switch book on how to get developers to realize that we also need to take our responsibility for the quality to test. It not just the testing departments problem. As W. Edward Deming put it;

“Quality is everybody’s responsibility”

Last time we took a look at the first principle – Direct the Rider. This time the turn has come to the elephant in the kitchen. The emotions and things that we cannot control by pure will power – it’s time to see if we can Motivate the Elephant.

Motivate the Elephant

The elephant is lazy; he doesn’t want to write more code than necessary or write stuff that probably somebody else will find anyway. Also the elephant will be pushed out of his comfort...

Last week I attended the premier agile conference in Sweden, Agila Sverige. In one of the Open Space sessions we had a great discussion on why, still to this day, many developers don’t think writing test is important. Or at least boring and second grade job for a developer. The session was suggested by Ville Svärd who apparently has spent quite a lot of time on trying to convince developers that testing is important and also an important part of their job. So the whole session was just us sharing ideas and tips on how to help and convince developer to catch the testing-bug – it was aptly named “Testing is cool!”.

Yes, yes – you could argue that it’s simply just to hit them harder and tell them that “They must!”. But I don’t think that works particular well. At least it don’t...

Lately I’ve been coming back again and again the importance of culture in an organization, group or company. It’s the thing that binds you together and with a strong culture in place you can get a very fast moving, quick acting organization without being afraid of the people in it straying away from the important stuff.

This topic has been nagging me for a very long time, a few years to be exact. I come back to it again and again in my reasoning and argumentations (probably sounding like an old record that got stuck to some people). But that just because I think it’s super important – it’s the soul of your company if you will. The spirit of a otherwise lifeless entity.

This blog post is probably just scratching the surface of book length material. Bare with me – I need to get this out now.

US...

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 supersimple. In fact you could sum it up as Janice Linden-Reed does on the excellent...

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