What’s Lean and Scalable about the Requirements Information Model for the Agile Enterprise?

In the last post, we introduced a Lean, Scalable Requirements Information Model for the Agile Enterprise. This model, based on the Big Picture, is being developed in collaboration with Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software.

This model serves as the requirements-related semantic underpinnings for the Big Picture of Enterprise Agility and I promised to describe the model further in upcoming posts. Before I dive deeper into the model, though, it’s useful to spend a few moments describing why the model is “Lean” and “Scalable” as advertised.

What Makes a Software Process Lean?

Lean Software is a philosophy of approach that is characterized by:

  • Eliminating all non-value added processes, steps, delays and artifacts
  • Minimizing time to market; maximizing value delivery

Lean Software development has been characterized by Mary and Tom Poppendieck in a number of books. In their most recent book, the principles of lean software are described along with the myths that prevent lean thinking. Here’s a view from Implementing Lean Software Development: From Concept to Cash.

  • Principle 1: Eliminate Waste- Myth: Early Specification Reduces Waste
  • Principle 2: Build Quality in- Myth: The Job of testing is to find defects
  • Principle 3: Create Knowledge – Myth: Predictions Create Predictability
  • Principle 4: Defer Commitment – Myth: Planning is Commitment
  • Principle 5: Deliver Fast – Myth: Haste Makes Waste
  • Principle 6: Respect People – Myth: There is one best way
  • Principle 7: Optimize the Whole – Myth: Optimize by decomposition

What Makes a Software Process Scalable?

Compared to lean, I know of no such convenient published definition. However, based on my experience in prior (RUP) and current (agile and scaling agile) software process initiatives, I’d think that an agile software process is scalable when:

  • Principle 1: It’s the simplest thing that could possibly support the needs of all stakeholders, including the team, program and enterprise level. (Scaling to support hundreds and thousands of practitioners).
  • Principle 2: It supports agile’s insane focus on customer value delivery at all levels.
  • Principle 3: It is particularly sensitive to the needs of the team members. (They write all the software; maximizing their velocity maximizes the productivity of the whole).
  • Principle 4: It is lightweight and adds no unnecessary overhead when applied to the enterprise. (Doesn’t slow development as it scales).
  • Principle 5: It is configurable and can be customized where appropriate. (Every enterprise is unique).
  • Principle 6: It drives and supports best practices of building a quality software foundation. (Without inherent quality, nothing scales).

What’s Lean and Scalable About this Model?

With that background, we can turn to attempting to defend our “labeling claims” of a Lean and Scalable information model. Of course, it’s the application of the model, rather than the model itself, that makes it lean and scalable. Therefore, in the table below we’ll describe how the model is intended to be used in the context of the Big Picture. We’ll also indicate the principles of Lean (L) and Scalable (S) that the model supports. Here we go:


Organization Model elements What’s Lean? What’s Scalable
Agile Team
  • Story
  • Task
  • Acceptance
  • Single (iteration) backlog
  • All that is needed for the team. (L1)
  • Just in time story elaboration (L1, L4)
  • User Story construct (L7)
  • Simple backlog. (L1, L4)
  • Acceptance tests assure quality foundation. (L2)
  • No limit to number of define/ build/ test) agile teams. (S1, S4)
  • Extremely efficient for the team. (S3)
  • Hooks to program. (S1)
  • Acceptance tests assure quality foundation. (S6)
Agile Program
  • Feature
  • Feature (release) backlog
  • Nonfunctional requirements (constraints)
  • Features described at high level of abstraction. (L1,L4)
  • Does not over constrain the solution space. (L1)
  • Single, localized backlog. Introduce non-functional requirements only as and when necessary. (L1)
  • Programs driven by Features, not requirements. (S2)
  • Hooks to stories below.(S1, S3)
Agile Enterprise
  • Epic
  • Strategic Product Themes
  • Portfolio backlog
  • Lightweight, hi level descriptions of the problem not solution space. (L2, L3)
  • Single (portfolio backlog) (L1)
  • Modifiable (L5)
  • Epics hook to Features. (S1,S2, S6)
  • Traceable and supportive of agile epic-based estimating and planning. (S1, S5)

Hopefully, we haven’t overly-belabored this simple point. But if we are to depend on this model in the enterprise, we must be confident in the fact that is both Lean and Scalable!

