It seems so simple -“working software.” : What’s not to like? Way preferable to that other kind of software that – you know, doesn’t work. Between the Agile Manifesto and its twelve principles, that phrase is used three times. Working software is not the cheese on Agile’s macaroni – it is the macaroni.

What’s not so simple is getting consensus on how to define that phrase. Enter “definition of working software”, with the quotation marks, into Google, and you’ll see lots of opinions on how it should be defined. And who should define it. Here are some potential definitions

The reasonably Agile marketer – test-proven iterations of software with functionality and results consistent with my requirements and agreed-upon changes.

The sort-of-not-really Agile marketer – test-proven software with complete functionality as per the requirements document (the whole enchilada, pages 1 through 117 plus the appendix) and results consistent with my original vision two Aprils ago.

The cowboy marketer – I don’t know much about working software, but I know what I like. What I’m saying is I’ll know it when I see it. Oh, and p.s. — that ain’t it.

The responsible Agile developer – test-proven software with functionality and results consistent with my business owner’s requirements and agreed-upon changes.

The sort-of-not-really Agile developer – Who the hell knows? It will be working in Phase…9? 10? Actually, I’m kinda in the weeds, bro. Ask me next Memorial Day.

The cowboy developer – It worked last Tuesday. It looks freakin’ awesome. Competent users will figure out the navigation.

The definition of working software is a contract between the business side and the development side. Are you working without a contract?