I like the Idea, but Disagree with one Conclusion

Scott Francis
Next Post
Previous Post
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).”