I've noticed that a number of people have begun to suggest that BPM should employ an Agile approach. As always, in situations like this, one wonders if those saying such things actually have any idea about what an Agile approach might amount to.
Let's start with a quick history of the agile programming movement. The idea of a more flexible approach to programming was discussed widely in the late Nineties and was formalized in 2001 in a book edited by Kent Beck, Manifesto for Agile Software Development. This manifesto, developed by a group of software developers was written to suggest an alternative to what was then referred to the waterfall approach of software development. In essence, the waterfall approach imagined a set of steps or phases, starting with Define Problem, Develop Software Requirements, Structure Development Plan, Execute Step 1 of Plan, Execute Step 2 of Plan….etc. In other words the waterfall approach described a very structured approach that one proceeded to execute, one step or phase at a time. The problem with the approach, especially when working on large software development efforts, is that one often got to phase 3 only to learn that some of the project goals had been changed.
The solution that Beck and others proposed was to develop software via very small steps, creating, at the conclusion of each step, a working version of the proposed software application. Perhaps one week would only result in screens, but the screens could be shown to users who could critique them. The approach depended on software tools that allowed on to create software that would work without an extensive infrastructure having to be created first, often using templates. That type of software had become widely available in the Nineties. At the same time new, more modular analysis techniques (e.g. CASE, Object Oriented Programming) became available and facilitated Agile, by providing ways to subdivide tasks into modules that could be developed more or less independently.
The Agile Software Approach resulted in the creation of modules of software, each able to do something and each capable of letting users get some idea of what the final product would be like. Thus, it allowed developers to interact with users much more frequently. Another emphasis was on small teams of developers — an approach also empowered by the new software development tools created in the Nineties.
Most software shops today use some or all of the Agile techniques developed in the Nineties and the Zeros. Meanwhile, the term bas entered into the popular business jargon, and for awhile there were lots of books on creating Agile organizations — presumably organizations able to change quickly in response to new developments. In this sense of the word, “agile” is rather like “lean” — something that just had to be good for your organization, even if no one knew exactly what it meant.
Stepping back, of course, I'm willing to admit that when any commonly used word, like “agile” (or “process” for that matter) has been around and used in business discussions for going on twenty years no longer means anything except what a particular speaker wants it to mean. It simply becomes part of the babble.
Given all this, is it useful to suggest that BPM should be “agile?” Starting in a narrow sense, its probably fair to say that today's BPMS software tools rely on elements drawn from agile tools created in the Nineties. In essence, they allow one to create a high level look at a process and then begin to define one subprocess that can, with enough specificity, generate code that allow end users to explore the use of the software application. Perhaps the newer iBPMS tools that rely on rules and interpreters are even more in the tradition of agile tools.
The main emphasis of many comments, however, have not been on the tools so much as on the methodologies. So, maybe a better question is the degree that BPM development practices rely on Agile approaches. Ignoring software for the moment, one can develop a process redesign in phases. If the process redesign is complex, it can take months to redesign and implement. Some methodologies try to focus on identifying specific subprocesses or activities that can be improved more quickly — in effect rolling out process changes in incremental releases. Some would suggest that both Lean and Six Sigma, when used as incremental process improvement methodologies are operating in the spirit of an Agile approach. Even if we accept this premise — and we think it's a very reasonable position — it leaves us with questions about existing formal methodologies for process redesign.
Most process redesign methodologies that we know of mix a bit of the Agile approach with a bit of the structured waterfall approach. They begin by defining the problem, and then apply analytic techniques to define the problem. One could imagine a team that defined a dozen activities that needed to be improved and then redesigned, implemented and fielded each module, one after the other, in the Agile manner. The decision to take this path has more to do with decisions made by the sponsor and the project manager than by process practitioners.
In essence, almost all BPM can be delivered in small increments, and few BPM projects, today, are allowed to run on for 18-24 months, as some large projects were in the Nineties. BPM many not use Agile as a formal approach, but its ideas have been informally incorporated in most BPM practice. Similarly, when using BPMS tools, its easy to develop BPM applications more incrementally than they would have been in the past. So, at least informally, most BPM today reflects the influence of Agile techniques.