This is the second post in a series where I discuss agile concepts with business people (and some technical folks too). Here is the first post if you want to catch up.

Again, a disclaimer: this might seem basic to agile experts. Please bear with me as I explain these ideas to people who may not have immersed themselves in agile methodologies.

One common topic that comes up is deployment frequency. Many organizations prefer to make big, infrequent deployments rather than smaller, more frequent ones. While this might seem logical to some, it’s often the opposite in large companies. Let me illustrate with a story:

I once consulted for a major insurance company in Sweden. They, like many in their industry, did four releases per year, aiming for “stable IT.”

Let’s pause and consider this. If you deploy only four times a year, stakeholders and projects will try to...

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 agilist 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 argumentation (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 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....