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
    test
  • 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!