One thing that attracted me to the OutSystems Agile Platform was the development lifecycle; the product is designed from the ground up to encourage Agile practices. You don't have to use something Agile to work with the system, but it enables Agile methodology very well. Here's a walk-through of the lifecycle of a typical project with Agile Platform that works great for me. (Note: Others in the ecosystem may do things differently.)
An iteration is a defined block of time to perform development work as a complete unit. On my projects, I find an iteration that is based on 10 hours of estimated development work is just right. At the beginning of an iteration, I sit down with the client, review their list of desired changes, and provide a rough time estimate for each item; this includes the testing/fix time (I guesstimate that for every eight hours of development, I need two hours of testing and fixing). The client selects what will fit into 10 hours based upon their needs and priorities, and then I get to work. When I am done, I demo the functionality back to them. If they are happy, we deploy it to their Staging server for their testing. Any bug fixes ("doesn't work as spec'ed") I do as part of the iteration. Any changes ("spec doesn't match needs") goes into the request bucket. In general, iterations have a turnaround time of one week.
You might think 10-hour iterations are rather short, right? Well, not really. First and foremost, I do this work on a freelance basis; I do not want a situation where if I go over the 10 hours that I'm burning the candle at both ends or being an absentee husband/father. A 10% overage on a 10-hour iteration is one hour; it's four hours for a 40 hour iteration! Secondly, I've found that the Agile Platform is so efficient for me, that I can do in 10 hours what most full time developers need a full work week to accomplish in ASP.NET or a similar technology. As a result, my bill comes in much lower than a typical developer's for the same workload, even though I charge a tidy sum per iteration. Thirdly, it's been my experience that estimation mistakes tend to snowball very easily. A 10-hour iteration constrains that issue. In addition, 10 hours of development work is small enough that the work can be quickly and easily spec'ed out, without much need for changes in the middle of development. Finally, with the number of features done in one of my iterations, the customer wants a chance to review things before choosing the next set of features to implement or changes to make.
Initial project discussion
One thing I refuse to do is provide an up-front estimate. At best, if I think the project can be done in three or fewer iterations, I will tell the client. Some customers do not like this, because they want to see a "guaranteed" price and timeline. I remind them about the other "guaranteed" projects they had with other vendors that quickly went over time and budget, and gently explain that in the world of development, nothing can be guaranteed. When they see that my iteration methodology keeps their costs constrained and doesn't give me free reign to ring up a huge bill, or create a situation where I need to "descope and declare victory" to make a profit, they are usually sold. For a customer who cannot be convinced of this, I do not play ball. I simply do not have the time or the energy to spend on contracts that I know will be hard to make a profit on.
Beyond that, I use this period to get a good idea of the client's up-front needs, particularly to understand their future roadmap ideas to ensure that the application architecture makes it realistic.
As alluded to, I like to demo the work on my servers first. I have a server that my customers can access. I recommend to my customers that they have two servers -- one for Production and one for Staging -- but it's not the end of the world if they cannot afford that. Nicely enough, high-end Agile Platform licenses include a not-for-production-use license, and I believe that the cloud offering from OutSystems does as well. Otherwise, the client is free to experiment with the project on my server.
Once the client is happy with the results, I deploy to their systems. Agile Platform makes the deployment really easy. Typically, I just need to log in to the Web-based administration, upload the single OML or Solution file (depending upon how I am working), and after it uploads and compiles it is ready to go. All of the database schema changes are handled automatically. I should use the "Solution" approach because it lets me cut a single, unified file with all of the extensions in it, but since I rarely change extensions, I tend not to in order to reduce file size.
Sometimes a new version will require some data to be inserted into the database or otherwise manipulated. For example, in one project, each customer account has a list of statuses that they can use for workorders. The list can be customized, so when the account is created, it gets copied from a master list. Sometimes I need to inject a new value into that list for a new feature. Instead of needing direct database access, I create an Action that handles the data manipulation, and then tie it to a Timer with no defined schedule. After deployment, I manually trigger the Timer to run from the Web-based Service Center, and once it has run, I disable the Timer. I make sure that future versions remove the Action and Timer completely. As a result, the only times I need direct access to the database are low level data checking or fixing.
To make life easy for all involved, I charge a flat rate per iteration. It's a fair rate for the customer, especially considering that any bug fixes are handled for free as part of the iteration. If the iteration goes significantly over time, that's my fault for estimating poorly and it's a good lesson to me. If I'm way under, I offer a "low price guarantee": once the customer signs off on the work and is ready for invoicing, I charge them an hourly rate if the true time spent on the iteration (from top-to-bottom, including planning, review, deployment, fixes, etc.) is under seven hours. This lets the customer know that I am not chiseling them, and provides me with great incentive to plan properly.
Since I started doing consulting work with Agile Platform in early 2011, I have learned a lot of lessons. I had one project become much more work than I intended because the scope of work for the initial iteration had too many open questions at the beginning. I did not ask enough detailed questions up front to realize that the proposed algorithm had a lot of logical inconsistencies, and it ended up getting implemented and re-implemented a number of times. That is a classic programming error that I hope I do not repeat. But for the most part, the short iterations plus flat-rate pricing have done a great job at insulating all parties from the hazards that per-hour and fixed rate contracts typically have.
Justin James is the Lead Architect for Conigent.