Architecture and Design Practices for Agile Project Management

Dr. David F. Rico, PMP, CSM

August 6, 2012

A major principle within lean and agile methods is “No Big Design Up Front (BDUF)”. Instead, agile teams promote the notion of evolutionary, emergent and iterative design. Proponents of traditional methods believe a comprehensive top-down architecture and design are tantamount to system quality and project success. However, the lean and agile community has since learned that large architectures and designs are a form of “waste.” That is, traditional teams over-specify the system architecture and design by gold-plating it with unnecessary features that undermine system quality and project success.

How do agile teams perform architecture and design? Is there such a thing? What are its associated practices? When is it performed? How much effort is applied? Try to remember some of the characteristics of agile projects. Their goal is to rapidly produce a precious few system capabilities and customer requirements that have the biggest bang for the buck. That is, produce something with high business value or great return on investment. Furthermore, system quality, project success and customer satisfaction are ultimately achieved by significantly reducing the scope of the system architecture and design.

Less is more for agile projects, which address a smaller scope and have fewer requirements and shorter time horizons. They focus on a few critical customer needs, business functions and capabilities. They are optimized for project success, system quality, customer satisfaction and business value. Conversely, traditional methods are based on the theory of comprehensive, all-encompassing architectures and designs to anticipate every conceivable customer need. However, “wisdom has proven right by her children” as traditional project failure rates were too high, resulting in agile methods.

Given these assumptions, the scope of an agile project is limited to a near-term release plan spanning nine, 12 or 15 months (give or take a few). Therefore, an agile architecture and design should be right-sized to fit the scope of the release plan and no more. This is true whether the architecture is created in a traditional top-down or agile bottom-up style. This means that an agile architecture and design can be visualized within the initial release planning phase when a lightweight plan is created--and the most business value to a customer is achievable. Here are some of the practices for agile architecture and design:

What’s the bottom line? Agile methods have just enough just-in-time emergent architecture and design practices for successfully creating products that satisfy customers and maximize business value. Emergent design minimizes effort, cost, waste, defects, schedules, poor morale, project failure and customer dissatisfaction. It is the antithesis of the traditional all-encompassing, top-down “big design up front (BDUF)” to prematurely anticipate unarticulated customer needs. Big upfront architecture and design is done to lower costs and increase system quality, although it has proven to have the opposite effect.

Emergent design is an efficient and waste-free practice for creating today’s complex systems. However, it is important to note that its success rests on other interrelated practices. Some of these include prior experience, release planning and iteration zero. Oftentimes, developers have inadequate experience, are unfamiliar with release planning or don’t realize the value of standing up an operational IT infrastructure. Sometimes, project leaders do not understand the importance of release planning, creating and communicating crystal-clear vision statements or the critical role they play in day-to-day design.

A few books that come to mind include Planning Extreme Programming by Kent Beck, Agile Estimating and Planning by Mike Cohn and Agile Project Management by Jim Highsmith. Kent’s book gives a 40,000-foot overview, Mike’s book provides step-by-step guidance and Jim’s book provides an overarching framework for adapting release planning to larger and more complex projects. Although there are a few textbooks available on emergent design, just-enough architecture and even lean architecture, the principles of “evolutionary design” as it applies to agile methods have yet to be fully articulated.

In spite of the promise of emergent design as it applies to agile methods, customers, project leaders, developers and other critical projects, stakeholders are not perfect. Essential non-functional requirements often go unidentified and undocumented. For instance, security, usability, performance, maintainability, scalability, reliability, availability, safety and other critical system characteristics often go undefined. Security requirements are essential for today’s petabyte-scale systems. Usability is at an all-time low and user-experience design examines the ecosystem of useful services surrounding individual computers.

Customers and developers are so consumed by trying to determine whether a system “can” be built successfully. Conversely, they rarely ask themselves whether they “should” develop the system. Just because we have the ability to store billions of photographs, credit card numbers, personally identifiable information records and other highly sensitive data doesn’t mean we should. The responsibility of creating complex, high-risk information processing systems has never been greater. Unreliable systems may anger customers, unsecure systems could cost billions of dollars and unsafe systems can cost lives.

Agile project management and its practice of emergent design are a powerful combination that enables developers and customers to successfully build and acquire complex systems that create business value for their enterprises. In the early days, traditional developers believed agile methods sped up development (i.e., shortened cycle time) at the expense of design, quality and long-term maintainability. Developers are now entering an era in the adoption lifecycle of agile methods where we have the evidence to show that we can achieve superior designs, ironclad quality and lower overall total lifecycle costs.

Dr. Rico has been a leader in support of major U.S. government agencies for 25 years. He’s led many Cloud, Lean, Agile, SOA, Web Services, Six Sigma, FOSS, ISO 9001, CMMI and SW-CMM projects. He specializes in IT investment analysis, portfolio valuation and organizational change. He’s been an international keynote speaker, presented at leading conferences, written six textbooks and published numerous articles. He’s also a frequent PMI, APLN, INCOSE, SPIN and conference speaker (

Copyright © 2019 All rights reserved.

The URL for this article is: