Let's get down to business!

The CIP FORUM 09 conference will take place in a couple of days in Göteborg, themed "The Future Of Innovation". There will be talks about "management of intellectual assets", "building platforms to assure innovation", "new infrastructure adapted to knowledge-driven business creation", "asset value creation process", "contract management" and more!

It's all very good. I guess. But I wish I had the guts to crash the conference, go down there and stand up at the keynote and say:

— How many people in this room is a founder of a start-up? Who is actually working at a start-up now, raise your hand!

Expecting no more than a handful of hands, I'd continue:

— So, who wants to keep talking about innovation, processes, assets, infrastructure, IP and all that, and who wants to get down to business and do something? Anyone? Come with me if you want to spend the next 24 hours doing just that, bringing an idea into the hands of actual customers. Think: The Apprentice with Donald Trump.

Then I'd leave with hoards of fresh entrepreneurs following me out into a bright new world.

Maybe not.

Now for a more realistic idea: Since 24 Hour Business Camp in Stockholm is already fully booked, how about doing a Go:teborg version of that? Gothenburg cannot be all about motorized vehicles, please!

I want my lawyer

I'm sitting here waiting to be interviewed for a gig. This room makes
me want to scream "Where's my lawyer? I'll say nothing without my
lawyer". (okay, they are actually redecorating)

Agile usability

Jakob Nielsen is writing about how to use agile development methods without ignoring the usability aspect. This is a really interesting topic since usability is ignored to an equal degree within both waterfall and agile methods.

In my experience, usability people usually favor the heavy up-front design. Because, in their view, once they've completed their sound usability engineering, what could possibly change? Their work is done and they leave before the first line of code is written. They continue on to the next project without ever learning that requirements always change, and ought to change.

While I'm on the subject, let's look at the usability of Jakob's Alertbox column itself. Where is the Comments feature? Is he too smart for feedback? I've sent him an email about this. We'll see if his email address is actually usable...

The Mystery Sherlock Holmes Never Solved

I'm talking about the mystery of setting up your development environment for the project you are joining. You know, that step-by-step instruction that within 30 minutes leaves you with a complete environment that lets you check-out, check-in, build, debug, deploy, test, run and perform all your daily developer tasks.

Actually, that document is usually nowhere to be found. It could only be recreated by interviewing every developer that ever worked on the project. Sherlock would not have coped.

The plot thickens since this very document is the single most important piece of documentation of any project. And I have proof, Dr. Watson. Let me come back to that in a short while.

Having a good dev-setup instruction is all about respect for the new coder on the team. Do you want him to end his coding days like Sir Charles Baskerville or do you want him to get a good start?

Also, if the setup takes a long time it is a sure sign that the system has grown more complex than it should be. Perhaps it's time for a thorough refactoring.

How would you go about creating this document? I believe it shouldn't even exist. The setup ought to be fully automatized.

If automization isn't an option I would suggest to try something I did on a recent project. Hire an external developer to come in and try out the existing setup instruction. Ask her to follow the instructions while updating them as needed. Time it. If you're not happy with the result, bring in another developer and iterate.

Well Dr. Watson, allow me to present the result of some research I did before writing this post. I asked for the Single most important piece of documentation on stackoverflow.com. At the time of writing the most voted answer by far was "How to set up the development environment".

How is possible that I have never seen a good setup instruction for any project I worked in? Hmm, I believe we got work to do, my fellow coders.

What I hate about Scrum

I attended the Deep Lean conference held in Stockholm on September 25-26 2008, with Mary & Tom Poppendieck, Jeff Sutherland and Henrik Kniberg. They were as brilliant and full of energy, as was the crowd full of smart questions.

Especially Mary impressed me and it was a joy to listen to her presentations. During on of those she suddenly said "Let me tell you what I hate about Scrum". Jeff Sutherland sharpened his ears as did the rest of us. Let me get back to what she said in a moment.

The best thing about the conference was that all of the speakers stayed in the room and listened to the presentations. To hear them interrupt each other and discuss something was great. The lesson learned from that is that these guys don't have all the answers. You need to think for yourself. I certainly need to repeat that for myself every once in a while.

