Value-driven development in a nutshell

Tom Gilb coined the term “Value-Driven Development” [Gilb10] to remind the software industry that our purpose was to deliver value and not only use cases, user stories or features.

He also wanted to remind the Agilistas that their first principle was “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. There is a real challenge to make this ideal come true. It’s quite easy to increase your velocity and work on the wrong product at the same time.


During an Agile transformation we faced a problem: some teams were applying Agile methodologies, but not always creating value. So, we started to experiment new tools to help the teams delivering business goals instead of features.

Five concepts

When studying how to create valuable software, we have identified five concepts that successful teams were comfortable with:


Those teams could also answer quickly five embarrassing questions:

Goal: Why are you doing this?

Successful teams prefer to focus on the outcome (why they are creating this system) rather than the output (what are the parts they need to build). They focus more on their zone of influence (behavior changes of the end-users) than on their zone of control (features). They consider technology should help remove a limitation and simplify a system instead of automate the complexity of a manual one.

Uncertainty: Do you know what you don’t know?

Those teams consider they progress if they know better their customers day after day. A bug in an idea costs much more than a bug in software, so they need to learn as fast as possible and crash test their ideas by experimentation. They build the software in order to learn and measure data from real use of the software. The knowledge creation process is accelerated if they deliver fast a minimum set of features prioritized by the goal they want to reach.

Tradeoffs: How do you maximize value-for-money?

They don’t think there is “one best way” for the solution. They search and try the best alternatives to solve the problems. They don’t hide their assumptions with a large scope of features and prefer a minimalist approach with minimum set of features.

Speed: Can you reach your goal faster?

Those teams think the best solution doesn’t come with more time and the problem they try to fix will also change with time. Thus the only way to fit the market is to deliver as fast as possible, in a continuous way if possible.

Synergy: Does the team share the same vision?

The four concepts described above are sometimes counter-intuitive. That’s why they need glue in the middle with leaders who always challenge and avoid status-quo. Teamwork and team empowerment are key success factors to avoid sub-optimization and find the best trade-offs.


What about Patterns?

We have collected 4 patterns for each concept. A good pattern appears when someone says “that’s exactly what I am already doing and it works!”. We have not created anything new, in our quest for the right software we have:

  • Searched for practices successful teams were using
  • Experimented them
  • Selected the techniques that were working and identified the associated patterns


A pattern is there to be implemented in different ways (with different tools), but the objectives stay the same. They are also there to be combined with each other.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>