Something I see again and again is a team wanting to switch from CVS/VSS/TFS/SVN to something better, like SVN/git/BZR/Hg. In preparation for this move, they spend a lot of time seeing if they can find some tool that can migrate their history to the new system. After considerable effort, they decide it is no tools can do it well, and go ahead and do the switch manually. After some initial bumps, everyone is happy with the new system, and the team realizes that they haven't missed the history at all.

So, my suggestion for anyone wanting to switch is this:

1. Install the new VCS
2. Make the old VCS read-only
3. Make the first commit in the new system as just the trunk from the old system, sans all .svn/.ssc/.cvs files.
4. If you need to look at old history, the old VCS is still there

If you have branches, merge them in before doing this. If you have long-lived branches that you want to keep after the switch, you probably have to do some manual magic. Do it manually. Don't spend any time looking for tools.

Of course, you will not listen to this advice, and spend a number of fruitless hours looking for something that can do the switch for you. I know I would...

Chris Hedgate:
I have worked with Chris on and off for the last seven years. I have learned from him all along, and I still do. Chris has changed so much during these years that it is not even funny. He has gone from a kick-ass SQL dev with a little C# expertise, to exceptional object oriented developer, to an inspiring coach and great facilitator. And he can still code... One of the things I like about Chris is that he is always open to new ideas and projects. I am absolutely certain Chris will reach great heights in this industry, and I will be to be the one in the background saying "I knew him back when..."

Marcus Widerberg:
We (Marcus and I) did our first agile coaching assignment together almost five years ago. We noticed early that our interactions were not always smooth, but I learned from each and every one of them. Of the three, Marcus has helped me most to find new communication tools. He has a way of pointing at exactly what I say or do that might offend people, and he is not afraid of saying it. Marcus has also shown me that preparation is not only a bad thing. When he prepares and facilitates a meeting, I know that the meeting will be successful. I see Marcus presenting his papers in OOPSLA in a near future. I want a signed copy!

Joakim Karlsson:
I met Joakim through his design of a system I was hired to work on. He took parental leave, and I stepped in to implement his design (I know, it sounds crazy in my today-agile-ears). When he came back we worked side-by-side for some time, and I remember doing "guerrilla agile" with him - installing CruiseControl.NET on my laptop. Joakim has taught me a lot about how to work as a consultant - even though I have ten years experience in it, and he just started... I like watching him work with our clients, and in his relaxed, laid back manner steer them gently to better code and greater understanding of the system we work in. I try to copy him, but it's hard...
When we joined forces with Joakim a year ago, I knew that he was a good developer, but I didn't expect to find a great new friend in him.

Blueplane didn't work out, but I had a good time, and I learned so much it would be crazy to regret any part of this experience.

Blueplane slutar! Efter två års spelande lägger vi av. Beslutet är taget med största enighet och i största samförstånd. Alla planerade produktioner och turneer inställs. Beslutet gäller med omedelbar verkan. All ryktesspridning i frågan är osann! Jag vill ge ett speciellt tack till Leif Carlsson, ex-VD på Playahead och Carolina Palmquist, ex-VD på Travelstart. Tack för att ni trodde på oss. Lessen att kapitalet inte insåg hur bra ni är.

Tack också till alla som fortfarande inte förstår hur man ska utveckla mjukvara - ni gjorde Blueplane möjligt.

Kampen går vidare! 1,2,3,4, SLUT

To my English readers:

We have decided to close down Blueplane. It has been fun, exciting and immensely  educational. What I will be doing in the future is still not clear. Have a suggestion? Let me know.

Myth #3: If the team isn’t struggling or working long hours they aren’t working hard. Teams that are working well together make the work look easy. They work at a purposeful, yet relaxed pace. They even look like they are having fun.

We hold seminars every month (you are welcome too!), and a few months back, we did a Lean simulation game. It gave people a chance to experience first-hand the benefits of small batches and pull. People got to try pull with small batches (Right Way), and push with big batches (Wrong Way). What I found extremely interesting is that when people were doing the Wrong Way, everyone was working at a hectic pace. They showed signs of stress and it was clear to us outside that they were working a lot harder than when they it the Right Way. Yet they produced a lot less. When doing the Lean way, people seemed almost bored, and had time to observe what was happening in other stations.

The hard part about the myths that Ester talks about is that they are not really myths - they are not stories passed on from manager to manager. Instead, they represent what our guts tell us. That makes them much harder to ignore. Most of the time, our gut feeling helps us make the right decisions - we are used to listening to our instincts, and rightly so. It's just that the caveman survival instincts do not always apply to 21st century software development...

