Gartner BPM: The New Agile BPM Method, David Norton

This morning, I attended with David Norton’s session on integrating BPM and Agile software development methods. In BPM, we always talk about how BPM brings agility to business processes, but what facilitates that agility? Although a lot of this talk is about Agile, it’s definitely valid to look at how to apply Agile methods to BPM projects, since there’s still some amount of software development in almost every BPM project.

He started with a review of software development methods: architected model-driven (including BPM, where you draw an executable process model rather than writing code to handle work routing), architected RAD, and Agile. He then drilled in on Gartner’s 10 principles of NeoRAD (an example of Agile), such as close involvement of the customer, peer review and an iterative approach.

BPM needs to be a mix of agility and discipline, but not a waterfall methodology that we so often see used by old-style development teams when they take on a BPM project; BPM is predominantly architected model-driven because of the executable process models, but also uses some aspects of architected RAD and Agile since there are integration and UI components that require development beyond just the process modeling stage.

He described the principles of Extreme Programming as a coding methodology, and Scrum as a way to manage agile development projects; Scrum, in particular, has a lot of useful concepts that could be applied to BPM projects. He also covered Dynamic Systems Development Method, a type of RAD framework that includes the concept of turning an operational prototype into the end product to reduce waste and time in the development cycle, and Lean Software Development, focused on reducing waste and defects in the same sort of way as Lean works in the manufacturing sector.

He then looked at how BPM release cycles — continuous cycle of design and optimization, iterations of under six weeks, new policies and rules in a day — and how they are much more aligned with Agile methodologies than the traditional waterfall approach, which typically sees the first release in 4-6 months (in the best possible case). Unfortunately, most development teams inside organizations are still stuck in waterfall methodologies, and third-party professional services firms are more motivated to suggest long development cycles with large development teams. That means that even though the process model might be done as zero-code architected model-driven, the (often excessive) customization that happens in the component/service layer and the user interface drags down the project schedule.

This presentation was really much more about Agile than BPM — sometimes Gartner makes a bit of a stretch when bringing in their analysts from other areas and trying to make them BPM-ish — but if you’re not already looking at Agile development for any BPM-related project, you definitely should be.