[ There is an interesting discussion in ProductNation on Customizable Product : An oxymoron which triggered me to write this post]
I find many people use these words interchangeably. However the distinction is important and source of value. Agility can be engineered with proven techniques and best practices. With advancement in software engineering there is convergence on the tools and techniques to achieve agility and it may no longer be a source of differentiation but a necessary feature. Flexibility on the other hand requires deep insight into diverse needs and types of usage and done imaginatively can provide great value to users and be a source of competitive advantage.
|
The online Merriam-Webster dictionary offers the following definitions: Flexible: characterized by a ready capability to adapt to new, different, or changing requirements. Agile: marked by ready ability to move with quick easy grace.
|
In Software product context it may be more appropriate to define agility as the ability to change things quickly and Flexibility as the ability to achieve a (higher) goal by different means. So ability to value Inventory by different methods like FIFO or LIFO or Standard cost is flexibility. The ability to change commission rate or sales tax rate quickly (generally by changing a parameter in a table of a file and avoiding need to make code changes) is agility.
There is a range or scale ( 1 ..10) of agility. Making changes in code esp 3rd generation languages like Java, C# is the baseline. Using a scripting language like Javascript , Python may be less demanding then compiled language but it is still not as agile as most users expect. Most users would rate it simpler to update a parameter in a file or a simple user interface like a Excel type spreadsheet as simpler and faster. Changing logic by using a If-Then type of rule base is in-between. Simpler then coding but more complex then table updates.
You should have picked up some inter-related themes here. Complexity or need for skill in making changes to a scripting or Rule engine . Need for easy to use interface to make the changes. Need for relatively easy and error free method of making changes. If you need to update ten parameters in ten different places or change 17 rules in a If-Then rule base it may not be as simple and is less agile .
Most modern Software products are fairly agile with scripting, table based parameters and rule driven execution engine. The use of style sheets in generating personalized User interface, specialized components like Workflow or process management engines etc also provide agility.
Flexibility is a different beast. Layered architectures and specialized components for workflow, rule execution and User experience can make it easier to accommodate different ways to do the same things. They make it easier to make the necessary changes but they do not provide flexibility as such. End users do not value the potential flexibility of architecture but the delivered functionality. This is a major problem. Even Analysts from Gartner , Forrester do not have a good way to measure flexibility and use proxy measures like number of installations or types of users ( Life Insurers and Health Insurers or Make to order or Make to Stock business).
Flexibility is derived from matching the application model to the business model and then generalizing the model. I will illustrate with a concrete example. Most business applications have the concept of person acting as a user ( operator) or manager authorizing a transaction. So a clerk may enter a sales refund transaction and a supervisor may need to log in to authorize this refund. The simplest ( and not so flexibly) way to implement this is to define the user as clerk or supervisor. A more sophisticated model would be to introduce the concept of role. A user may play the role of clerk in a certain transaction and a supervisor in another. Certain roles can authorize certain types of transactions with certain financial limits. So user BBB can approve sales refund up to 100,000 INR as a supervisor. However BBB as manager of a section can initiate a request for additional budget for his section. In this BBB is acting as a clerk and DDD the General Manager who approves the budget extension request is acting as a supervisor. This model is inherently more flexible. It is also not easy to retrofit this feature by making changes to parameters or If-Then rules. If the Application does not model the concept of Role all the agility in the product is of little use. Greater flexibility can be produced by generalizing the concept of user to software programs. So in certain high volume business a “power user” can run a program which can automatically approve a class of transaction under certain set of control parameters. This “virtual user” is recorded as the approver on the transaction. The application keeps a trail of actual control parameters and power user who ran this “batch”.
Flexibility comes from a good understanding into user’s context and insight into their underlying or strategic intent. Business and users will vary the tactic used to meet their intent based on context. Consider a simplistic example to illustrate. I need to urgently communicate some news to a business partner. I try calling his cell but to no use. I would send a SMS ( India) but if a US contact ( who are not as yet fans of SMS or Text) leave a voice message on his phone or send a email. A Smartphone that allows me to type a message and send as SMS or email is more flexible then one where I have to separately write the email or the SMS.
Frequently Software designers and Architects generalize all types of changes as extensions. They are not interested in understanding intent and context of usage and want a horizontal generic solution to all changes. This leads to overly abstract design with extension mechanisms to change logic, screens and database and reports. In essence to develop a 4th generation programming environment or Rapid Application Development Environment (RAD) . These help by making programming easier and faster but are no substitute for understanding user’s context and designing the application architecture to match and exploit them.
Users relate to a product which speaks their language and seems to understand them. They also get excited and impressed when they see new ways of doing their business and improving their revenue, reducing cost and improving customer satisfaction. Most managers want to make changes incrementally. So ability to “pilot” changes to a smaller segment of users, customers and products while continuing in traditional way with the larger base is of great value. That is ultimate flexibility.
Flexibility is not a mélange of features haphazardly put together. I have seen many service companies developing “Flexible Product” by adding every feature they can see in other offerings. Invariably this leads to a mythical creature which does not work. If you put a Formula 1 Race engine in a Range Rover chassis with a Nano steering and Maruti wheels you have a car which does not drive!! A Formula 1 car is intended for maximum speed and acceleration that is safe while a goods carrying vehicle is intended for maximum load carrying with optimum cost of fuel usage .
Delivering Flexibility requires heavy lifting in developing a good understanding of user’s domain, their intent and context. It adds value by simplifying the feature set and matching users intent and context.. If we can use our imagination and understanding of technology trends and capability to provide more then users have visualized we can lead them to newer ways. Leadership is an important way to differentiate your product. Invest in doing this and reap benefits.