Teaching an old dog a new trick is difficult. At least your dog will not talk back to you and tell you that you are making a mistake. Introducing the concept of BPM to ANY developer is not as easy as many would think. This article will share the challenges I experienced and offer four steps to minimize the unnecessary painful transition so that you can work with your developers to achieve the goals sooner.
Why is there even a challenge/pain to get your developer on board with using BPM?
Warning: The more experienced the developer is, the more resistance you will face in the initial stage.
Developers have been building the application in a certain way for a long time. It will be difficult to imagine why it is necessary to break that perfect process and sequence into different chunks to accomplish the same goal. Many times, the initial reaction of the developers is that this is unnecessary.
Within the software development paradigm, most of the developers (the good ones) should be very familiar with the concept of decoupling, modular, and componentization design. They all understand the concepts of how to build a well-architected application.
The developers who had great success at building an application in the past already developed a solid reference frame for developing an application. It's proven, and it works. They strongly believe in the concept of "if it ain't broken, don't fix it."
However, the BPM development process will break that frame of reference. It requires the developer to "give up control" and let the BPM framework take over the process orchestration. It is almost like learning a new programming framework, and that framework will make you feel like you have lost control of how things are working.
Many developers believe that the BPM framework's introduction will slow things down, and they can build the same application functionality without BPM faster and cheaper. That is the root cause of the contention for the developer to adopt the BPM transition.
To avoid the challenging situations above, you can consider these four steps to ease the BPM transition process:
1) Communicate the big picture as clearly as you can
First of all, you, the decision-maker, has to be 100% certain about the decision to go with BPM. If you ever show any sign of hesitation, the developers will "smell the blood" and further challenge the decision.
The decision to leverage BPM is for long-term strategic business reasons. You need to be able to articulate that vision to the developers. So that you both understand that and sincerely commit to this vision together.
2) Illustrate the business benefits as much as you can (forget about the technical part)
Understanding the vision and strategy is just the beginning. Most people perceive that developers are techies and do not care or need to know about the business benefits. For the best developers and those who will have the most resistance to move to BPM, they care a lot about it. It is critical to illustrate the business benefits to them. Prepare to spend some extra time to make sure that they understand and (truly) on board with it.
3) Show, don't tell
Switching the design and implementation to BPM is a very abstract concept. Even the developers understand the business vision, strategy, and benefits, they will still doubt the implementation level.
First of all, anything new is dangerous. It is human nature to avoid uncertainty and pick the proven path. Experienced developers will require proofs before they will jump off the bridge with you.
It will be beneficial to hire experienced BPM developers who can show and illustrate the BPM development process. Also, consider creating a prototype application with the developers to demonstrate how everything works together.
4) Set proper expectation on the productivity
When the rubber hits the road, the real test will begin. It is very typical to experience a slow start for any developers to get into the BPM development process. There is a new way of solving the problem, new tools, new ways to break down the business logic, new ways to test the code, and a new way to communicate the overall progress.
All good developers have some ego level, and they all have a reputation that they want to keep. In their mind, they will always compare how they would have done it before against the new BPM way. There is no comparison in how quickly they can get the "same" thing done if they can do it the way they know the best.
Frustration will be there. Expect that and manage that. And understand what the developers are going through. Clearly express the understanding that productivity will not be the same initially, and you will have a different set of expectations on them. From your side, you also need to adjust your project schedule to accommodate the initial learning curve. In my experience, it could take three to four months for any developer to entirely onboard and develop at full speed in BPM.
If budget allows, hire an experienced BPM expert to guide the team through the initial phase of transformation. The money spent will be well worth the team's time, rather than to struggle through and become more frustrated.
Behavior changes won't happen overnight, and it requires continuous reinforcement to change. Your older dog has been your best friend for a long time. Give him/her some trust and faith. As long as you know the proper method, everything is possible!