Code by Prescription

A friend of mine is a doctor. Whenever someone comes to him with a problem, he checks them and in some cases he gives them a prescription for something that might help. The reasons that he has to give a prescription is simple; The society wants to make sure that only qualified personel can administer possibly harmful substances and we want to limit the chances of overdoses. The is why you only get a limited amount of medicine per perscription.

I'm just thinking, wouldn't it be great if we had something called code prescriptions? Not for tecniques that are simple, but for those that requires more advanced skills to master without increasing the complexity of the solution.

Wouldn't it be great to be able to give a prescription of "one dependency injection" or "ten linq queries, only to be taken in pairs" ? :-)

Happy new year everyone, let's make this year the best so far!

Evil Microsoft

My last post about Rosario was quite negative, being an MVP makes it is by nature hard to write negative things about someone that has done so much for my professional life. Microsoft has been helping me all along, from booking me as a speaker on MSDN-Live in the beginning of my career to providing me with all the great opportunities I get from being an MVP.

Microsoft is perceived as being a large evil company that does a lot of evil things (compared to Apple, that only does good things).

So what does this big evil company do when someone they have had close to them for years openly criticize one of their products?

They invite me for a beer and an open discussion about my concerns.

Rosario : Missing the mark for Agile Development?

The next release of Visual Studio Team System is called Rosario and I've been attending many technical and marketing sessions on it.

From the marketing buzz it seems to me that Microsoft wants to target the Agile Enterprises with this release.

I am currently working in an organization with over 100 projects being run in about 10 different locations at any given time. For our setup we are planning to do the following:

- VS2008 with Resharper 4.0 for development
- CruiseControl for buildcontrol
- NANT and MSBuild for actual builds
- Nunit for unit-testing
- Watin for gui-testing
- Perforce as source control and branch management
- JIRA with GreenHopper for planning and change management
- A homebrew and really simple application for doing dependency management (simple UI, generates simple copy-batch scripts that are checked into source control)
- A simple homebrew configuration generator (text replace based on a template and hieratical delta files). Works with all kinds of text files (like web.config, stored procedures and so on)
- Server side MSI generation for deployment with simple batch-files.

Please note that all homebrew parts have been discussed in detail with other software vendors like Microsoft and we were not able to find a better "off the shelf"-solution.

When looking at this list I can't help but thinking: What can Rosario provide to this story?
I guess that having everything integrated within one tool is good on a conceptual level, but will it actually help the performance of the teams in an enterprise world? For every part of our developer story we provide simple implementations and we make sure that everything is easy for everyone to find. We focus on KISS all the way (KISS = Keep It Simple and Stupid).

This brings me to my main concern with Rosario: Which parts of this story can it do better? As of now, it seems that Rosario will provide a lot of non-core features, but it will not provide much with higher real value than my current story. For every part of the story, I can't help but thinking that we will loose flexibility and important core features if we move to Rosario. Rosario mainly solves problems I didn't know I had.

The point of this post? Please prove me wrong in my assumptions. It might save us a lot of time and money. I will be very happy even if you can prove me wrong in parts of this story, as long as the focus is enterprise (real) agile development.

New workshop format: Goldtaking

Today we tried out a new format for workshops; I'd like to call it "GoldTaking". We got great feedback on it.

It works in the following way:

Pre-requisites
1. The group starts off by having a quick standup where everyone suggest one topic to discuss. These topics are being listed on a board/big notebook.

2. Everyone goes up to the board and make a single mark on one or two topics they like to discuss.

3. Depending on how many people are attending, the organizers choose a number of topics to discuss and make up groups for them based on number of markings. Since everyone can mark two topics, we easily filter the topics. If they could only select one, they are more likely to only mark the one they came up with in the beginning.

The actual "Goldtaking":

For each group we have a notepad and a pen and select a note taker to begin with. Whenever that note taker wants to make a statement or ask a question, she passes the notepad and pen clockwise, thus making the person sitting next to her the new note taker.

This has some interesting effects; one that we experienced is that very often someone is likely to "take over" the discussion. After some time they are bound to become the new note taker, thus giving the word to the others.

Another thing that this accomplishes is that when we gather the books afterwards, we have an excellent document for making reports or post-documents of the discussion.

Everyone is free to take their own notes when they are not the official note taker, this means that if they really want to take notes on everything; they can either fill in their notes whenever they pass the notepad (after making the statement/question) or they can borrow the notebook afterwards and copy from it (the missing bits will be written by them self!).

The reason for the name "GoldTaking" is that this is inspired from Gold Fish Bowl-discussions and that the result document may be worth its weight in gold.

The good life of Agile

When I started doing Agile projects and coaching in around 2000/2001 it was hard work getting management to agree or even discuss the topic of Agile. Whenever we wanted to do an agile project, we had to be very stealthy. We had to fly under the radar of upper management and sometimes even project management. Management usually told me "we can see how this works for small projects, but in the enterprise world we have to go for waterfall"

In the later years, this has changed a lot. These days you can't start a project without deciding "how agile it will be" first. In a coaching session the other day one manager told me "I can see how this works for enterprise projects, but will it work for small ones as well?"

This question almost gave me goose bumps (ok, I'm crazy, you know this by now).

After all the years of hard work, I think we are at a point where we are changing the way software is actually being created.
Not only changing the way we wish software was being created.

This might have to do with the fact that we have proven ourselves over and over. We have been put to so many tests and hard questions that we have a lot of refined and well thought answers, stories and experience reports that we can tackle any challenge.

Since April, I've been doing sessions in London, Florida, Seattle, Limerick/Ireland, Shanghai and several cities in Norway (and I am currently in Toronto, waiting to do two more). All of them have gotten a good review and I still get a real kick of being on stage.

I feel like I'm in the right place at the right time. I am sure most of you other Agile Coaches out there feel the same way.

Life is good.

Speaking at Agile 2008 - Toronto, Canada

Next week I am going to host two sessions on Agile 2008 together with Lars Arne Skår.

Here are the sessions:

How to support a collaborative atmosphere in distributed projects?

http://submissions.agile2008.org/node/388

Exposing the “devils” within - Agile taboos and other hurdles in a large organization

http://submissions.agile2008.org/node/380

We did the second one at XP2008 in Ireland some months ago and I will blog the result of both of them soon.

Airport Check In - Local Chinese Style

When leaving from a small local airport in Shanghai (about the size of our national airport in Norway...) this morning, I got into a rather bizarre situation. When reaching the check-in counter I was promptly dismissed (after standing in line with my fligh number over it, for quite some time). I was told to go to another counter on the other side of the hall. This was an interesting counter, not only because it had 4 employees sitting in a 2 Square meter space. It was interesting in the way it had about 20 angry screaming Chinese people around it. In the midst of the highly aggressive and high pitch screaming crowd (AHPSC), here I was trying to get a boarding pass. After a while I managed to navigate close to the counter and explain that I was sent from the counter on the other side, and that all I really wanted to do was to check in and get my boarding pass. After some more commotion from the AHPSC I finally got my boarding pass. Or at least I got the boarding pass for the first destination. I was told that I had to check in at Beijing for the rest of the way.

The reason?

A colleague of mine told m e that their software only has two fields for destinations... If you have more than 2 destinations you can't check in all the way. I would not be suprised if this piece of sofware was created using a waterfall approach...