Sunday, July 5, 2009

Thinking in context.

There has been som general hubbub about establishing WIP limits in the Kanban community latly, some have gone so far as to claim that it is wasteful. Or more exactly that they are wasteful since if you're mindfull you can see the same bottlenecks without them. And theoretically I think that is true. But this is one of thoose times theory just won't help.

In my, not so humble, oppinion establishing WIP limits helps us the same way a budgets do. It help us set clear priorites and makes us think about our general goals. It also works as a clear leading indicator for when things are getting out of hand. One could make the claim that having a budget is waste, and if you're really disciplined I guess that is a viable option. But for me, it's not that I strictly need it, it's just way simpler than the alternatives.

Twitter via @hiranabe provided this gem: Kuroiwa-san(ex-Toyota mgr) concluded speech by emphasizing "Thinking for yourself in your context" is the heart of Lean

This is another very tangible postive effect of imposing limits, they help us establish context. The heart of lean and agile processes is thinking in context, anything that helps us faster establish context and be present have a great positive impact on the speed of communication. Thereby helping us improve, reflect, adjust and evaluate. That in turn helps us deliver more value faster, and sustain those improvements over time.

Thinking is not the key, thinking about the right stuff is. Establishing context is vital for that.

Tuesday, June 30, 2009

Ownership, Responsibility and Sharing.

Im a big fan of collective code ownership. This is my attempt to clear up one common point of confusion. Responsibility does not imply ownership. Making everyone responsible for the whole codebase most often fails miserably for the same reasons very few can keep any sufficently large system wholy in their heads. If everyone is responsible, most often nobody or a select few is. My current thinking about this is that people should be responsible for a slice of functionality or a module depending on your circumstances. But they're responsible, they don't own it. Anyone can, and should be encouraged to, change the code. The responsible guardian for that part should monitor changes, clarify conceptual missunderstandings, know his part of the system on a sufficent depth to be able to detect at a structural and conceptual level when duplication is creeping in to other parts of the system. Having responsibility does not mean soly working on that part, it means shepherding it and making sure that peers adhers to agreed conventions.

I've seen tremendous benefits from this, it lets people get really good at one part of the system, giving them both pride and the ability to at a much deeper level draw parallels to other parts during pairing sessions and work on other parts. It avoids the "everyone knows almost nothing about everything"-problem thereby reducing waste due to relearning and rediscovery. It sets expectations and builds team spirit, if we know that someone will be checking our work we tend to take greater care. And noone want to let a team-mate down. Theese effects augument conventional practices like pair programming in a very positive way.

Thursday, June 25, 2009

Wednesday, May 27, 2009

Microsoft - You're doing it right!

I'm generally not known for being a big Microsoft fanboy. But I have to say that my recent experinces have left me happy. I've been using the F# CTP since it came out and currently running the Visual Studio 2010 beta. Both are great products but that's not what this post is about.

This post is about how pleased I am with their handling of submitted bugs. The F# team is extremly friendly, quick to respond and equally good at providing updates and responding in a timely manner. Maybe not shocking given that it seems to be a small dedicated team. What mandates this post is that the VS2010 beta team also exhibits theese qualities. Submitting a bug is easy and painfree and they seem to be handled in a very good manner providing timely updates as it flows through the process.

So all thumbs up for the awsome F# and VSEditor teams!

Friday, April 24, 2009

Fake - The future of .NET build tools?

Tired of XML based build systems?
Thought so. That's why I spent a few minutes hacking togheter the basis for my own build system. I call it Fake. And looks like this:
let clean = task "Clean" (fun () ->
    Console.WriteLine("Cleaning."))

[<Default>]
let build =
    task "Build the lot" (clean => fun () ->
        Console.WriteLine("Building.."))

let loadTestData =
    task "Load some test data" (fun () ->
        Console.WriteLine("Loading test data..."))

let test =
    task "Test it" ([build; loadTestData] => fun () ->
        Console.WriteLine("Running Tests...."))
Then simply
x:\..\>fake test
Cleaning.
Building..
Loading test data...
Running Tests....
x:\..\>
Is this idea worthwhile? Tell me in the comments.

Tuesday, April 21, 2009

Team Foundation vs Subversion and Bazaar - Round 1: Update my workspace.

I usually work with Subversion or Bazaar but currently I'm on a project using Team Foundation Server. Today I got the silly idea of updating my workspace using the command line interface. Assuming that you are standing in the directory you want to update this task can be accomplished as follows:
SubversionTeam Foundation
svn uptf get .\* /version:T /recursive
Now one of theese is sane, the other is complelty insane. I won't tell you wich is wich.

Wednesday, April 8, 2009

RED - Re Evolutionary Development

Something is happening in devloperland, if you put your ear to the tubes of the blogosphere you can hear a faint message. The Software Craftmanship movement is gathering momentum with a simple message, and one of the high priests of XP has abdicated.

There's a new focus comming and it cuts right through all excuses, the message is simple.
YOU are responsible.

No one else is going to give you the mandate to work in a fashion you know you really ought to, no one else is going to educate your peers for you, and no one else is going to fix your broken process. Yes I know it's horrible. The business demands the impossible and your cow orkers are all a bunch of imbicils. That's exactly why it's your problem. You're the only sane, educated, competent, levelheaded person around, it's your responsibility to do something about the madness.

We need to stop trying to blame everyone else for our problems, we need to stop discussing what's wrong with "other people" and actually start taking action. Every single day, strive to improve, learn and share!

I'll dub this "Re Evolutionary Development" or RED for short and as all good philosophies it needs a set of principles the first one simply is:

RED Principle #1

Each day ask yourself.
  • What did I learn?
  • What did I share?