Paul Kompare, SVP of commercial banking technology at JPMorgan Chase discussed their Pega implementation of a straight-through processing infrastructure for commercial loans. He gave us a brief view of the current environment and the proposed solution, then moved on to discuss their agile implementation approach. Although they refer to this as Agile, it’s still a bit waterfall-like: the sprints don’t result in released code, but in checkpoint demos, and these are the points when the business representatives interact with the development team rather than being a co-located team (which likely would not have been possible since they rely heavily on offshore development resources). However, it’s a big improvement over their old waterfall methodology.
They delivered the project in two phases, each with three iterations:
- Happy paths and primary flows
- Exception paths and secondary flows
- UI, integration and reports
In each iteration, they establish and sign off on the criteria, then use Pega to directly capture objectives and model the processes. With this relatively agile process, they improved project sponsorship as well as getting early buy-in from the business, since they were able to demonstrate something earlier and more frequently. Using PRPC also gives the business managers more visibility into the business processes and their underlying logic, rather than having those processes locked up inside opaque application code. They found that the tools gave them more agility and flexibility during implementation, greater reusability and faster time to market, as well as allowing potential changes to be identified earlier.
They did have some challenges with adapting to an agile approach: this type of approach assumes that changes to the design and functionality of the system will occur during development, and relies on rolling out a phased series of small, self-contained components. From a funding standpoint, it’s almost impossible to issue fixed-price contracts for agile development, since there is not a really fixed statement of work on which to base the proposed price. I’ve seen cases where a third-party services firm doesn’t really get agile methodology, and there is a huge amount of overhead as they attempt to shoehorn their waterfall deliverables into each iteration of the agile development, or they just abandon the agile approach and go back to waterfall.
There’s also major changes to roles and responsibilities: the business participants have much greater responsibility during design and as the system rolls out, and having them trained in the design tools is critical.
He concluded that adopting agile development methodologies has been a challenge for them, but that it’s definitely helping them to achieve shorter development cycles. There’s very little here that’s specific to commercial loans, Pega implementations, or even BPM; these same factors would be seen in any organization shifting to an agile approach. However, Kompare made the point that they were driven to consider an agile approach because the Pega tools tend to work better in that environment than with a traditional development methodology.