Jacob Ukelson, in his post Time for a Process Manifesto? , picks up some ideas from the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

So far so good.  But then he draws the following conclusion:

I think that traditional BPM does less well on the first two principles – it is pretty clear that comprehensive documentation (the process model) is still a basic requirement. Probably because of the mindset – process and tools take precedence over individuals and interaction. So not so good on those fronts.

I guess people have different notions of what “traditional BPM” is.  The traditional BPM I’m familiar with is not about documentation, it is about working software (and so it is not clear that comprehensive documentation is a basic requirement).  The diagram is the process, and the diagram actually runs.  Although, I’ll admit I came into the BPM world via Lombardi, and brought with me software and consulting approaches learned from other jobs.  So I might have missed out on the specific traditional BPM Jacob is referring to.  But in our (BP3) world of BPM:

1. People are the focus
2. Document if it reduces risk or adds value.  Don’t document just to pass gateways.
3. We emphasize working software and feedback loops.  Luckily the software tools we use reinforce this approach and support it.
4. We use the term “value-driven vs. plan driven” but I think it substantially has the same spirit as “collaboration over contract negotiation”.
5. Responding to change over following a plan: of course, see the previous point.

I realize not everyone tackles BPM this way.  And I also realize there’s no One True Way that is always the best way.  But these principles gird every project we do. I agree with the principles in the manifesto, but BPM practitioners should already be abiding by these principles.  If that’s not “traditional” BPM, so be it.  I may not be able to convince everyone to define BPM the way I would, but I can still advocate for our approach.

Side note- I like another point Jacob makes:  “Though many position ACM as a way to respond to change, for me it is a process oriented way to focus on individuals, interactions and working software (which make it more amenable to change).”

Seems we just posted on Lean-Agile as it relates to BPM, when  another article on Agile BPM appears on ebizQ, by Jack Vaughan.

Oh wait, we really did just write about this topic! Only the day before the ebizQ article was published.

Both articles are worth a second look.  If you’re not applying agile principles to BPM solution development, it might be time to take a second look.

“Successful Failure” has been used to coin the events which unfolded for the Apollo 13 mission. The failure was that the mission did not meet its original objective to land on the moon and return but rather met a more urgent objective which was to successfully deliver home the astronauts who were caught up in a series of unexpected and violently changing situations.

During the course of BPM delivery, and if a company is open-minded enough they can actually benefit from a failure. Now to be clear, I am not suggesting that every endeavor should automatically be assumed to fail or for that matter even the planning for failure is not something anyone would really want to do. Risk mitigation, yes of course but what I am referring too is a willingness to change a plan if the business value interests aren’t completely aligned with that initial plan. Things happen on a project and sometimes even a perceived negative situation can be capitalized on and may actually yield a better overall outcome than that original improvement roadmap. For example, when you are finding yourself looking at a process and subsequent solution requirements and they have stagnated. Stagnation of solution requirements is extremely common. Perhaps those requirements were developed months and months ago (or even longer), or similarly developed in isolation of the true voice of customer/voice of business. If you approach this purely from a plan-driven approach your failure scenario is high pure and simple. And achieving that failure may be the best thing to happen on that project because it opens the door to re-adjust and go after the more immediate business-value aspects of the solution; the here and now, not the how it was. As a result, you likely just saved a ton of capital by avoiding the ongoing support for a solution that was at best dead on arrival, and at worst just added to the overall process problems.

In a Lean-Agile delivery approach the notion of “failing fast” and being business-value driven over plan-driven are extremely important in these scenarios. Business-value driven simply means that during delivery you are willing to put the true needs of the business first, those solution requirements that will actually move the performance needle and not generating assets just because they may have been written down in a plan once upon a time. In essence, separating the wheat from the chaff.

For Apollo 13, as much as solutions were needed to the various problems, solutions had to be identified quickly in the face of the many unknowns that the mission was faced with. To do so the team needed to “fail-fast”, meaning that the capability to perform quick failure assessments and prevent re-occurrence is equal to the value of identifying a solution. Simply stated, do everything you can to get the real problems you are going to face identified up front. For companies new to BPM and its Agile software delivery tenets no matter how rock solid you believe your plan to be the teams will be undoubtedly faced with unexpected challenges. Getting too far ahead of the risk aversion curve by trying to engineer for every possible corner case everyday is fruitless, expensive, and ultimately useless. Reason being is that in doing so you will create more mass in the project than what can literally be propelled off the ground; more mass requires more energy and will ultimately result in inertia. The last thing anyone would want to have on their delivery project is a vast, never ending source of mitigations and controls based on theory or even meta-theory. An organization needs to have courage to move into and stay in a delivery mode versus discussing what delivery may or may not mean for a project academically.

What is required in delivery is proportionality and pragmatism in order to achieve the mission objective. In Lean-Agile, which happens to be the method of choice for us at BP3 in delivering BPM solutions, there are just a few simple staple items all of which are based on delivering business value as soon as possible. When we talk about what is value we talk in terms of a working solution over the documentation of a solution, collaboration over negotiation, flexibility being valued over rigidity as examples. The reason we value this is because it brings everyone closer to seeing a successful outcome by bringing risk and unknowns forward to deal with immediately.

In Lean, something which is considered Value-Added must pass three discrete tests:

1. The customer would be willing to pay for it
2. Done right the first time
3. Physically transforms the output; increasing its value

If you took the same philosophy to dealing with failures which occur on projects today then its pretty evident that there is a tremendous value in being able to identify and resolve issues quickly.

Value-Added Failure

1. The mission/project/program would be willing to pay to prevent or remediate issue
2. Identified and resolved early
3. The outcome increases efficiency, effectiveness, and business value of the ultimate solution

Again, in order to truly realize the value of putting your undiscovered troubles behind you quickly you have to begin by acting, doing something that provides the opportunity of discovery versus avoiding the journey all together. So if your going to have a failure, set yourselves up to do it quick and unequivocally.

Lance Gibbs gave a well-attended talk on moving from Plan-Driven to Value-Driven delivery at bpmCamp 2010 @ Stanford.  There are some great slides in this presentation, and the approach dovetails well with Lance’s ability to get people focused on what matters most to their project success.

It starts with realizing that requirements are estimated, and resources and time are fixed, which is inverted from the typical plan-driven approach.  There’s also a focus on “should” rather than “could.” In particular, slide 4 jumps out at me, as it spells out what you should value, for example:  working software over comprehensive documentation.  Amen!

The presentation is embedded here: