This post need to start with an disclaimer;

I write this since I have run into several people to which these thoughts are new and confusing. If you are an agilista you will not find anything new or exciting here.

Really… there’s nothing new to see here. Go away you scrum-lovers - this is not aiming for you.

How’s that for scaring people away from a blog post. If you’re still around… Anyone… Hello? Ah - there you are. Well – let’s get started then.

I recently have introduced agile in a large company and tried to do it through the whole company, business and IT working together in brotherly company. As you can imagine I ran into some problems. And still to this day we need to explain for the business why they would and probably should look into agile thinking (or was it lean maybe?). I...

This is the last post in my series on how to motivate developers to write test for their code. Please read the first two posts to get some context (part 1 and part 2).

This post talks about the last part of the Switch Framework – Shape the path. This is all about making the change easier by helping our rider and elephant to get a smooth path to walk on as they change.

Tweak the environment

This talks about changing the environment in which the people we’re trying to change so that it’s easier to change than to not. Microsoft lately has use the expression; “help developers to fall into the pit of success”. I like that a lot – that’s what we want here; it should be easier to do right than to not to.

Everything you can do here to get the...

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

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

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

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