Easy; just renaming your 'process improvement project' to 'sprint'
Copied from a comment later on:
Agile BPM...I would never combine these terms. What it would mean to me would be something like flexibilty and adaptabilty of processes.
I don't want to make BPM more agile. I want to make my business more agile.
The challange is agility within a regulatory compliance framework. Compliance is a factor in every maror company and particularly inflentional in certain industries: Financial Services (FSA), healthcare (HIPAA), Life Sciences (FDA), Food (FDA) and Energy and Construction (HSE)....
Just apply agile development practices to what you're doing. We've been doing this a long time at BP3 and before BP3. I use agile with a lower case A because we take into account particulars of platform and UI development technique in the context of a BPM project. Recently we started putting a name to the method that we use just to have a short-hand for referencing it, but really there's no secret - all the secrets are published in blog posts and books - you just have to put them to work...!
We have adopted the use of wire frames. Good business analysts (BAs) can guide innovation (steps to reducing process waste while improving the overall experience) and design (how the user interacts with the solution) by using wire frames to help users visualize user experience during every step of the overall process. The visualization allows the consultant to explain how data is captured and the users to understand and determine layouts. For example, in the UI users should decide what data should describe a work item and how the data is broken out into rows and columns. This exercise also helps users understand how form data (the list values and free text captured in each form field) and process data (touch time, turn around time) is published to the user interface. As users connect the dots, they become better analysts and designers themselves. They also often remember data and/or key metrics that somehow fell through the gaps during requirements analysis. So the use of wire frames not only help users understand how the application works they also help developers to quickly code/configure the end product. Projects go faster and smoother.
1/ Model and execute processes directly in your IDE.
2/ Model and execute business cases as Cases (either as per BPMN 2.0 with ad-hoc tasks or as per CMMN 1.0) directly in your IDE.
3/ Model your data model directly in your IDE.
4/ Model your interface directly in your IDE (or use something that can easily export the HTML / CSS / JS code - no, please, not friggin' Balsamiq or wireframing tools).
Have an IDE, while you're at it.
What does this have to do with agile? Because in an IDE you can iterate the cycle design - build - test - deploy
Agile used to mean something. These days, however, it is just a buzzword to try to make broken companies look better than they are.
There is a basic marketing rule - if something says "finest" on the label, then it probably isn't. If it was good it wouldn't have to say so.
Like "innovation", "best practice" and "customer-driven", "agile" is just management speak for "we have a problem getting things done in this company. But I'm one of the good guys - it's the others".
But there is an important thought in behind.
Back in the pre-computer days of Time and Motion, Lean and Six Sigma, the world was made of physical things. Those things were hard to change.
All the effort to collate data, add it all up and turn it into a justification for a process was massive. So people only did it once.
That created the idea that fixed was normal and change was the exception. Something to be done only when you had to.
And good reason to force it through a rigorous management process which made sure it wouldn't upset the figures which came off the fixed process.
One reason why animals and plants exist is that we are made up of cells.
Change is easy - indeed mutation happens all the time whether we like it or not.
When something changes in our environment, we find that some of us have adapted to cope, or even thrive.
Survival goes not to the strongest, or fastest, but the one most adaptable to change.
Like AB testing, really - those who were adapted would survive, the others disappear.
Our business world is now made up of pixels and bytes.
Change happens in an instant, all the time, all around us.
Indeed change is now the default - fixed is the oddity.
That means we can throw out all those fixed state business models. Porter's Forces, Balanced Scorecards etc.
Throw out all those Change Management textbooks too - the one which treated change as a rare event to be managed.
Fixed business models and fixed processes will always be at a disadvantage to those which move forward continually in a state of change.
What we need to do now is design processes which evolve. Which gather data on the environment they operate in (after all data isn't hard any more).
Which use this data to AB test continually, adopting the winner each time, then repeating the procedure to create a truly evolving process.
Always the best option for its current circumstances, yet able to reinvent itself andmove on when those circumstances change.
That is truly agile. And it is the future of BPM.
True "Agile" programming means abandoning documentation, making it difficult to maintain or modify the program. I do not believe this is the direction you want to go. Instead, better training of the Business Analyst is required. They must learn such standard concepts as defining information requirements, logical vs. physical design, transaction processing, the basic constructs of sequence/iteration/choice, work flow analysis, developing test criteria and test plans, etc.
Good subject for a book, frankly! But for the sake of brevity, I'll select just one of the principles of agile development referenced in the question:
“Work not done.” I love that. For BPM, this might mean, for example:
If for nothing else, BPM exists to increase the volume of work not done when solving business problems.
Agile is a slippery concept. My question is "Why be agile?" in the first place.
Micro-agile applies to better and faster construction of software artefacts; macro-agile applies to adaptation of enterprise to changing conditions. Clearly it's better to be flexible when constructing complex technologies; Soviet-style top-down waterfall development is inherently flawed (although strangely popular in "capitalist" organizations). As for whole organizations, certainly it's probably a good idea to try and adapt to changing business environments (although it didn't work out too well for Kodak).
But for agile to work, at any level, requires a concept of identity and purpose. Otherwise, agile and adaptation are just opportunism. Or a random walk. A random walk actually works in nature. Evolution is about the survival of successful adapters.
But at the individual level, evolution results in failure for most entities. This is just a fact.
Consider evolution in business. We have seen the death of rather too many Fortune 1000 companies over the past decades. So by all means, lets speed things up, be agile and adapt. But without leadership, we lose our identity, we are only opportunistic and we embrace the evolutionary risk of a single insect. (Investors likely don't want to hear that you are going to be "agile".)
OK, the original question was not about leadership, but I take it that one cannot ask about agile without considering leadership. In this context, I like the following quote:
"As a guiding principle, however, adaptability is analytically useless for doing what any coherent strategy must do: specify where we do and don’t play in specific markets and how we propose to win in places where we do choose to play."
”There’s No Excuse for Avoiding Strategy”, by Frank V. Cespedes, Harvard Business Review, October 28th, 2014
BPM is already agile because BPM implements the agile manifesto.
“Individuals and interactions over processes and tools” obviously, modern processes and related tools are much better than 15 years ago and they are real enables for efficient interactions between individuals
“Working software over comprehensive documentation” thanks to modern DSLs (primarily BPMN, CMMN and DMN) a lot of business artefacts are captured directly in executable formats and maintained directly by business owners. No needs for intermediate documentation.
“Customer collaboration over contract negotiation” modern IDEs are perfectly implementing this by enabling pair (customer & BPM-suite specialist) development of process-centric solutions.
“Responding to change over following a plan” the combination of classic workflow and case management is the way to do this.
Agility is a wide concept, I will take the point of view of the CEO of a small/medium business who involves in some degree in the tasks of automating and optimizing their business processes. Let's call him Lucho.
Lucho wants agility when automating a process for the first time, but want it more in the subsequent improvement cycles. So Lucho will find his BPMS agile if and only if:
For example, an integral SaaS & PaaS approach as Flokzu BPMS or our INTEGRADOC suite in SaaS mode would be good examples.
Agile is a way (and IMO a pretty good one) to be able to anticipate fast moving developments. However and whatever these developments, you still need to be in control of your processes.
So, not the process it self needs to be agile per se, but the way you manage them. And IMO this difference confuses many when discussin BPM. Which seems strange to me, as the phrase Management is part of the very acronym...
Key to this is do your research to find the enterprise level software that supports "Agile" build direct from input by users. Then explain to users how it delivers and show how their ideas now matter!
Once business get over the shock that there really is this new Agile way to help them do things better a new door opens with no turning back....So do that research ask relevant questions and get answers all in business language.......
Agile implementation if one of BPM keystones; it isn't BPM if it's not agile.
BPMS technology speeded up business process implementation and improvement by order of magnitude comparing to typical ERP project. From my experience, it usually takes 2-3 months to implement first production release of a fairly complex executable process and 3 or 4 weeks for successive releases.
Yet today many customers want more:
So there is a lot we can do to make BPM even more agile.
To make BPM more agile, you need to focus on the processes!
That means forgetting about extra programming, code, installations, complex set up, having an already secure infrastructure which already defines user levels and enables permission setting.
A SaaS BPM Suite that has all that (such as Flokzu) will let you focus on what really matters: the processes.
Oh noes, Agile is dead, too? *SMH
Sometimes when I come on bpm.com I feel like in a cyberpunk novel: a decrepit graveyard of zombie technnologies, dead frameworks, failed methodologies, half-buried tweeting fridges with rusty USB 2.0 ports, IoT drones flying against a darkened sky of incoming economic crises, and a toxic green AI brain floating around in an augmented reality visor shooting random process tokens into pale, skinny customer passersby.