Sweat now, gain later
My theory is simple. We value what the code does more than we value how the code looks. It's a little bit like watching TV or working out. If you stay home and have a soda in front of the TV, your rewards are immediate. You'll relax, and the sugar feels good. Anything uncomfortable that might come from sodas and TV will not affect you for a long time. Working out, on the other hand, is often uncomfortable immediately. The sweat comes now, the nice abs way down the line. So why bother?

Code now, test later
This leads to legions of developers and managers that put short term rewards ahead of long term benefits. Hacking away without unit tests or stopping to refactor gives you that immediate reward of working code. Working diligently on great code design won't give you any benefits until much later. It's way too easy to use that path. I've been thinking about code quality for years now, and I still start hacking away if I don't watch myself.

You get what you measure
I think that there is one more factor that makes bad code so common. Whether code works or not is relatively easy to measure. You click a button, and either the row is put into the database, or it's not. It's easy to see for anyone, including managers, product owners and clients. Code quality is, on the other hand, impossible to measure, and to a large degree a subjective dimension. So anyone trying to measure output from a developer, can measure finished story points with ease, but has a hard time measuring code quality.

The old maxim says that you get what you measure. And I've seen almost every team I've met measure their productivity on the complete features axis, but few or none measure the quality of their code.

We're heading for a fall
I wish I had something more positive to finish this post of with. We are as a species fighting a losing battle against obesity, and I don't think we'll finish any better in the battle against bad code. The only silver lining is that any team that has the wisdom and discipline to do what it takes will easily outrun the lazy developers that prefer TV over the treadmill.

"I hear and I forget. I see and I remember. I do and I understand."

Confucius

Big, important parts of agile are counter-intuitive. If you had to guess how important some of our practices are without experience, you would problably come to the wrong conclusion.

So, a lot of time, I find myself discussing concepts and theories with people who are interested in the domain. They want to understand. They are curious. But their gut tells them that this will problably never work. There's no way I can talk a gut into believing me with logic and diagrams. Guts just don't listen to reason.

Let me explain how I see this. I imagine a small kid, scrawny and innocent. He's riding a big elephant. He has this stick in his hand, which he uses to prod the elephant to get it to go where he wants to go. Anyone looking at the pair instantly recognises that the elephant goes wherever the elephant chooses to go. The kid's prodding is but a suggestion, and nothing to take seriously. If the elephant wants to go somewhere, the elephant will go there, no matter what the kid thinks.

The kid is the brain, and the gut is the elephant. It's hard enough to talk to the kid under these circumstanses. But it gets worse. Most of the time, if the elephant goes somewhere where the kid didn't want to go, the kid will make up excuses to explain to you that he really wanted to go there. Not only does the elephant go where it wants to go - the kid will actually believe that this is exactly what the kid wants! Rational arguments might be interesting to the kid on top of a huge elephant, but it will never move the duo into action.

So, to influence the duo, I can't talk to the kid at all. It's just a delusional child, after all. We want to talk to the top man - the elephant. And in this quest, I have a new weapon. Experential Meetings.

Experential Meetings help me design an experience where the persons will feel first hand how our proposed way of working feels and looks like. If we can design the experience well enough, the persons will want to go there, and their rational mind (scrawny kid, remember) will make up excuses to get there. Much easier.

Anyone introducing new ways of working should really look into how you can use Experential Meetings to get the people you work with to really experience what you mean, instead of talking about it.

Chris writes:

" [A]n experiential meeting (or workshop, training session etc) is a meeting that includes activities that allow you to experience something (through discussion, hands-on work, simulations or something
similar) and then learn from that experience by reflecting on it.
[...]
During the debriefing participants get to hear other participants' perspectives. By sharing your own thoughts with others you will refine and extend your own understanding."

So not only do you get to experience things first hand instead of looking at a slide deck - you will get the chance to talk about what you've learned with other people and strengthen your own understanding.

We used this with a client last week. They had literally no experience at all with agile, and we were afraid that they would have a hard time understanding us. They have very long experience doing things their own waterfally way, and might not be open to two consultants telling them they've been doing it wrong for all this time.

So we designed a few experential sessions, and invited the managers and the dev-team to two hours of playing. By the end of the meeting, the CEO and CTO were saying exactly what we wanted to say to them, without us having to convince anyone. Incredibly powerful, and so much fun too.

Next up is Chris, who's going to be speaking about how to become a great developer. Here's the invitation, in Swedish.

A few weeks ago I talked about the constraint in software development. I produced a PDF from the presentation, with notes to go. Again - Swedish.

Knowledge is the key here. We need many different types of knowing to build systems. We need to digest the thousands of hours of effort that has been put into thinking up the programming language that we've chosen to use. We essentially move some of the platform designers’ ideas into our heads, and armed with this knowledge, we create. We need to understand their mental models - if we don't, we can't use the tools that they have created.

