Business Process Management is probably the first area where Software Development is almost entirely ‘Agile’. In the past few years we have begun to question the validity of relying too much this approach.

Also, there is a very interesting post by Theo Stolker called BPM and the Unicorn tale that discusses similar issues. He states:

The work required to make a business process executable and manageable should never be reduced to just drawing a high-level (BPMN) model. In fact, anyone who tried implementing a business process to a BPM Tool knows how hard it is to transform the logical, high level buisiness process to a executable process that deals with the required detail, variations of the process, business exceptions and error handling.

…

You will need to go through a requirements analysis and solutions design, just like you do in non-BPM projects!

What is Agile Software Development?          

This is an interesting question in itself. It appears to boil down to a manifesto drawn up in 2001 (http://agilemanifesto.org/) that states:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more.

Why is this interesting? Well, what this says is that we are going to let individuals have more say, less documentation, collaboration with customers and a more dynamic approach. All that sounds very laudable, and I agree. After all, what we had before was a rigid and almost unassailable IT-driven design, incomprehensible documentation that swamped business users and never really matched the eventual product, rigid and impractical contracts, and rigid and impractical plans that collapsed into disorder when anything unforeseen occurred (and let’s face it, have you ever seen a software project where it didn’t?).

What is wrong with it?
What I do not agree with is when this is taken this too far. What we then end up with (and this example is extreme in all ways for illustrative purposes):

Design by committee, no documentation, no actual contracts, and we’ll make it up as we go.

OK, as I said, it is extreme. But let’s be honest, how many BPM projects have been described just like this? From those inside the industry, be honest now, how many BPM projects have actually been like this?

Far too many. Personally I believe this is the real root of most BPM initiative failures. It is far too easy to do, and far too easy not to realise it is happening, while working in joyful flutter of the ‘Agile Software Development’ progress banner.

What should we do?
OK, so we have to find a middle ground. There are some things that are required of all on-going software development projects to my mind, and these need to be taken into consideration when considering the Agile approach:

Processes are not best designed by a committee
Obviously we need expert and non-technical input, and lots of it. That is where BPM shines, because we now have a ‘language’ of Process that is understood in almost the same terms by both Business users and Developers. That was my opinion when I saw my very first BPM tool in 1997. I was blown away at how simply I could describe the concepts I wanted to design, and indeed build them just as simply. That opinion has not changed a bit over the 15 years I have been practicing BPM myself, before it was even named.

What is required, however, is the ability to design Processes well. Generally most people do not have this skill, and it is best to leave it to someone who does. They need not be technical at all. In my experience, most software developers do not understand ‘human’ Processes as different from computer processes, and so are not good ‘human’ Process Designers anyway.

Software must be documented
Well, most software (exceptions at the end). Generally, the problem you get if you do not document software well is that it becomes unmaintainable. The trouble starts when you are pushed ahead to work on some more development, as documentation is not seen as providing any ‘Cost Benefit’. The cost comes when that undocumented system needs to be updated or fixed. The effort required to diagnose faults in undocumented system is ridiculously high compared the effort of documenting it during development. It also requires your best and most expensive resources, whereas documentation does not. The same applies to functional changes and enhancements. And how many systems are developed that do not require changes?

Just putting comments in code can massively reduce the time taken to understand it. In the best systems I have worked on, there are more comment lines than code. When you see that, you get a warm glow because you know that the job will be easier. The same applies to well-documented Processes, of course.

Contracts are still required
I agree with collaboration over contracts. Unfortunately a contract is only really useful when it is too late. What it does do, however, is outline the responsibilities and expectation of both parties. That is important.

Generally, when writing proposals, I try to put as much of the original requirements in the proposal as I can, but in our own words. In this way, we can demonstrate our understanding and invite discussion when that understanding has not been good.

Changes need to be managed
Responding to change is vital, as the world of software is always subject to change. A rigid project plan is just a pre-ordained failure in my opinion. Contingencies need to be built in as much as possible, and change management procedures clearly outlined. All software development project plans should be designed like this.

In my next post, I will discuss why, and when, one would use Agile Development, so stay tuned! In the mean time, I’m curious to understand: what are your thoughts off and experiences with Agile Software Development?

Follow