As a company Srijan is slowly, steadily making the move towards Agile development. The whole process of Agile is great, but it seems it is ideally suited for Time-and-Material kind of projects where the customer and the project team have a HUGE amount of faith in each other - the sponsor feels that the development team has adequate technical competencies and integrity to give their reasonable best effort. The development team must trust the sponsor to continue to sponsor the team with adequate funds during the various sprints, and evolution of the product.

However, we do not live in an ideal world. Most (if not all) projects have a "fixed deadline", and "fixed budgets". Given this, what is the best way to manage an Agile development process within a defined end-date. This is challenge we're grappling with internally at Srijan.

Here's the scenario:

1. Sales sold a project with estimates done by an expert internally (not developers; but a CTO or a Tech Lead or both)
2. During our estimation process, we break down the project to as much detail as possible (i must mention here that this does really drain our sales and tech resources, as not all project pitches we make convert - obviously)
3. After much debate we agreed to ensure that we put the all tasks and key functionality - as has been estimated - into a macro-project-plan with the developers who are going to be working on the project; and share it with the client
4. This would ensure that  we are sure that the deadline we have sold is still achievable with the current team taking account of holidays (company and developers)
5. Ideally, at the project kick-off stage itself, a re-estimate of all tasks should be done
6. The challenge that we are seeking answers for - is that if we do re-estimate the complete project at this stage which may require detailed planning - then the process does not really remain Agile; it becomes a Waterfall method of project development and planning
7. The only Agile process then that remains, is within this larger/macro estimate where we can do detailed Sprint-planning
8. In this process then, we have to ensure that the sprints plan sticks to the larger project schedule as communicated to the client in the first place; and if slippages in this schedule are expected, then they are absorbed by the development team by working extra hard

This is our challenge, and part of our process evolution at our company. What are you thoughts? How are you making the shift to being Agile from Waterfall development processes? We would love to learn from our readers.