The Challenge of Enterprise Requirements Management

order to maximize productivity. Early and detailed specification of requirements represents too much work-in-progress that is wasteful and distracting. Pushing large requirements specifications through project factories spreads focus thin, as low priority requirements suck as much time and energy from the organization as the highest priority requirements.

Challenged with such volumes of poorly understood requirements, over-engineering flourishes (e.g., "I'm not sure what that means, so we better design for the worst case"). A better approach is to free up an organization's energy by empowering teams to do what they know is right--focus on testing and quality so that better designs and architectures can emerge as needed. This just-in-time mentality requires courage, since control is relinquished from management and given to collaborative teams that undertake team learning to solve difficult problems of technical product development.

Ken Schwaber sees the solution space to be totally within the rules of Scrum. Ideally, Scrum scales perfectly, and the "enterprise's work can be organized, top to bottom, into a single Product Backlog." [x] This represents well the conceptual scaling of Scrum. One should also be aware that scaling Scrum teams adds degrees of complexity that are best framed by Lean principles, since teams of teams have different dynamics and communication needs than teams of individuals.

The enterprise product backlog prioritization should be guided by such principles as optimizing the whole, eliminating waste, and delivering fast, and a properly scaled enterprise can then pull from the prioritized backlog based on each team's capacity and the needs of the enterprise. [xi]

Enterprise Silos
As mentioned above, an unintended outcome of Enterprise Requirements Management is the building of silos. It's not uncommon for a mature technology organization to have a silo devoted to managing a portfolio of technical tools that are approved for use within the enterprise. The justification for this organization itself is several degrees away from any business vision (unless the business happens to be technology).

Summary
Examples have been presented where Business Analysts and Use Cases can be misapplied to the Enterprise requirements effort, and can result in Lean anti-patterns that fail to bridge the chasm between business and IT. Agile requirement techniques, such as the Business Value Roadmap, focus Agile teams on prioritized chunks of work, and allow quality to emerge without waste of legacy enterprise methods. Warning signs of dysfunctional organizations that result in Lean anti-patterns include:

• Organizations focusing on process instead of business value.
• Specialized teams focused on creating and managing enterprise documents.
• Backlogs of use cases managed by use case experts.
• Formal inspections of enterprise documents that result in grammar and punctuation corrections.
• Change-resistance enforced by rigid change control procedures.
• Generic use cases.

Work to eliminate these and set your enterprise up for successful product delivery.

[i] Implementing Lean Software Development: From Concept to Cash, by Mary and Tom Poppendieck

[ii] Link Borken

[iii] Just Enough Requirements Management, by Alan M. Davis, Dorset House, p. 172.

[iv] See Alan Shalloway, Lean Anti-Patterns and What to Do About Them

[v] Scaling Software Agility: Best Practices for Large Enterprises, by Dean Leffingwell, Addison-Wesley, p.93.

[vi] Out of the Crisis, by W. Edwards Deming, MIT CAES, p. 15-16.

[vii] Ambler ( http://www.agilemodeling.com/artifacts/sequenceDiagram.htm)

[viii] User Stories Applied, by Mike Cohn (p.137-141)

[ix] See Beaver ???

[x] The Enterprise and Scrum, by Ken Schwaber (p. 70)

[xi] Private discussion with Alan Shalloway of NetObjectives, who promises a separate blog on Lean and teams of teams...