A Lean, Scalable Requirements Information Model for the Agile Enterprise

For those of you who have been following the Big Picture series, you may have noted that one element of the picture is the “requirements information model” that flows down the right side. This element of the model describes agile terms for expressing system behaviors at various levels of abstraction. (See below).

Big Picture with requirements model highlighted

The Big Picture, Highlighting the Requirements Model

In summary form, the model implies the following requirements-related elements and relationships as illustrated below.


For Big Picture purposes, this is an adequate explanation which helps the enterprise to understand the new labels for “requirement like things” in enterprise agile methods and the way teams use these new things to describe intended system behavior.

However, while the Big Picture supports “hand waving” descriptions of this complex problem, it does not define the exact nature of each element nor the critical relationships between them. For this purpose, my colleague, Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software Unit, and I have been working on a semantic meta-model for agile enterprise requirements information management. The model also serves as the technical underpinnings for the requirements elements of the Big Picture. The need for the more definitive model is driven by two factors:

  1. The need for clear definition of each artifact type, so teams can be coached as how to use the appropriate element (ex: feature, user story, task) at the appropriate time
  2. The need to make explicit the relationships amongst the elements of the model (user stories, acceptance tests, features, etc.) to support tooling automation, which will provide enterprise- level support for status reporting and portfolio estimating and planning.

Last week, Juha-Markus presented this model at Object Days at the Tampere, Finland, University of Technology. His full presentation can be found here.

Lessons Learned at (truly) Enterprise Scale Agile Adoption

The purpose of Juha-Markus presentation was not the model itself; rather it was to describe how this model supports the enterprise level agile practices being deployed in the development of Nokia’s S60 Software Platform and Applications. Nokia’s S60 Platform is a software platform for mobile phones that is currently amongst the leading smart phone platforms in the world. The Platform is built by an extensive network of software teams who are applying Scrum to increase the productivity and quality of their local efforts. S60 in turn, is built on top of the Symbian OS, further coupling the efforts of the Nokia development teams to the many software practitioners of this critical supplier. Nokia S60 teams’ experiences in scaling agile across a large number of intensively collaborative software teams represents some of the most advanced agile thinking and practices, at the greatest scale, of any that I am aware of.

These experiences serve as an excellent object lesson for others in (really) Scaling Software Agility. For more on this topic, I refer you to Juha-Markus’ presentation which will provide a fuller understanding of some of the challenges the S60 teams are addressing with their new agile model.

The Requirements Information Model

The purpose of this post, however, is to introduce the requirements information model that we have been collaborating on. The most basic form of this model (more in future posts), as represented in UML form, is shown below.

A Lean, Scalable Requirements Information Model

A Lean, Scalable Requirements Information Model

When compared to the Big Picture, it’s obvious that the Big Picture graphic is an oversimplification of the reality of large scale, agile system development. While the elements of Epic, Feature, Story, Task and Backlog are described in the Big Picture and elaborated in supportive posts, the elements of Strategic Product Theme and Acceptance Test have not. These are described below:

  • Strategic Product Theme – this information model adds this, new and highest level element to the information hierarchy. Themes provide a well-defined set of core value propositions that in turn, drive portfolio investment. They define the key strengths of the enterprise, deliver on strategic initiatives and solutions, and drive long-term competitiveness. Themes, in turn cause the creation of Epics, Features, and Stories that deliver on the themes value proposition. (In the Big Picture, Themes can be considered to be the various “slices” in the portfolio management pie chart at the upper left)
  • Acceptance Test – moving all the way to the bottom of the stack, the model also highlights the critical role of the acceptance test in agile development. In turn, this encapsulates two key agile quality principles: 1) there is always at least one acceptance test for every story (in agile, all code is tested code) and b) a Story cannot be considered “done” until it passes the test.

Lastly, the Non-Functional Requirement is a primary element in this model, which reflects the role these special requirements play in the development of enterprise class systems. (These were called out as auxiliary elements of the “Vision + in the Big Picture.)


That summarizes the primary elements of the lean, scalable, requirements information model. To the new or smaller team Agilist, this model may seem relatively complex and perhaps not very agile, or at least not “the simplest thing that can possibly work”. However, experience has shown that thinking about the solution space in these varying levels of abstraction is in fact, a simplification of the problem at enterprise scale and encourages agile thinking throughout the organizational hierarchy. I’ll describe why in an upcoming post.