Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

What is Agile? … Or Rather, What is It We Really Want to Be ‘Agile’?

This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php ~~~~~~~~~~~~~~~~~ Agile in software development is an IT development method featuring rapid iteration and prototyping. Agile software methods and business agility have nothing to do with each other. Agile in software development leaves off exactly where business agility picks up – at deployment. In working with clients we frequently come across systems that feature a very ‘open’ environment with few enterprise controls. Typically, this ‘flexibility’ resulted from diligent efforts by IT to satisfy many stakeholders individually. But the ‘flexibility’ is just an illusion. The failure of business-side stakeholders to come together and develop a collective business solution before ‘agile’ software development commences can plague the company for years to come. It reduces overall productivity, lowers customer satisfaction, and diminishes the capacity to make sound operational business decisions. It makes apple-to-apple financial comparisons virtually impossible. And it always costs a lot in ‘maintenance’. There are simply no magic bullets for building business solutions. 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. So the answer to my question is that business should be agile. Here then is our definition of business agility: being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense.

Tags: , , , , , , , ,

Ronald G. Ross

Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.

Comments (2)

  • Avatar

    ChrisW

    |

    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.

    I suspect the trouble comes when we try to do things the other-way-round. That is, we try to implement an agile development paradigm (complete with documents, reviews, sign-offs, etc.), but do not consider the associated impacts on the surrounding management systems. In this case I doubt the result would look very agile…

    • Avatar

      Ronald G. Ross

      |

      @Chris – Great observation about agile development of business rules.

      Just to clarify for everyone who might read this: An underlying assumption is that business policy and business rules can be and should be specified and analyzed independently of traditional software requirements (functional & non-functional requirements et al). They 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 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 believe it’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 appearance of “rules” and “policy” in that definition. I didn’t make it up, it’s right there in the dictionary.

      Bottom line: Instead of ‘agile development” of business rules, I think at that point you’d be talking about *agile governance*. Indeed, I think that’s *exactly* what we’re talking about here. Very exciting once you ‘get’ it.

Comments are closed