I've been exploring the meaning of 'agile' with respect to business rules.  In our recent book^[1] we say:

"Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing.  All artificial (IT-based) production freeze dates for deployment disappear and the software release cycle becomes irrelevant.  The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to."

In response, a practitioner made the following deeply insightful observation about agile development of business rules.

Practitioner:  "My perception of the intent of agile software development is to try to have the underlying development process track better to the realities of the business process change.  Rather than the good old days where the specification and implementation of the solution ran so long that the problem trying to be solved had changed so much that the delivered solution was irrelevant.  So, if you reach a point where 'The only constraint is how long it takes business leads and Business Analysts to think through the change', then, to me, you are already doing agile development."

Just to clarify:  Our underlying assumption is that business policy and business rules can be and should be specified and analyzed independently of traditional software requirements (i.e., functional and non-functional requirements).  That's rule independence as the Business Rules Manifesto^[2] calls it.  Business rules can and should have an independent life cycle.

Then yes, there could be two kinds of 'agile development'.  Agile development of business rules and agile development of software.  (I'll leave it to others to decide whether agile development of requirements makes sense.)

But here's the rub:  If you did reach the point where 'the only constraint is how long it takes business leads and Business Analysts to think through the change' in business rules — and I do believe that's possible — business managers almost certainly wouldn't (and shouldn't!) call it 'agile development'.  That's an IT buzzword.

When you talk about development of business policy and business rules, you are really talking about governance.  Here is the Merriam-Webster Unabridged definition of "govern" …

1a:  to exercise arbitrarily or by established rules continuous sovereign authority over; especially : to control and direct the making and administration of policy in

Note the prominent appearance of 'rules' and 'policy' in that definition.  Hey, I didn't make it up, it's right there in the dictionary(!).

So the bottom line is this:  Instead of 'agile development' of business rules, at that point I'd say you'd be talking about agile governance.  Indeed, I believe that's exactly what we're getting at here.  Very exciting once you see it!

References

[1]  Building Business Solutions:  Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC (2011), 304 pp.  Visit www.brsolutions.com/bbs

[2]  The Manifesto is free, only 2 pages long, translated into 15 languages.  Have a quick look (or re-look!).  No sign up required.  Well worth your time.  Visit www.businessrulesgroup.org/brmanifesto.htm

# # #