Is Agile Development of Business Rules Possible? … And What Would You Call It If It Is?I’ve been exploring the meaning of ‘agile’ with respect to business rules. In our new book, 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 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 inNote 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! ~~~~~~~~~~~~~~~ Our new book (Oct, 2011): Building Business Solutions: Business Analysis with Business Rules – See: http://www.brsolutions.com/b_building_business_solutions.php By the way, we call the “it” in “… once you see it” an elephant. Have a look at the book to find out why.
From my experiences with Agile development I have found that:
1- It affords the opportunity to break projects into digestible chunks. As an example, what can be done in a two week, 10 business day cycle.
2- In turn the ability to catch problems quickly and gage the impact on the overall deliverables.
3- Provide a base for tracking projects and generating reports that management can quickly use to vet the project status.
4- Whether you use scrum masters and a management tool such as RallyDev is not mandatory but value added
5- Requirements gathering and specification creating can and should also be managed in an Agile rule set.
6- Realistically any process can be dealt with in an Agile approach