Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

That Agile Thing

time to read 2 min | 367 words

Agile introduction is an interesting problem. One that I have learned to avoid. I am not feeling comfortable standing up to a business owner and saying (paraphrased, of course), "if you will do it my way, your life will be better". At least, not about development methodologies, I have no problem saying that about techniques, design or tools. The reason that I don't feel comfortable saying that is that there are too many issues surrounding agile introduction to talk confidently about the benefits.

I usually never mention agile to the customer at all. What I am doing, however, is insisting on a regularly scheduled demo. Usually every week or two. Oh, and I ask the customer what they want to see in the next demo. Given that I have a very short amount of time between demos, I can usually get a very concise set of features for the next demo.

Having demos every week or two really strengthen the confidence in the project. So from the point of view of the customer, we have regular demos and they get to choose what they will see in the next demo, that is all.

From the point of view of the team, having to have a demo every week or two makes a lot of difference in the way we have to work. As a simple example, I can't demo a UML diagram, so we can't have a six months design phase. Having to accept new requirements for each demo means that we need to enable ourselves to make changes very rapidly, so we go to practices such as TDD, Continuous Integration, etc. It also means that the design of the application tends to be much more light weight than it would be otherwise.

In other words, everything flows from the single initial requirement, having a demo every week or two.

Once you have that, you have a free reign (more or less) to implement agile practices, as they are needed, in order to get the demo up and running. You get customer involvement from the feature selection for the next demo, and you get customer buy-in from having the demos at frequent intervals, always showing additional value.


Neil Mosafi

So how do you handle charging the customer when you don't discuss with them (up front) that you are going to be running the project in this way? Usually they want to know before the project starts how much it'll cost and what they'll be getting for that money.

One often has to convince clients of the benefits of the agile approach before they'll come round to a different way of thinking.

John Rayner

I agree fully that the idea of regular demos of working software, with the customer choosing priorities for the next demo, is the core driver for anything you can call agile. All the other practices (CI, TDD, SoC, etc) all simply help to achieve this.

I actually don't think that these practices are what make a project agile (is that heresy?). If a project is not regularly demo'ing functional software with customer-driven priorities, then I can't see that it can call itself agile, even if it has CC.Net+Svn+xUnit+whatever.

grega g

What is the customer buying? The program or the code? If former, than he shouldn't really care weather you do it agile or put all the code in main method, as long as you deliver.

grega g


to grega: well that's true but realize that once your project gets more complex than saying hello world, tools like unit tests or good decoupled design helps you to to deliver new changes faster and safer.

grega g

Yea, I know.

I was saying that as long as client doesn't see the code, he doesn't need to be explained about agile. Just use it.

grega g


Hi, this is a smart strategy to get an agile process up and running. You seem to have gotten the reason behind agile: deliver early, deliver often, get early feedback, react to changes in requirements.

I only wish I could do the same at the place I work, but unfortunately, I have a large system that is used by a trading desk, front office, back office, plus has integration with upstream and downstream systems. 1 week iterations are simply too short. Plus, we don't have 1 'customer', we have several stakeholders at our customer all with their own ideas of what is higher priority....

Ayende Rahien

Do two weeks demos, if one is too short.

Get someone that has the final say in the matter. There has to be someone like that, even if they are just there to settle disputes.


to Domingos: is it possible to split your system into several parts with well defined interfaces so that you can deliver these components independently?


This is brilliant. It allows you to implement the heart of Agile by selling the direct customer-perceived benefits. If the customer is interested in more detail, they'll ask. Until then, they reap the benefits and you can pick your battles more carefully on ancillary issues as needed--giving you a free hand and ability to implement whatever methodologies you deem most appropriate.


@Neil Mosafi

I have been doing the indepedent contractor thing for 14 years and this is exactly how I work. I usually cut it even shorter. I ask for the next feature and upload daily builds. Whether they have time to review the builds or not is up to them.

Once a business starts working with a contractor this way they get spoiled and forget about the $$$ and start focusing on the value the software is delivering because they feel in control of the process for once.

It's a win / win because the business gets great software and the contractor feels great about what he has written - and most importantly, you get a repeat customer.

The best thing about repear customers is - you dont have to train them a second time. They know you you work and it's they love it.

Jon Arild Tørresdal

This got me thinking about Kanban, where there is no such thing as iterations, but it's still Agile. How would you feel about using this approach instead of iterations?

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats