Lean Architecture

Lean, agile, architecture… This book’s intention is to teach us about lean architecture for agile software development, how we can use the planning values of lean to drive the inspect-and-adapt (short feedback loop) principles of agile.

This first chapter clarifies the concepts of Architecture, Lean and Agile and why we need Lean Architecture.

In today’s fast-paced world, change is the most stable constant.

In order to thrive, a product must swiftly adapt to changes. For this reason, we need Agile methodologies, to have a project (and the team developing it) embrace change and react to it fast to give the product a competitive advantage and keep it in the game.

However, it is difficult to reshape a system if it is cramped with clutter, if to change part of it, we need to change other unrelated parts who might not even be in use. And here enters Lean.

Lean practices help us get rid of the clutter so we can use agile practices to focus on quickly delivering value to the end-user, by delivering basic functionality and iterating on it to deliver better quality.

Architecture

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that define the structure of the system and where everything else will be built on top of.

The architecture is responsible for deciding the systems:

• Components
• Relationships between components
• Principles guiding the design and evolution of components and relationships

In other words, these are the design decisions that are more and more difficult to change as the system evolves, it’s the foundations that give support to feature development. (pg. 2)

Lean

Lean is a production management methodology developed by Toyota during the 20th century and explained in the Toyota Way (Liker 2004).

Its goal is to reduce waste, inconsistency and irregular production/development.

Its core principles, when in comes to software development, are:

• Lightweight upfront architecture, to reduce waste in rework (from inadequate planning), unused artefacts (unused documentation and code that “will” [NOT] be useful later on)  and “wait” states (global review processes);
• All hands on deck, (everybody, all together, from early on) meaning that all stakeholders (domain experts, customers, developers, testers, managers) should be involved in the initial planning stage of the production. This helps clear possible misunderstandings before starting production, and save resources otherwise wasted producing something that is not what is needed, in rework of a product poorly planned;
• The end result should reflect the end user mental model of the product, how he needs it to be, how he dreams of it. Because in the end, and independently of technical quality, a product is only as good as its users consider it to be. There is no other reason to build a product;
• The partial product components will be delivered just in time, meaning, only when is needed and only what is needed at that moment. In other words, it’s about doing what is needed now (which depends on the planning scope, maybe this sprint target or this quarter target) to keep you in the game for the long run, it’s about carefully planning and slicing the design to deliver exactly what is needed in order to support feature development in the long run;

Agile

Agile has its foundations on the Agile Manifesto (Beck et al 2001).

In an agile methodology, solutions evolve through collaboration between self-organizing, cross-functional teams utilising the appropriate practices for their context.

Its goal is to create better software, faster, using end-user engagement, short feedback loops, and eliminating waste.

The 4 key values defined in the agile manifesto are:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The agile manifesto 4 values

And the 12 principles that support those values are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The agile manifesto 12 principles

Lean & Agile

Lean and agile contrast in some points, making them complement each other towards the common goal of quick and constant value delivery to end-users:

Lean Long and careful deliberation followed by quick deployment	Agile Rapid decision making
Thinking and doing Plan and design the project form Continuously improve the process	Doing Build the base structure and features on top of the planned form
Inspect-plan-do Analyse the global problem at hand Plan in broad strokes (lightweight) Build the minimal foundational form and structure of the project	Do-inspect-adapt Build a feature in a first iteration approach Inspect the result with user feedback Improve the feature with a second iteration
Feedforward and feedback Design for change and respond to change, by having a carefully thought but lightweight plan, and being able to promptly rethink the plan if/when the need arises	Feedback React to change, by quickly delivering features and iterate to deliver the changes required by the given feedback
High throughput	Low latency
Planning and responding Have a carefully thought but lightweight plan, and be able to promptly rethink the plan if/when the need arises	Reacting Quickly deliver features and iterate to deliver the changes required by the given feedback of the previous iteration
Focus on process Think about the process, both the development pipeline and system / product broad strokes (the high level design, the form)	Focus on people Communication is key, so constantly use end-user feedback and team members interaction to improve the product
Teams Working as a unit	Individuals The interactions between all stakeholders (domain experts, customers, developers, testers, managers, end-users)
Complicated systems Make decisions on what to build, and the broad its strokes	Complex systems Make decisions on how to build it, its implementation detailed design
Embrace standards Define standards so that those decisions are out of the way when developing the system	Inspect and adapt Get feedback from previous work and rework on it to improve its quality
Rework in design adds value Rework in making is wasteAdjust the high level design when requirements change, but plan carefully to avoid rework derived from poor planning	Minimize up-front work of any kind and rework code to get quality Assume nothing, build the minimum functionality required for a feature and get end-user feedback as soon as possible to increase quality
Make decisions before work Make structural decisions before starting work to avoid repeatedly revisiting the decision making process while developing features, ie coding standards, command bus architecture, etc.	Delay decisions as much as possible Only build something in a specific way, when we really need it

This post is part of a set of posts with my personal notes about all the chapters in the book “Lean Architecture for agile software development” by James Coplien and Gertrud Bjornvig. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.