Core Principles of Lean and Agile

living — created 2022-05-02 — updated 2023-01-07

I’ve learned constantly throughout my software career, that if you are part of a team building software, you must be willing to work constantly to push the team towards agile and lean ways of working. Teams tend to drift constantly away from these effective ways of working. I created this documentation of the core principles to make sure I can always communicate the core of what is important.

I — Contents ^toc
II — Lean Principles
III — Agile Principles
IV — Further Reading
V — References

I — Contents ^toc

II — Lean Principles

Lean software development is a set of principles that aim to produce better results by eliminating unnecessary work through learning and end-to-end optimization.

The below principles are paraphrased from Marty Cagan (“Beyond Lean and Agile”).¹

Principle 1: Risks are tackled early

Risks are tackled up front rather than at the end. We tackle these risks before deciding to build anything or by building as little as possible before the risks are minimized.

First, tackle these risks:

value risk (whether people will buy it)
business risk (whether this solution also works for our business’s various aspects, like financial, contractual, and legal).

Then tackle these risks:

usability risk (whether people can figure out how to use it)
feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)

We always reduce risk as early as possible by developing MVPs, especially value risks and business risks. We do this because any time spent building something before the risks are reduced will be wasted time if the risk later turns out to be fatal.

Principle 2: Product definition and design are collaborative and iterative

Products are defined and designed collaboratively and iteratively rather than sequentially.

DON’T DO THIS: First, the product manager defines requirements, then a designer designs a solution that delivers on those requirements, and then engineers implement those requirements, with each person unable to change the decisions made in the previous step.

INSTEAD, DO THIS: In strong teams, product, design, and engineering work side-by-side, in a give-and-take, to come up with technology-powered solutions that our customers love and that work for our business.

Principle 3: Focus on results, not features

Finally, it’s all about solving problems and results, not implementing features. Conventional product roadmaps are all about output. Strong teams know it’s not only about implementing a solution; they must ensure that the solution solves the underlying problem. It’s about results.

Clearly define and follow up on goals, using a framework like OKRs. The goals are the roadmap, not the features.

III — Agile Principles

Agile software development is an iterative approach to software development that helps teams deliver value to their customers faster and with fewer headaches.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The above is the original Agile Principles (Beck 2001),² which are as relevant today as in 2001!

You can sum it all up with:

“When in doubt: scope way down, shorten the timeframe, & make it a requirement that at the end something is shipped. Never fails to unlock creativity and impact.”

—Maggie Crowley³

IV — Further Reading

Marty Cagan. “Product vs. Feature Teams.” SVPG Articles, 29 August 2019, https://svpg.com/product-vs-feature-teams/.

Marty Cagan. Inspired. https://www.svpg.com/books/.

Erik Ries. The Lean Startup. http://theleanstartup.com/.

Kevin Albrecht. “Dual Track Agile: Focusing on Customer Value” Kevin on Code Blog, 31 August 2015, https://medium.com/kevin-on-code/dual-track-agile-focusing-on-customer-value-a2e39312585b.