Let me mention just a few things that stuck with me from this conference.

Keep your backlog short
Why spend time elaborating on things that perhaps will never get done? I immediately started deleting things off of my project backlog as well as my private Outlook task list. If the items I deleted ever become important they will certainly bubble up to the top of my mind again.

Story point deflation
This is a question that came up and I don't remember it getting a good answer from any the speakers.

Let's say you estimate a story to five points during the first sprint planning. A number of sprints later you get a similarly difficult story to estimate. This story gets an estimate of only two points, since the team is equaling story points with ideal man days. The result is that the team gets more and more done but the velocity stays the same.

Is the solution to make estimations relative to a medium sized reference story? Even though the days needed for the story is only two, it will still get five points since it is about as complex as the reference story. I don't know if this works, but perhaps somebody else does?

Product Champion
Mary spoke of the product champion as somebody who is the product owner and the system architect in one person. That's a role I would like to have. The product owner has always struck me as somebody too far away from the technology. She also abolished the scrum master altogether. A functioning team will remove impediments by itself.

Unnecessary features
Lean is a lot about waste, and the worst waste is the implementation of unused features. Probably very, very true. But how about this: Features sell products. I buy dishwasher detergent based on whether is has that red ball in middle. I feel I need that feature. And the big corporation buys the application server from IBM since their product is just incredibly complex and has so many features. Then it must be good, and worth all that money. Solution, anybody?

Ok, so now let's get back to the question of love and hate.

What was it that Mary hated about Scrum? As I recall it she said "What I hate about Scrum is that only team members get to speak during the Scrum meeting. If anyone else attend they should stay silent and listen. That is totally disrespectful."

At this moment Jeff desperately (?) reached for the microphone and said "That is a misinterpretation of Scrum".

I'm glad he set that straight.

Two other blog posts about Deep Lean: Damon Poole, David Jellison

Carl Bildt leads the way

Frequent blogger, our Minister for Foreign Affairs Carl Bildt just made the switch. His only regret is that he didn't make it earlier (Swedish).

And now the time has come for me, I've ordered an iMac this morning. I would have waited longer if it wasn't for the strange noise coming from the harddrive(?) of my four year old Dell desktop.

That machine has served me well, and I'm not the geek who craves the fastest processor every six months. Actually I always buy the second fastest machine available and usually save at least 25% on the price. An intresting fact is that the Dell runs at 2.66 GHz and the iMac at 2.8 Ghz. Whats is going on, Mr. Moore? ;-)

I'm not totally new to the Mac. There is a green iMac 1G on a table in my office, and there is Mac Mini we use as a media server sitting on top of the tv set. What worries me a bit is that I rely a lot on Outlook and Exchange. Is Entourage as good as Outlook?

I do hope that my current machine will survive the month it takes for Apple to deliver the new one.

En dator är en bil

På en avgörande punkt har vi som är systemutvecklare misslyckats totalt. Nämligen vad gäller användarens/förarens kontroll av maskinen. Lika lite som en förare kan godta att förlora kontrollen över bilen, bör en användare godta att förlora kontrollen över applikationen i sin dator.

När det gäller förlorad kontroll av en bil kan det sluta med döden. Riktigt så allvarligt kanske inte förlorad kontroll av en dator är. Men det finns få saker som är så frustrerande när ett program låser sig, om så bara för två sekunder, när man behöver ha någonting gjort.

Detta är sannerligen inte ett olösbart problem, rent tekniskt. Det handlar snarare om vår inställning (som utvecklare) mot våra användare. Bristande respekt. Ofta mot oss sjäva fascinerande nog.

Men vissa operationer tar lång tid, eller hur? Andra är beroende av att operativsystemet skall svara, eller hur? Javisst. Men nu finns ju en magisk sak som kallas tråd. Låt gui:et få en tråd. Gui:et vill ha en tråd.

Sen är det såklart så att operativsystemsmakarna måste skärpa sig i lika hög grad. Frågan är om vi inte skall lära av Intel och andra som gör CPU:er?

Användarna måste få tillbaka kontrollen. En dator är en bil. När man svänger på ratten skall bilen svänga nu, inte om tio sekunder.