Interleaving Architectural Initiatives In Lean/Agile Environments

Posted by Marius D. on September 06, 2012  /   Posted in Informational, Technology

Lean/Agile software development methodologies such as scrum are not only the new fad for achieving hyper-productivity in modern software development, they are becoming the norm. Shifting the life-cycle of software development from the sequential design processes (e.g. waterfall) to agile promises big gains in efficiency and overall output but usually bring in a feeling of loss of control over long term initiatives such as architecture. The gains agile deliver are usually attributed to the shorter delivery cycles which promotes fail fast (fail sooner rather than later to minimize impact of failure), an opportunity to re-shift product delivery focus with minimal consequences, and promotion of individual dynamics.

Manifesto for Agile Software Development

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

As we can deduce from the manifesto above, agile is about doing things quickly and adapting rapidly. Looking at traditional architecture, a process which plans out infrastructure, components, interactions, etc…, sometimes considerably in advance of actual development, you will probably realize that there is a serious incompatibility between the two approaches.

Architecture is all about quality. Architecture focuses on aligning the technology with the business’ needs and goals. This alignment usually deals with incredibly large swaths of components at the same time due to very interdependent nature of technology and processes. It is not uncommon for an organizations architecture road-map to span many years, usually due to the size of the projects, the number of delivery teams involved in the implementation of the initiatives, and the lifespan of technological components.

Because agile is a very reactive process with very short iterations, it is difficult to state that the sprint, or time-block in which features can be developed and tested, are conducive to supporting architectural initiatives. Every sprint must produce software that can be released, there is no such thing as half-complete pieces of functionality. So, how exactly do we incorporate architectural initiatives that may span dozens of sprint?

Architecture as Agile Architecture!

In agile, architecture is demoted from a superior driving force to an equal. It must adhere to the same principles other functions submit to in the agile methodology. Rather than being a static road-map, it needs to continuously evolve to keep up with the requirements of the business, just as features do. Architecture needs to be agile architecture!

My framework of choice in lean/agile is the scaled agile framework due to its ability to retain the focus of architecture as a 1st class citizen.

The Scaled Agile Framework is a proven knowledge base for implementing agile practices at enterprise scale. Its primary user interface is a “Big Picture” graphic which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level.

The basics of the framework: The portfolio level contains high level epics, long term investments that span releases. The program level breaks down the portfolio epics into features, which are assigned to teams. The teams then break down the features into stories, time boxed units of work that can be delivered within a sprint (2 weeks in most cases). These sprints are usually wrapped in a PSI (5 sprint, 4 development sprint 1 hardening sprint) which deliver potentially shippable software.

In this framework, architectural initiatives are intertwined within the portfolio items at the portfolio level. The organization agrees that a certain percentage of effort is dedicated to architectural items each iteration.  At the program level, architectural initiatives are broken down into architectural features. These architectural features are then broken down into tasks and interleaved into stories.

Closing Thoughts

There are a few different approaches to incorporating architecture into lean/agile environments but the true test is scaling them to large organizations/enterprises. The complete process, from the investment themes to the delivery of individual features should be conducive to supporting architectural initiatives in order for architecture to maintain a high degree of focus and to ensure overall quality of solutions.

Using the scaled agile framework, architecture is not only continuously evolving; it is a first class citizen in the entire portfolio. Having had incredible first hand success with this framework in an organization that houses almost 2k employees, I cannot recommend this approach enough. I recommend further reading on this framework to anyone who is interested and passionate about ensuring that architecture maintains a strong focus in lean/agile environments.

Useful Links

Scaled Agile Framwork

Scaling Software Agility Blog


Leave a Reply

^ Back to Top
%d bloggers like this: