The most important way to increase productivity in Software Development.

Software development is hard and expensive. Most projects run over budget and fail to deliver business or market value. People try all sorts of methodologies, team configurations -- on-shore / off-shore, different levels of QA & product management; engineers use different technologies, apply different architectural patterns (MVC, MVVM, DDD, RIA,  CQRS, micro-services). 

So what's the most important thing? After 20 years, I have 1 unequivocal answer: 

YIELD

Though a simple concept, you won't hear much about it. I never did. I discovered it from a completely different industry: Real estate development's notion of ROI (return on investment).

ROI = (Net Profit / Cost of Investment) x 100

Basically the idea is to capture as much Business or Market Value with as little effort as possible. In real estate development, you want as much profit with the least cost (land + build out costs).  All real estate markets are different; in some places you need to build modern homes while others are more traditional -- there are many ways to architect and build homes just as in Software Development. 

One BIG difference b/w real estate & software:  when a real estate developer designs their product, they ALWAYS consider the topology of the site -- meaning, they design the building while considering the land. 

Example: I recently built homes on a very steep hill, so we worked with the architect to build a 4 story house that would require as little excavation as possible. Why? Because buyers don't appreciate excavation -- they don't care if you had to move tons of earth to make the house design possible. They care about the house!

As simple as this sounds, time and again I've seen Product Management dictate software designs without considering how hard the development would be. 

Sure, SCRUM has poker planning, during which the developers indicate the "COST" or complexity of a feature. And, almost always, product management accepts the cost as an absolute truth. This is where YIELD suffers most.

Typically Product Management & Engineers do not work together to come up with the least costly way to capture value.

Engineers accept the design, and Product Management accepts the cost. Imagine building a house without considering the terrain up front and then react to the terrain over the course of the project. The design of the house would look like similar to many software products.

Instead, Product management should work with engineering to understand the complexity & cost of their proposal and then change the design to come up with the HIGHEST YIELD (value given cost).

In this way, the complexities can be used to build a less expensive product with a far more valued result.

But software is different than real estate, right? Not necessarily! Was Toyota Production Systems (automobile manufacturing) different? Absolutely not; the Poppendieck's & many others realized the principals were one in the same.

YIELD = VALUE / COMPLEXITY

This one equation could change software development as much as TPS/Lean has. 

Rather than Product Management asking "How complex is this?", they need to ask, what's the easiest way we can capture "X" value? The whole notion of USER STORIES destroys the NEGOTIATION that should occur between business and development. 

We should be talking about business value not features.

This in no way reduces the importances of good engineering, UEX or product design, but rather makes explicit what has long been assumed: Teams will work together for the optimum outcome.

Ask yourself this: How many times have engineering negotiated making features differently to reduce complexity while capturing the intended business result/value?

In my 20 year career, I have rarely seen it. Much of my career has been spent getting people to understand this... that you can increase valued productivity.

The goal is  not to: fully utilize people, have people work hard, to produce as much complexity as possible.

The GOAL is to produce highest VALUE at PEAK YIELD.

Once Developers & Product Management co-design features / product to capture VALUE with lowest complexity, the resultant valued productivity eclipses all other measures.

Why don't people do this? Because it's HARD and requires the most essential element in software development: TRUST

Product management and engineering have to TRUST that each other negotiate in good faith. They must RESPECT each other's opinions. They must EMPATHIZE with each other's objectives -- engineering wanting sound technical design and product management wanting UEX and business value.

YIELD = VALUE / COST

More valued velocity can be produced through design negotiation than scaling teams, technical architecture, etc...

Consider WhatsApp (https://www.whatsapp.com/) -- acquired by Facebook for $19,000,000,000 (19 Billion). They're serving 500,000,000 users with a development team of around 50 developers. They currently serve over 1,000,000,000 (1 Billion) users with less than 70 developers. That's AMAZING!

How did WhatsApp do it?

They have amazing engineers, no doubt. They use a fantastic, alien like technology that scales better than almost anything else: Erlang. No doubt these contribute, but just as important -- and in my opinion, most importantly, they have very carefully chosen WHAT THEY BUILD.

WhatsApp's product design is fiercely focused on the value of messaging and not complex bells and whistles.

WhatsApp understood that "what they decide to build" was as or more important than how or on what technology they built it.

BUILD VALUE not COMPLEXITY

Focus your teams on YIELD... not just velocity, UEX, ....

YIELD should be a manifesto all it's own!

Y = V / C

Resources:

• Taichi Ohno: https://en.wikipedia.org/wiki/Taiichi_Ohno
• TPS: https://en.wikipedia.org/wiki/Toyota_Production_System
• Agile Manifesto: http://www.agilemanifesto.org/
• Speed of Trust: http://www.speedoftrust.com/ (thanks to Neal Reizer for introducing me to this book)