Abstract
In the past, a long waterfall-style development was briefly punctuated by the delivery of documents such as the design documents and status reports. It finally culminated with the real end goal—the software delivery. The documents were often seen as the proxy for the real product because nothing else was available to communicate progress through the long dark phases proceeding the final delivery. Needless to say, these documents often had no correlation whatsoever to the actual product or its quality. A status report could at best only communicate the past (which everyone already knew!), but never really predict the future in ways that would be meaningful to the product development team and the customers so that they could collectively re-plan their activities to align with the evolving dynamics of a project.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
- 2.
“Configuration Management,” www.dsdm.org/content/24-configuration-management .
- 3.
“Continuous Integration: How to Avoid ‘Integration Hell,”’ https://dzone.com/articles/continuous-integration-how-0 .
- 4.
“Continuous Integration,” http://martinfowler.com/articles/continuousIntegration.html .
- 5.
Velocity 2011: Jon Jenkins, “Velocity Culture,” https://youtu.be/dxk8b9rSKOo
- 6.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2015 Tathagat Varma
About this chapter
Cite this chapter
Varma, T. (2015). Deliver. In: Agile Product Development. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-1067-3_7
Download citation
DOI: https://doi.org/10.1007/978-1-4842-1067-3_7
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-1068-0
Online ISBN: 978-1-4842-1067-3
eBook Packages: Professional and Applied ComputingProfessional and Applied Computing (R0)Apress Access Books