The perfect business process management system (BPMS) hasn’t been invented. Perhaps it never will be. However, that hasn’t stopped countless attempts to create the next wave of BPMS solutions. One of the approaches getting attention today is the combination of Agile development methodologies with business process management. It may not be a match made in heaven, but it seems to be producing results.
Since it burst on the scene in the early 2000’s, the desire to utilize Agile techniques in many aspects of businesses has taken off. You’ll hear about Agile manufacturing and Agile marketing and other seemingly misused commingling of the word “Agile.” However, the place where Agile software development is attributed with getting its start is summarized in 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.
Process Management Evolution
The idea that business process management lives in a silo is false. BPM has continued to grow and change with the business. BPM systems have continued to adopt and adapt to modern technologies. It’s in this way that Agile and BPM have and can come together.
BPM and Agile Together
There is a logical connection point where Agile development and business process management ideals can come together. BPM is all about the rules, follow through, dealing with exceptions, and back to more rules. This is the way business process management professionals think. This is how they are taught.
Of course, BPM has morphed and changed over the years to include more complex flows, including routing, re-routing, wait states, extremely complex rules, recursion and recursive processes, and a plethora of ways to included process iterations. All in an effort to insure the process can be documented… because a documented process can be followed.
Agile development runs almost 100% counter to this mentality. Agile values the individual over the process and prefers that something works versus something being documented. Agile prefers the human element to the business element. And, Agile allows for change instead of taking the planned path.
This last point is what may be the saving grace where Agile and BPM can come together. Since Agile values the human element and BPM has traditionally focused on the process over the people there is a logical connection point here. BPM systems are morphing to allow for ad hoc routing and exception handling. Some of these capabilities are the result of customer demands for a more flexible BPMS and others are from advances in computer processing, such as the increase in access and use of machine learning.
The implication is that there might be areas where Agile and BPM shouldn’t be used together. If you look to the “rules” of Agile development, they run counter to what traditionally has been considered the domain of business process management. Advanced computer processing and more powerful mobile platforms have allowed for the development of low-code solution platforms that put the power of Agile Development in the hands of the people that know the processes best, while allowing the IT department to provide guardrails to insure data and process governance.
Where Agile Might Be Heading
Now, it’s all about lean processes and the minimum viable product (the MVP), as espoused by Eric Ries in his seminal work in his book, The Lean Startup.
MVP thinking – In 2011, a book was released by Eric Ries. He espoused a model of thinking that was common in startups, but had not taken off in the corporate world yet: to develop a minimum viable product (MVP) with the highest return on investment versus risk. To do this, a minimum viable product only has the core capabilities to allow it to be deployed and nothing more. The idea behind MVP thinking is to allow for rapid development and iteration and not get bogged down in the minutiae of a traditional product development lifecycle.
In the future, I expect to see more thinking around designing, developing and deploying BPM systems around the concept of holocracy. While it may not make sense that a BPM system can be self-governing, that is exactly what can happen in an Agile development environment.
Holocratic thinking – The concept came to the forefront recently because the CEO of Zappos, Tony Hsieh, committed his company to adopt a new corporate structure: holocracy. The simplest way to describe a holocracy is that there are no more traditional bosses. Holocracy changes how an organization is structured, how decisions are made, and how power is distributed.
In the meantime, it is quite possible and useful to continue to think in terms of Agile computing to create and deploy both simple routing solutions as well as mission-critical BPMS offerings. The methodology has proven itself to be adaptable to multiple business models as well as flexible enough to change when the business changes. I expect we will continue to see Agile BPM solutions for the next few years. However, I also expect we will continue to see development on lean and holocracy-oriented BPMS offerings. Because as the post stated at the beginning … the perfect business process management system (BPMS) hasn’t been invented.
0 comments:
Post a Comment