Project Versus Product in Agile Development

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 the requirements in the beginning.
4. You don’t have enough time or money 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, and no Minimal Viable Capabilities in the sense of MVP, meaning without these?Capabilities being their?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 that?it can and is done daily 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 product, they may need to familiarize themselves?with how many businesses?work. In the product development world, the funding, revenue recording, and staffing management at the financial?level is managed as a Project. FASB 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 with a bounded period of performance, a bounded budget, and a bounded set of Capabilities from which revenue will be generated.

Those loud voices shouting about software is product development may 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 user's location, the software?is still?ready for use.

To separate?a project from the product is a developer's 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 who has yet to take 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.

Write?code that every few weeks produces value for 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 customer who will start using the working software every few weeks for their business, there is no difference 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 available 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 for the DO-178 flight control system every few weeks 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. Make sure to distinguish the business process from the everyday software development processes.