A "Post-Agile" Post: "If it works, do it. If it doesn't, don't".

I like simple rules of thumb. I found an article this morning with a very simple approach to the software development life cycle: "If it works, do it.  If it doesn't, don't".

Of course, it's not exactly that simple.  What does "works" mean?

I would define "works" as delivering products that people want to pay money for at a high enough quality to meet the business value of the customer and the ethical standards we should value as technical professionals.

Underlying that is customers are paying enough money in relation to what the software company is paying its workers.  So on the revenue side, we need

• Good market research people.  
• Good sales and good marketing people.  
• Good customer service folks. 

All are making sure that we understand the problems customers are facing and that the customers are and feel valued and heard.
Also underlying the simple approach is we are efficient at delivering the software on the cost side. 

• Development/QA and product management work super closely together so that there is no question what the customer wants and why. 
• We only deliver what the customer needs or have strong evidence that they want.  
• Developers are all focused on current customer needs, paying down any technical debt that's accrued in the past that threatens the current value of the product, or researching future technological trends -- what customers don't need now but will in 1-5 years.  
• QA is empowered to ask questions from the beginning and in a position to find issues quickly after they're introduced.  This prevents Development/QA from having to spend time identifying, fixing, patching, and retesting issues after the initial release.  
• Nothing is done without the customer in mind.  No documentation that doesn't directly serve a customer or promote good understanding of the product within the company.

We still need continual, honest assessment of what we're doing that's "working" and what is "not working".  But by taking the simple approach we focus less on blindly following and enforcing specifics of a process (even an Agile process) and more on the understanding and internalizing of what "works", particularly how each of our roles and interactions contribute to the value of the product.