Agile Architecture, Lean Architecture, or Both?

目录

Key Takeaways

Related Sponsored Content

Evaluating Stream Processing Technologies: A Comprehensive Guide for Enterprise Architects 

What You Need to Know About ElastiCache Serverless

An Introduction to Microservices Monitoring—Strategies, Tools, and Key Concepts

GraphQL and Data Products: A powerful pairing to streamline your data mesh journey

An Introduction to Stream Processing

Related Sponsor

MVPs, MVAs, and Empiricism

Agile, Lean, and Complexity

Agile, Lean, and Software Architecture

Conclusion

---

Key Takeaways

• Agile and Lean are not the same things. Agile is an empirical approach to delivering valuable increments of a product, while Lean is an approach to improving the flow of work by reducing waste and undone work, and improving cycle time.
• Lean is optimized for an environment in which requirements are mostly certain and the problem that needs to be solved is well-defined. The challenge with architectural work is that early in the product life cycle (and sometimes well into the product life cycle) the requirements that shape the architecture, which we call Quality Attribute Requirements or QARs, are not very well understood.
• Development teams need agile practices to validate the value that their MVP delivers and the design decisions they make to ensure that the product will meet its goals (the product’s Minimum Viable Architecture)
• Once the development team has validated the MVP and MVA and feels comfortable in their decisions, lean practices can help them to improve their ways of working.
• Premature or inappropriate use of Lean practices can hinder the evolution of the architecture by focusing too much on making the flow of work predictable and smooth. Until Quality Attribute Requirements (QARs) are fairly well understood, the architecture may undergo significant change and revision. This is not a waste but a reality of refining the development team’s understanding of the system’s QARs.
   

Over the years we’ve heard people refer to their architecture, or their architecture efforts, perhaps, as "lean and agile". This got us thinking about how lean and agile practices help a team to develop the architecture for a software product. Some people confuse the two and think of lean and agile being largely similar approaches. We think they are quite different, with different strengths and weaknesses especially as they relate to software architecture.  

Lean approaches focus on reducing waste created by ineffective development processes and practices, and reducing cycle time, having evolved largely in the manufacturing problem domain. While they focus mostly on the means and methods of product development, they also include mechanisms for incrementally improving the product.

Lean approaches assume that the organization mostly knows what product to build or what problem to solve, so it should primarily focus on reducing waste in building the known solution.

Related Sponsored Content

• Evaluating Stream Processing Technologies: A Comprehensive Guide for Enterprise Architects 

• What You Need to Know About ElastiCache Serverless

• An Introduction to Microservices Monitoring—Strategies, Tools, and Key Concepts

• GraphQL and Data Products: A powerful pairing to streamline your data mesh journey

• An Introduction to Stream Processing

Related Sponsor

​编辑

Hazelcast modernizes applications with a unified real-time data platform to act instantly on data. Learn more.

Some managers like Lean because it focuses on increasing efficiency, increasing productivity, reducing cost, and increasing predictability.

They look at software development as a kind of production line, and lean practices, with their roots in manufacturing, nicely align with this perspective.

This isn’t the focus of an agile approach. Agile approaches aren’t focused on efficiency, productivity, cost reduction, or increasing predictability, although all of these may be achieved as a side-effect of achieving the main goal of an agile approach: to rapidly determine whether the organization is building the right product.

In pursuit of this goal, teams do have to reduce waste to achieve rapid feedback cycles, which in turn reduces cost and improves efficiency, but these are means to a different end.

Image source

Like Alice asking the Cheshire Cat which road she should take, to which he answers "If you don’t know where you want to go, it doesn’t matter which path you take.", Agile answers the question "Where should the product go?" (i.e. what does the product achieve), while Lean asks the question "what’s the fastest and most efficient way to build the product?", assuming that the team knows which product they need to build.

So what does this mean for software architecture?

MVPs, MVAs, and Empiricism

The concept of the Minimum Viable Product (MVP) as a way to experientially validate whether a team is building the right product has been around for quite a while. In a series of articles, we have extended this idea with a related concept we call a Minimum Viable Architecture (MVA). We define an MVA as the small set of fundamental design decisions that the development team makes about the solution. This definition focuses on the sustainability, the long-term viability, of the MVP by considering how the product will meet its QARs in addition to its functional requirements while minimizing technical debt to achieve sustainability.

With both the MVP and MVA, the actual needs of customers and the technical decisions needed to deliver solutions that meet those needs are at least partially, if not mostly, unknown. Teams need to use empirical feedback loops to understand customer needs and also to gather feedback on whether their solution meets those needs. This is true for both the MVP and the MVA.

The MVP and MVA are also not one-time things; each release is really a set of MVP and MVA experiments that the team runs to better understand needs and deliver value. As a result, each release can be thought of as a new version of an MVP/MVA pair.

Agile, Lean, and Complexity