Encoded in the code libraries you use are hundred of hours of hard thinking by the makers. The better you understand the models that the library makers used when they created their software, the better you can use it.

You need to move the knowledge from the domain experts’ minds into your own to be able to create useful software. Sometimes the domain expert is a book - the idea still stands. Someone spent a lot of time writing down their ideas, and now you have to move their ideas to your head.

Anytime a group of people work together, you need to communicate and understand each other to be able to co-operate. You will learn about each other - what makes you tick, what your team mates are good and not so good at. To work together effectively, understanding of each other is crucial. You have probably heard stories about couples that have been together for many years, and how they barely need to talk to understand each other. They just have learned to communicate extremely well with each other.

Lastly, when we write the actual code, we're codifying our ideas into a form that can then produce runnable bits. The code will probably be read over and over again. Either by a future you that has forgotten the details you know right now, or to someone else. We still need to move ideas between minds.

In all stages of our work, be it analysis, design, coding, testing, this basic premise holds true. Learning - moving ideas and knowledge between individuals - is such an integral part of developing software that people forget about it. We sometimes think that the solution is already there, that the only thing stopping us is how fast we can type. Theory of Constraints, the management philosophy by mr Goldratt, claims that a system will always have at least one constraint. This constraint is what limits the systems total capacity. The system can’t produce more than this limit. So finding the constraint, and working on increasing it’s capacity is key to optimise a system.

Our industry’s common constraint is this transferral of knowledge - learning. Everything we do that helps us do learn faster will improve our effectiveness, and everything that diminishes our learning capacity will directly affect our productivity. Sitting close to each other opens up the possibility to use effective communication channels. It allows us to boost all the learning that is an crucial part of developing software.

Do I think that software can successfully be developed even by teams not sitting side by side? Of course it can. There are thousands of examples where distributed teams have produced high quality software that solved the business’ problem. I use Linux daily, and I don’t think Linus is sitting next to all the kernel committers.

What I tried, but failed, to say in my last blog post is that it’s so much better to work close to each other, that you should have very strong reasons to do anything else. Open source development done on by dispersed people on their free time is one such reason. Unavailability of developers at the right level might be another reason. Just take into account that the difference is not just a few percent less effective. I’ve seen teams productivity increase by more than 300% just by having the domain expert sit in the room with them for one week. You might want to give that productivity boost away, but make absolutely sure that you know what you are doing when you decide to split up your team.

I recently read a book about how important learning is to software development. It's one of those rare books that make you say "of course! why didn't I think of that!?". The main argument Allan Kelly makes is that the constraining factor in software development is how fast everyone involved can learn. I definitely buy into this - it resonates with me.

Many types of learning are involved here - about the technical aspects of the work, how the IDE works, platforms used, coding standards, patterns used and so on. The team will learn about the domain they're working in. They will also learn intangible things about how the group work, which will make them far more effective. All this learning is unavoidable - no matter what anyone does this learning will take place.

This is the constraint. No other single change can make as big impact as if the team gets really, really good at learning fast. Bigger screens, faster typing, or Ruby instead of Java means nothing compared to lifting this constraint. So an organisation that wants to make sure that their teams produce the right system as fast and with as high quality as possible better make sure that the teams are in a good position to learn.

And one way to make sure that learning is hard and slow is to force people to work far away from each other. Just having developers sit in different rooms will make the learning process much slower - imagine what sitting in different cities or even countries will do for you.

Alistair Cockburn talks in one of his books about how different types of communication have different bandwidths. Two persons talking face to face in front of a whiteboard can communicate many orders of magnitude better than two persons communicating through a Word-document. When you split teams up over geographical areas, you take away all the high-bandwidth ways they can communicate on, and this, of course, is very adverse to their learning capacity.

Manager realising distributed work is bad

When ever I hear of teams working across country lines, my gut reaction is to wonder if anyone has really thought this through. Have they made sure that the difference in labour costs really make up for the decrease in productivity and quality that it means to work like that? My experience is that it doesn't make business sense most of the times. Thoughtworks had a couple of distributed projects that where running pretty smoothly, but they worked a lot on overcoming the problems introduced by distributed projects. If you think that email communication with a development team is a good way to produce software, I would wager that you are in for a surprise.

So, to recap, a teams learning capacity is what limits their effectiveness as a software system producer. Some times you can't get away from dispersed teams. Enter these situations well aware of the extra cost this will have on your performance, and work on ways to get around these problems.

To me, talking about real options is not a revolution, or totally new insight, but it gives me a word to use for the practise of postponing decisions until the last responsible moment. I did a talk on real options last week, and I notice how I use the words "how can we create options here" more and more - even while talking to my wife.