Agile Software Development is rooted in Agile Manifesto and Agile Principles. It is all about delivering working software at regular intervals in order to provide visibility and predictability. It is also about embaracing changes. Agile requires discipline, focus, team work, conviction and courage. I started a series of Distributed Agile Blogs couple of months ago. Going forward, I will be writing more on this.
Agile methodologies such as XP, Scrum etc. work well in Time and Material (T&M) model. It has been a big challange to harness such projects in Fixed Price model. How can stakeholder commit to Fixed Price and execute projects that involve agile principles? Agile and Fixed Price: Can they go together? These questions are just the beginning. If we dig deeper, we come across distributed teams that work across time zones and cultures. Executing agile projects with distributed teams has become a common theme across several companies. However, combining agile or distributed agile with fixed price has been a bigger challenge.
My recent paper on Fixed Price Distributed Agile shares a case study on this topic.
2 comments:
By being too rigid in word-by-word meaning of Agile manifesto sometimes one does digress from the Intent.
To me Agile-ways of software development (multiple usable release in agreed sequence each with agreed set of functions) disciplines structured development activities in continuous integration/testing mode thus reducing the defects-insertion, because every release mandates retesting of all the function till then released.
This is independent of T & M or fixed price because those are mode of payments which in case of fixed-price can be agreed as release based payment. Customer's intent in fixing the total price is to limit the outflow within his budget and actual utilization of this budget is a matter of definition at the time of contracting the assignment. However fixed-price projects demand lot of discipline from development team so as to avoid waste of efforts.
Normally customer would agree to testing of releases because then he gets to tweak his requirements towards subsequent release. This method does not necessarily means extra work. Actually in Agile-ways you tend to save lot of rework because of its inherent characteristics.
If the customer does not agree to test each releases you can define an internal customer for this purpose.
Absolutely! Having a customer who has the commitment to collaborate and participate at regular intervals is critical! Thanks for sharing your views!
Post a Comment