Here is an interesting enigma.  On one hand, Business Rules are gaining momentum due to the need for Agility in automated systems.  On the other hand, despite wide appeal and adoption, the Agile methodology has hardly been applied to BRMS.  As I became more immersed in both, I started considering various ways to combine both aspects of modern agile systems.  Let me share my thoughts in this article.

In the many projects I have seen over the last decade, I have witnessed a traditional waterfall — from Business Users to Business Analysts, eventually to IT — to get changes done to the business logic layer of the systems.  The whole purpose of Business Rules is to enable more agility.  How come the Agile methodology has not altered this traditional approach?

My take on Agile

The Agile methodology shines by its incremental approach, providing many opportunities to review the status of the effort and steer it into different directions whenever roadblocks occur.  A naïve comparison between Waterfall and Agile could be an analogy to end-to-end direction versus GPS.  The former will get to your destination quickly and efficiently, with the opportunity to use shortcuts that you learned with experience.  Unfortunately, if any of the roads are blocked on the way — due to an accident or a special event — finding the right detour could take you a long time, much longer than you had budgeted for, while the latter will reassess and update your list of maneuvers as you go, to constantly get you back to an optimized path to your destination.

A Product Manager at heart, I see tremendous value in the transparency of the Agile approach.  When I have used that approach in the uncharted territory of new technologies or products, I find I saved time by co-designing in a way; although I knew what I was looking for, I found that the try-and-adapt cycles reduced the need for pages and pages of what I would have called 'obvious requirements'.  The problem is that a business person and a developer have different perspectives on what is 'obvious'.  Unless you have only one person representing both, you can be certain that non-said requirements will often be overlooked.  It happened to me; I am sure it has happened to others.  Communication is critical, and exhaustive written requirements could take years to be perfected.

Agile methodology has been documented over and over as a great path to reduce risk and accelerate time-to-market.  That being said, a software development effort and Business Rules implementation may or may not expose the same characteristics.  How else could you explain that Agile has not been widely applied to BRMS technology?

Some history on Agile and BRMS

The only attempt I am aware of, that made it to a larger audience, was proposed by Jerome Boyer and team at IBM.  They contributed it to the Open-Source community a few years ago under the "ABDR" add-on, which stands for "Agile Business Rule Development" methodology. 

ABDR focuses mostly on the process aspects of rules development in an Agile environment.  It puts attention on the following key aspects:

• Prepare the logical object model for rules;
• Develop the business terms and corresponding artifacts;
• Organize rules in terms of decision services (mostly for deployment services);
• Establish a rule governance process.

This is a great starting point for including Business Rules into a software project.  The use of Business Rules does raise the opportunity to discuss and refine the language for a solid object modeling foundation.

What the methodology does not cover, though — which is my main focus — is the harvesting of those business rules.  How do you go from ideation to specification to implementation at full speed in an iterative manner?

A practical approach to Agile Business Rules Harvesting

Rather than re-inventing the wheel, I recommend we borrow from the Agile methodology in the first place.  All concepts are probably not applicable, but others fit both software development and business rules paradigms quite nicely.

I always liked the 'test-early' concept of Agile as it gave me the opportunity to get my hands dirty early in the process and to test the interactions live.  How does that apply to business rules?

• Understanding the business impact of your business rule changes is something you want to do early rather than late.  Amazingly enough, in many projects I have seen, the business impact cannot be measured until 2 weeks or more AFTER deployment.  As a Subject Matter Expert, I wish I could get this insight much earlier in the process.  Ideally, I would like to get some directional computations as I am formulating my changes.
  
  
• Testing and measuring can only be done within the context of formal use cases.  Agile recommends that user stories be documented for communicating the requirements to the development partners.  Similarly, use cases could be leveraged for communicating business rules.  I would even argue that use cases could be exposed to business users to formulate their requirements and to experiment with alternatives when appropriate.  Well-selected use cases can be used to challenge business users in the context of real situations.  The beauty of business rules technologies is that you can execute those statements without having to wait for their implementation, assuming that enough of the infrastructure is readily available — although you do not need much to get started.

I envision an Agile approach for Business Rules that will enable business users to get acquainted with those technologies without such a heavy learning curve.  After all, what they know is their business and their interest in technology is only driven by necessity, not affinity.

I presented this approach to Agile Business Rules Elicitation in more detail at Rules Fest in October 2011.  Feel free to reach out to me directly with your questions and/or comments.

Key takeaways:

• Agile lessons learned are applicable to Business Rules elicitation;
• Current Agile efforts have been focused on object modeling;
• Challenge business users with use cases;
• Factor business objective measurements early.

# # #