BigLever and the Agile Product Line

BigLever’s recent introduction of the Gears PLE (Product Line Engineering) Lifecycle Framework and PLE Methodology – adding to its long-time BigLever Software Gears offering for product-development management – is as important, I believe, for its potential ability to foster the “agile” products of the future as for its immediate benefit in extending product management to multiple inter-related product lines.  BigLever ably describes its offering’s immediate benefits to present customers.  I’d like to dwell here on the broader implications of its new capabilities in evolving software development to support not only agile development but also agile solutions.

What do I mean by an agile product/solution?  I mean one that is exceptionally and quickly customizable (not just modifiable as the product evolves) at all points in the product/solution lifecycle, both before and after its delivery to the customer.  In other words, agile development allows you to change as customer needs change right up to the point of delivery, and then iterate in the next product development lifecycle; agile products allow you to create product lines of multiple related products in which somewhere in the welter of choices is the right version for a “customer of one”, and that customer of one is a large company that needs multiple versions for multiple customers inside the firm.

I would argue that this is an inevitable outcome of today’s trends in software-infused products and product lines.  The marketing approach that seeks to leverage one successful product in related areas is now reflected in software-containing products that share a great deal of features, whether the results are presented to the outside world as one product line or several.  Increasingly, a marketing and Big-Data focus on customer individuality, and customers’ desire to achieve greater usefulness via customization after solution receipt, makes customization both before and after the sale more and more frequent. I would also assert that most of today’s software development tools assume the old reality of one linear product development lifecycle.  Yes, programmers and code are shared across related projects; but across multiple product lines, less so.

Step 1:  BigLever PLE and Cross-Product-Line Customization

Again from my point of view, the BigLever offering simply takes a project management/product-lifecycle-management framework and infuses it with the notion that multiple related products and product lines are involved.  That’s not as simple as it sounds; for example, doing change management on multiple related development streams is more complicated than doing branching of code versions in a single stream.  In any case, the BigLever software predefines a set of “variable” building blocks that represent features, and runs through a checklist for a particular version that determines which customer gets which feature set on which customization of which product – and allows for further post-production customization by the customer.

The rest is details, but important ones.  There is a traceability mechanism, a “product configurator”, a “tiered” Methodology (supporting products, product lines, and muitiple-product-line “portfolios”) and the ability to store code sets representing customizable features – a characteristic that effectively creates for the developer a base of industry- and firm-specific software from which he or she can semi-automatically populate a product line.

And it is this last detail that especially excites me, and leads me to talk about agile products.

The Other Shoe:  Automated Development With Embedded Customization

It seems to me that the ability to store a “code data store” of feature variations across products and product lines is much like the ability to create a library of object classes:  It forms a natural basis for rapid, flexible development.  Granted, Gears is focused on managing development across multiple projects, not on creating code itself.  Still, taking that code data store and using it to semi-automatically generate new software based on the old is an obvious next step for somebody.  And that new software retains the flexible customization of the previous version of a product, product line, or product “portfolio”, baked in, as it were. 

Consider such an approach when wedded to agile development.  Techniques such as refactoring already ensure that it is exceptionally easy to modify software as you develop it, as needed.  Building blocks with customization built in allow not just modification, but also variation/customization to fine-tune for the customer of one.  Together, they maximize the agile developer’s ability to go in any direction needed at any time.

That’s why I call the result an agile product, not a flexible one.  The distinction between flexibility and agility is key to getting an agile approach’s true benefits.  Flexibility can simply cement a sub-optimal solution in place, rather than encouraging major changes as customer needs change.  Agility, instead, encourages incremental adjustment that eventually add up to major new functionality, well adapted to the customer.  The combination of development agility in modifying existing software, and the kind of customization agility resulting from semi-automated development using building blocks with embedded customization, makes both the process and the result (the product) more agile.

Bottom Line:  The BigLever Approach is Worth Incorporating

Let me be clear:  BigLever does not force any approach on you. Its Gears solution has a long tradition of working with development toolsets of all stripes.  It is my own view that it or a similar solution will in the long run pay off best when paired with agile development.  And, of course, the details of the merger of the two have yet to be fully worked out.

Still, given the promise of the BigLever PLE approach, it seems reasonable to me that medium-to-large IT organizations with an array of software development needs that approximate “multiple related product lines” should at least take a close look at the new BigLever offering.  Savvy implementers might well go further, and begin to amass a “war chest” of feature customizations for later use in automated development.  In either case, the only thing you have to lose is an illusion:  The idea that we can go back to the good old days when each project aimed to create a new version of one and only one product.

But back then, you couldn’t even dream of the customer of one. Maybe those good old days weren’t very good, after all. You’re probably better off exploring the brave new agile-product-line world that BigLever’s offering represents.