Dave Snowdon’s insightful Cynefin framework describes four kinds of problem spaces:

• Obvious, in which options are clear and consensus on cause-and-effect relationships is easily achieved.
• Complicated, in which there may be more than one "correct" solution, the choice of which requires expertise to diagnose and decide.
• Complex, in which there may be no "correct" solutions because they are too unpredictable to apply proven solutions or identify cause-and-effect relationships. Solving these sorts of problems requires an empirical approach of forming and testing hypotheses and adapting based on the results.
• Chaotic, in which there are no cause and effect relationships. The best one can do is to try to reduce the chaos and establish a degree of order and stability. Examples include emergencies and natural disaster response.

Lean approaches, with their focus on predictability, shine in working on obvious and complicated problems, where solutions are well-defined, or at least definable. When these conditions exist, where the solution or goal is well-defined, focusing on reducing waste, improving efficiency and speed, and improving predictability are important goals.

Agile approaches shine when working on complex problems when goals and solutions are not well-defined, where there are no clear solutions but only partial solutions with associated trade-offs.

This does not mean that there is no place for lean practices in solving complex problems. In the context of software development, for example, a lot of the work is still fairly simple or merely complicated, such as the process of building and testing software, especially using a continuous delivery pipeline, or reducing waste in hand-offs between teams. Building the right product is a complex problem, but building it right is merely complicated.

Agile, Lean, and Software Architecture

Creating an architecture for a software product requires solving a variety of complex problems; each product faces unique challenges that its architecture must overcome through a series of trade-offs. We have described this decision process in other articles in which we have described the concept of the Minimum Viable Architecture (MVA) as a reflection of these trade-off decisions. The MVA is the architectural complement to a Minimum Viable Product or MVP. The MVA balances the MVP by making sure that the MVP is technically viable, sustainable, and extensible over time; it is what differentiates the MVP from a throw-away proof of concept.

Lean approaches want to look at the core problem of software development as improving the flow of work, but from an architectural perspective, the core problem is creating an MVP and an MVA that are both minimal and viable.

One key aspect of an MVA is that it is developed incrementally over a series of releases of a product. The development team uses the empirical data from these releases to confirm or reject hypotheses that they form about the suitability of the MVA. They cannot determine whether the MVA is either suitable for its associated Minimum Viable Product (MVP), or viable over the lifetime of the product, without empirical data. The team needs feedback to address shortcomings and to improve the MVA in future releases. This empirical feedback cycle is ideally suited to an agile approach.

This work is inherently unpredictable because of the variety of different kinds of decisions the development team has to make, and because of the novelty of the work; team members are working on problems they have never encountered before, and their focus is not on efficiency but on effectiveness. Their effectiveness can be aided by using some lean principles such as reducing the number of things they are working on (WIP), or reducing wait-time, interruptions, or hand-offs, and they are certainly interested in reducing the length of time they need to get feedback, but they are not otherwise overtly concerned with optimizing their flow of work.

Lean is optimized for an environment in which requirements are mostly certain and the problem that needs to be solved is well-defined. The challenge with architectural work is that early in the product life cycle (and sometimes well into the product life cycle) the requirements that shape the architecture, which we call Quality Attribute Requirements or QARs, are not very well understood.

Lean also seeks to reduce waste, which is a worthy goal. The problem with architectural work is that the development team doesn’t know which decisions are correct and which are not without experimenting. Some of these experiments will provide data that tells the team that their decision was not correct. One could view the work they did as waste, but it provided valuable information that reduces future waste even more.

Lean approaches to software development are especially concerned with waste that results from the process itself, especially in the form of work that is started but not completed. This usually results from having too much WIP, but in software products there is a special kind of waste that results from postponing decisions, technical debt. Feedback from agile delivery cycles can highlight that technical short-cuts and postponed decisions are impairing the ability of the product to meet its QARs. When this happens, the development team usually needs to devote time to resolving technical debt and reworking the architecture. From a lean perspective, this disrupts the flow of work, but it's necessary to greatly reduce future waste resulting from a product that can’t sustain its value.

Conclusion

Organizations need both agile and lean approaches but for different reasons. They need agile’s feedback that the product they are building is meeting customer needs, and especially when the products don’t meet customer needs. They also need lean practices to root out sources of waste that impair their ability to deliver high-quality products in a cost-effective way. In this way, lean approaches complement agile approaches.

Development teams need agile practices to obtain feedback on whether the MVP and its associated MVA meet their goals. They need to use this feedback to improve the MVP/MVA in subsequent releases. If the MVP/MVA doesn’t meet its goals, focusing on efficiency and productivity won’t help the team deliver a better solution.

Once a team is fairly comfortable that they are building the right product, and that the product’s architecture is meeting its goals, the team can shift its focus to matters of efficiency, productivity, and cost, so long as it keeps in mind that every release is still an experiment that tests the value and the sustainability of the product.