Working software over documentation is fine but ‘only’ working software and no documentation is not a good idea, especially in case of a business process driven applications. It may be acceptable to go easy on technical documentation but there is no justification for not creating and maintaining business requirement documents. Absence of documented business rules and processes creates an enormous amount of confusion, application is hard to maintain, it’s difficult to communicate changes and reverse engineering code to drive business rules is highly unproductive and wasteful process.
I believe the two primary notions that give agile edge over waterfall methodology are
- Built in process that encourages frequent and continuous review by end users
- Ability to keep everybody on toes with daily stand-ups and rapid deliveries
Waterfall assumed that it’s possible to plan everything upfront, agile goes the opposite way and assumes that things are always changing so it’s better not to plan. While frequent changes may be possible in some projects but it’s not always the case, specifically for the projects that are business process centric.
While agile acknowledges the importance of bigger picture during initial project estimation, preliminary release plan, backlog prioritization, technology selection and architecture, it looks the other way when it comes to application design and identification of reusable components. I agree certain projects could have uncertain requirements and putting too much effort in designing would be a waste of time and energy but there are projects in which requirements tend toward a level of certainty.
I feel with agile methodologies like scrum considerable amount of effort goes in refactoring the design/code each sprint because we tried to do just enough or simplest thing possible in one of the previous sprint refusing to acknowledge the bigger picture. Lot of this effort could be saved, if depending on the context of project more time and effort is devoted towards design when project starts. Dedicated design sprint in the beginning may not be a bad idea!
Fixed amount + Fixed deadline + Fixed scope + Change friendly = Team burnout
In most of the scenarios before committing to a project, customer is primarily interested in getting estimated cost with reasonable accuracy for given requirements. The calculation of cost for executing a project is derived with some calculation based on team size and timelines. The customer is confident that cost more or less covers the defined requirements and since project will be executed with agile so change would not be an issue! It’s quite possible that sales team of an organization may further enforce this perception if not deny it.
So now we have a project with fixed cost which was calculated on basis of a fixed team size and timelines. Customer’s perception is that most of the requirements are in scope because cost was estimated on basis of these requirements, so generally customer would be averse to any change in scope. Customer may be open to possibility of varying team size and timelines but any changes to these factors would have a direct impact on the margins of the project so not a good option for company executing the project.
To top it all customer holds the perception that since it’s an agile project changes would not be an issue, process will accommodate them magically when requested. Now imagine being a member of the team who is caught in this situation with frugal initial estimates! While I acknowledge that with waterfall a project runs bigger risk of failure but team is still protected from frequent changes, also customer understands change averse nature of waterfall, so it may be a bit easier for the team to handle the situation.
I personally do not think fixed bid projects fit well with the philosophy of agile, but since they are an uneasy reality we should go easy on selling the ‘change embracing’ attitude of agile and make sure that customer understands that even with Agile change has a cost, you put something in something needs to be pushed out!