Agree, and focus more on discovery since in *delivery* you have 4 problems: 1. Requirements will change, 2. Requirements are never complete 3. It’s impossible to gather all requirements in beginning 4. You don’t have enough time or $$$ to do everything
This quote is typically the basis of proposing agile software development over traditional software development. While there is some truth in the principles stated there, there is a fundamental flaw.
If the development work has no deadline, no not to exceed budget, no Minimal Viable Capabilities in the sense of MVP's meaning without these Capabilities being there Features we cannot Go Live on the needed date for the needed budget, then the phrases in the quote may be applicable.
But if the development work is a Project is a fixed period of performance (with margin), for a fixed (with margin) budget, and a fixed set of Capabilities, then the question is can agile be used to develop the software?
The answer is, of course, it can and it is done every single day in many domains I work in. Ranging from embedded flight control systems for winged vehicles to orbiting spacecraft, to Software Intensive System of Systems from industrial, business, insurance, and financial systems.
But these developments are not Products in the sense of the term used by agilest. They are projects in the sense of the term defined by PMI
A project is a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.
When an agile advocate says, software development is a product, not a project, and provides all the reasons why the thought process needs to switch from project to products, they may be unfamiliar with how many businesses actually work. In the product development world, the funding, recording of revenue, management of staffing at the financial level is managed as a Project. FASB 86 is an example of how cost and revenue for internal software development are recorded on the balance sheet.
Financial Accounting Standards Board (FASB) Statement No. 86, Accounting for the Costs of Computer Software to Be Sold, Leased, or Otherwise Marketed, applies to the costs of both internally developed and produced software and purchased software to be sold, leased, or otherwise marketed.
Projects build Products on the Balance Sheet. Developers may be working on a Product, but the CFO is recording the work as a Project that has a bounded period of performance, a bounded budget, a bounded set of Capabilities, from which revenue will be generated.
So those loud voices shouting software is product development, may very well hold that view from their position in the firm. But for those signing the paychecks, that is not likely the view.
What Does This Mean for Agile?
Agile shouldn't care. Agile produces useful working software at the end of every Sprint. If that software is not put into the hands of those paying for the software until some release date, those writing the software shouldn't care. The software is still useful. It's likely useful to the Staging and Pre-Production manager. The software is ready for use by someone internal or external to the firm, but regardless of the end uses location the software is still ready for use.
To separate project from the product is a developers point of view, it is not a business point of view.
When you hear that they are separate, and we need to move to a product point of view, you're likely talking to a coder, that hasn't taken that Managerial Finance class in his educational institution. For us in the Finance and Business Operations side of writing software for money, it's a moot point.
Go write code that every few weeks produces value to the next step in the process. That next step could be the end user in some distant land, or it could be the Systems Integration Testing staff down the hall, who in turn produce useful outcomes to the User Acceptance Testing staff across campus, who in turn releases the working UAT code to the customer around the world.
If the agile development team of 6 people sitting in the same room with their end customet who will start using the working software every few weeks for their business, there is no differenc in principle from the team of 6 people who have never met their customer except through the Product Owner who comes from downtown every 3rd day to sit with the team, and who has a go live date for the working system this coming December (7 months from now) and on that date, the customer will have been trained, all the external and internal interfaces to other systems will have been end-to-end verified and validated, and a new system will be avaialbel for those strangers who didn't even know something new was coming.
So before listening to any conjecture about how agile should be done or not done - establish a context, a domain, a business and technical process, the external and internal business, technical, and financial governance process.
You're not going live with working software every few weeks for DO-178 flight control system in the same way you can go live every few hours for a sports photo sharing web system. Both ends of the spectrum can and do use agile software development processes. Don't confuse the business process with the everyday software development processes.
