No contract can compensate for lack of trust

Many buyers of IT development projects seem to think that all problems and unpleasant surprises can be avoided by buying a fixed-price, fixed-time, fixed-functional contract. My experience, however, is that if you haven't built enough trust between buyer and supplier you will at some point, often late in the project, end up in endless discussions on what was really part of the scope and how to interpret the requirements written in the contract. This is just natural since both parts, lacking trust for each other, are focusing on maximizing their own profit from the business relationship.

In the agile world one giant step forward has been taken - to embrace change. This results in fixed-price, fixed-time, fixed-functional-effort contracts where decisions on functionality can be deferred and revisited in each iteration. This gives the buyer the benefit of actually receiving what they need instead of what they thought they would need in the future by the time of contract signing.

However, even in the agile approach you may end up in long discussions on how to define the effort of any given feature to be implemented - if you are in a non-trust-relationship that is. I think that relationships between organisations aren't any different from relationships between people. It is just not possible to base a lifetime of living together with another person on contracts. It has to be based on deep and honest trust that both parties honour.

So, before you decide to by an IT development project from a vendor, decide on whether the vendor is to be trusted. Also try to find out if the vendor has trust in you as a buyer. If so, go forward, form a common goal and sign the contracts you think are necessary for guidance. But do not try to build a relationship on contracts if you are lacking the trust.

White-boards and UML - The strength of visual communication

I really enjoy communicating in front of a white-board. Whenever I'm engaged in a discussion with some colleague, asked to explain how some piece of software works or what my design idea looks like, I tend to pull him or her into a room with a white-board.

I think it was Kent Beck who talked about the bandwidth of different styles of communication. From worst to best he listed written documentation, two persons speaking over the phone, two persons speaking face to face and, with a broad margin, two persons in front of a white-board. I fully support this theory since I feel the best discussions always tend to result in a white-board full of symbols, perhaps with absolutely no meaning to anyone who has not been part of the discussion, but invaluable to us who have.

Even when just trying to get my head around a problem or figuring out a small piece of design work on my own I like to visualize my thoughts, "the model", on a piece of paper. Perhaps the result at some point ends up on a white-board to be discussed with others.

In all of these situations it is invaluable to have a graphical "language" to use. Since written or spoken language is so imprecise and ineffective in describing complicated relationships and structures, especially among software components or pieces of information or data, we need a better way to express our mental models. This is where Unified Modelling Language (UML) comes in handy. Not that you need to draw complete and 100% correct UML-diagrams, I strongly think that to much details kills the good communication, but being "fluent" in rough UML-sketching gives you a powerful way to structure and communicate your design ideas. As a pure bonus it also strengthens your thinking in object oriented models; always a good thing when designing for Java or .Net.

If you need a good guide to UML I would recommend you to read Martins Fowler's "UML Distilled". Its subtitle is "A brief guide to the standard object modelling language" and I would say it's the only one you'll ever need. It's only 150 pages long and can easily be kept handy at your desk whenever you need it.

Learning UML isn't just good for expressing your own design ideas, it is also necessary if you want to move on and learn more on SE-related topics such as design and integration patterns, domain driven design, etc, etc, since those books (if they are good) always comes with a good deal of UML-diagrams to explain key points and give examples.

Jfokus 14-16 February in Stockholm - Don't miss it!

Over the last few years the Jfokus conference in Stockholm has grown fast. It now attracts top-level names such as Eric Evans and Martin Odersky and many others. Personally I'm looking forward to the sessions on  Domain Driven Design and Scala. In many slots of the day it is really hard to decide what session to choose since that also means that you are missing out on other great content. For me, that is a sign of a good conference.

Visiting Jfokus is now a yearly event for me and it has provided me with a good deal of new influences to my day-to-day work. I often find interesting new trends, methods, techniques and tools to investigate further. For example, it was at Jfokus I got my first good bits of both Scrum and DDD, which both now are permanent residents in my toolbox.

So, if you are in Stockholm in mid Feburary, don't miss the opportunity to pick up on the latest and greatest in the Java/JVM/Software Engineering world!

Use SCRUM to increase flexibility, efficiency and transparency in the delivery process

In this post I’ll give a short overview on why I think using SCRUM is a good way to increase flexibility, efficiency and transparency in the delivery process.

Flexibility
In SCRUM we work with short, iterative, releases (sprints) where the customer (product owner), at the beginning of the sprint, is allowed to decide what is most important right now and should be included in the next release. Hence "time-to-market" for a typical feature can be reduced to only the length of a sprint, typically 2 to 4 weeks.

Efficiency
SCRUM emphasises the delivery team as responsible for the delivery they have committed to within the sprint. The team is also empowered to make decisions on how to organise the work to achieve maximum efficiency now and in future sprints.

Communication on priorities, requirements and possible designs is short-circuited between the team and the product owner. Hence, additional management and detailed planning is eliminated and feedback cycles are sped up. Everyone involved is contributing directly to the delivery of high-quality code, following the lean principle of "eliminate waste".

Transparency
SCRUM introduces complete transparency to the delivery process. Expectations for the next sprint is set and agreed between the product owner and the team in the "sprint planning meeting" at the beginning of the sprint. Current status is tracked every day in "daily scrums" where all team members discuss what has been done and what should be done next. Anyone is invited to listen in on "daily scrums".

At the end of the sprint a "sprint demo" is organised where the team demos the features implemented in this sprint. Everyone is invited to the "sprint demo" to see and comment on what has been done and what needs to be done next.

The SCRUM team
A typical SCRUM team consists of 5-8 people including every competency needed to produce a production ready release in every sprint. Competency in the team includes:

- Analysis
- Design
- Implementation
- Test
- Configuration Management
- Scrum Master (responsible for the delivery process)

Running Ubuntu in VirtualBox - stay off the bleeding edge!

Since the beginning of 2010 I've been experimenting with running Ubuntu inside VirtualBox on my Windows laptop. I always tried to stay up-to-date with the latest stable releases. In the beginning it worked like a charm but lately there have been some issues. It seems that VirtualBox has not been able to keep up with changes in the latest Ubuntu release, 10.10. Problems with the guest freezing due to using several cores arouse already during system upgrade from 10.04. It seems to be working fine when using only one core, but who wants to go slower just because of that. Lately there also seems to be some problem with the VirtualBox guest-additions leading to a painfully low screen resolution of 600x480 in the guest OS. It's just not working these days....


So, what is the alternative? Since remembering everything working fine during the spring I decided to roll-back to earlier versions. Now I'm running VirtualBox 3.1.8 with Ubuntu 10.04 LTS (both desktop and server) and it all works fine. From now on I will be much more reluctant to upgrade to new releases, and definitely be sure to create a snapshot of the virtual machine before any upgrades.


All in all, the combination VirtualBox and Ubuntu works fine, but for a stable working environment be sure to stay off the bleeding edge!