just because we can live in a virtual world, doesn't mean that we should - a blog entry about the power of the Gemba

Friday, June 26, 2009 10:07:23 AM (Romance Standard Time, UTC+01:00)

Here is a nice blog-entry about what you can learn when you actually engage with your endusers.

Gemba in the virtual world



By Bent Jensen

Breadth-First Development

Tuesday, June 09, 2009 5:46:41 PM (Romance Standard Time, UTC+01:00)
I first came across the term vertical slice when I was in the video games industry. Trying to raise capital for our game, we were told by venture capitalists that they needed to see a vertical slice in order to assess our concept. That meant a small version of our game with just a little bit of everything. You should be able to see the technology, the artwork, audio, game design and all. I am not sure where the term originates from, but it is easy to realize what it means. If you consider a product to be composed of layers, the vertical slice represents a little bit of each layer.
Vertical Slice
This blog is called The Vertical Slice for a reason. While there is great focus on prioritizing in agile development, the emphasis is often in the concept of "business value". Which is a very sound focus compared to say, premature optimization or writing a system that is unnecessarily generic. However, focusing on vertical slices is equally important. As my colleague Lars suggested recently, the term breadth-first development is perhaps even more descriptive. If you consider the product to be a tree of increasingly detailed features, you want to start at the top and move into the details at all levels at the same time.
Breadth-First development
There is a consequence to this: you run into a lot of problems at the very start. A project that we are currently working with includes a web-frontend, a database layer and a reporting system that have all given us different kinds of problems. Other teams might have focused on getting one part working before moving on to the others but in the spirit of breadth-first, we wanted to work a little bit with all of them. That way, we don't run off on tangents in one of the layers, which might turn out to be unfeasible or simply incompatible with the rest of the environment.

By Kristian Dupont

Inversion of Control in the Real World

Wednesday, June 03, 2009 8:48:02 PM (Romance Standard Time, UTC+01:00)
When booking a hotel or a flight for your next trip you could do it the old way: surfing a lot of websites looking for cheap and relevant offerings. Or you could apply "Inversion of Control": specify your wishes regarding travel and accomodation and then wait for a lot of hotels and airlines to send offerings for you to choose from. Hotwire is one example of that kind of service.



When surfing the net, a lot of websites "push" commercials onto your screen earning money to the people running those websites. Wouldn't it be nice if you instead could "pull" selected commercials and thereby provide funding to your favorite charity? AidOnline is one (Danish) example of that kind of service.

As a programmer it seems to me that these two examples of "Inversion of Control" are structurally similar to the popular unit testing technique called "Dependency Injection".

Can you come up with other interesting examples of "Inversion of Control"?

By Lars Thorup

Collaborative Agile Contracts

Wednesday, June 03, 2009 10:15:49 AM (Romance Standard Time, UTC+01:00)
Recently peterstev reported on, 10 Contracts for your next Agile Software Project.

In BestBrains we now have experience from two commercial projects using a new kind of agile contract.

We want to create contracts where risk is shared fairly between customer and supplier and where likewise benefit is shared fairly. Based on our experiences we have arrived at a contract model that has proven to achieve this result. We call this the collaborative agile contract.

The main mechanism of the contract is to delay some of the payment until a certain criteria has been reached. We do not use a date as this criteria which otherwise seems to be common. Rather we want a criteria that tells when we have a situation where the customer is getting value from the software. There is generally a mutual interest of arriving at this situation as quickly as possible. Effectiveness and creativity from the supplier will be rewarded. And the customer will be careful when deciding what features are needed in order to reach that goal.

The contract defines the following elements:
  • Scope described loosely in a few paragraphs, a kind of vision statement
  • An hourly price, that is 10-50% below what is normal for pure time-and-material
  • A set of milestones, which will lead to payment of a fixed amount. The simple criteria that tells that a given milestone has been reached, is whether the software is deployed in production.
  • A development process following agile practices
  • A suggested time frame for the overall project and for each milestone

We are going to report on our experiences at Agile 2009, but don't hestitate to comment on this blog entry or contact Lars Thorup to learn more about agile contracting.
agile kontrakter

By Lars Thorup