“In manufacturing following a process step by step is a good thing. In our world [business analysis] this is not the case. Following an A to Z process for every project is a bad thing. Every project is different. Different people, different risks, different priorities, etc. You need to adapt your process to meet the needs of the project.”.I believe what Kupe is saying is that the ‘business analysis process’ is not a traditional straight-line process (like old-style manufacturing). Instead, it is what is currently being called (variously) a ‘social process’ or ‘dynamic process’ or ‘case-based process’. Such a process is:
“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.