http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660This got me thinking about [Kanban](http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html), where there is no such thing as iterations, but it's still Agile. How would you feel about using this approach instead of iterations? http://ayende.com/3601/that-agile-thing#comment12http://ayende.com/3601/that-agile-thing#comment12Sat, 27 Sep 2008 19:24:37 GMT@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. http://ayende.com/3601/that-agile-thing#comment11http://ayende.com/3601/that-agile-thing#comment11Wed, 24 Sep 2008 12:50:12 GMTThis 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. http://ayende.com/3601/that-agile-thing#comment10http://ayende.com/3601/that-agile-thing#comment10Mon, 22 Sep 2008 15:05:27 GMTto Domingos: is it possible to split your system into several parts with well defined interfaces so that you can deliver these components independently? http://ayende.com/3601/that-agile-thing#comment9http://ayende.com/3601/that-agile-thing#comment9Mon, 22 Sep 2008 04:02:12 GMTDo 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. http://ayende.com/3601/that-agile-thing#comment8http://ayende.com/3601/that-agile-thing#comment8Mon, 22 Sep 2008 03:55:42 GMTHi, 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.... http://ayende.com/3601/that-agile-thing#comment7http://ayende.com/3601/that-agile-thing#comment7Mon, 22 Sep 2008 02:05:40 GMTYea, 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 http://ayende.com/3601/that-agile-thing#comment6http://ayende.com/3601/that-agile-thing#comment6Sun, 21 Sep 2008 18:41:35 GMTto 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. http://ayende.com/3601/that-agile-thing#comment5http://ayende.com/3601/that-agile-thing#comment5Sun, 21 Sep 2008 08:40:56 GMTWhat 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 http://ayende.com/3601/that-agile-thing#comment4http://ayende.com/3601/that-agile-thing#comment4Sat, 20 Sep 2008 22:32:45 GMTI 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. http://ayende.com/3601/that-agile-thing#comment3http://ayende.com/3601/that-agile-thing#comment3Sat, 20 Sep 2008 21:51:38 GMTGreat post. The problem is that Agile is nebulous and means very different things to different people. Here is an article I wrote recently about the lack of clarity behind Agile development. [grahamnash.blogspot.com/.../...-lean-feedback.html](http://grahamnash.blogspot.com/2008/09/agile-lean-feedback.html)http://ayende.com/3601/that-agile-thing#comment2http://ayende.com/3601/that-agile-thing#comment2Sat, 20 Sep 2008 19:35:41 GMTSo 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. http://ayende.com/3601/that-agile-thing#comment1http://ayende.com/3601/that-agile-thing#comment1Sat, 20 Sep 2008 19:31:12 GMT