Why Lean–Agile Delivery for BPM?
With all the different techniques out there for software delivery it’s understandable why companies pick different flavors based on the nature of their projects. Even the analyst community at times differs on what iterative-based approaches are best suited for BPMS roll-outs; and that’s OK. The real answer, at least in our minds, is to select an approach that is best suited for the make-up of the organization, and one that has the thinnest profile in terms of overhead to get the job done. The winning profile is one that is “built for change”. Simply stated: it’s the approach that allows for the greatest adaptability and efficiency to be realized along the project journey. If you are in the business process improvement game then you already know how critical it is to be able to respond to change. Business Process Management truly is a management discipline to business process improvement. It is certainly not the only one out there but it is one in which information technology plays a value-added role and not the role of a constraint which must be subordinated.
Since effective BPM initiatives hit both sides of the ledger between operational process improvement and technological support, having a delivery method that speaks the language of process is very powerful. In the same vein that the business processes should be effective, efficient, and adaptive through the systematic reduction of waste (pure non-value added activities) so should the method in which you employ the technology to support them. Lean-Agile based delivery does that.
Don’t Call it a Strategy
Lean-Agile delivery isn’t a strategy in and of itself but rather a set of mostly common sense principals and practices to reduce waste in the software development lifecycle – and to support your strategy. So consider, if you have designed a green field process or if you have a process which requires remediation, the last thing you will be doing is seeing just how heavy and restrictive you can make it. On the contrary, you are looking for ways to make it flow through defect removal, automate where it makes sense. And if you are very smart, at a minimum you will focus in on those in-flight process metrics which confirm the outcomes you seek and provide the end-to-end visibility.
The exact same thing should be present as you manifest that process into tooling and the software delivery lifecycle! You want your development process (and it IS a process) to flow, to reduce hand-off’s, to avoid stagnation, to value working software over copious/short-lived documentation. Even if you are doing iterative development, it’s astounding how much waste you can remove and still get the solution realized by the business customers who really and truly need it. And not only do they need it now, but they need a solution that can support changes coming quickly as they learn more about the true process capabilities and the inevitable external influences driving continued improvement.
A quick real-world Value Stream example, looking at a delivery process…
Before a Lean approach is applied to an Iterative Delivery Process (target iteration run-time of 3 weeks)
After a Lean approach is added to the Iterative Delivery Process
Again, if you think of your delivery process apply the same notions you applied to the business process, bring these two sides of the ledger into harmony. Everyone speaking the same language between business and IT is a fundamental “must have” to solidify, succeed, and grow your BPM capability. Gartner has a good research paper entitled “Agile Foundation: Lean Software Development” and it is one of the differentiators they cited about BP3 in terms of our delivery model in their “Who’s Who in Business Process Management Consulting and Systems Integration”. Bottom line, it just makes sense if you’re serious about BPM to take a look and figure out how you can tailor these principles and practices into your organization. Is there anyone opposed to shaving a days out of their development lifecycle increasing product quality by doing so?
(As an aside – I do have this in BlueWorks Live as a pseudo VSM as well but I couldn’t see the single view, big-picture plus details and metrics, hopefully BlueWorks Live will start supporting these types of process views)