Working towards agile BPM
Most organizations want to move to agile delivery, and for good reasons. Agile promises both to be much faster and to result in functionality that is closer to what users really want. In addition, agile allows you to declare success earlier on, building user buy-in.
BPM platforms look like prime candidates for agile. Their rapid application development capabilities lend themselves to working with business representatives to illustrate and refine requirements in iterative design sessions. However, some early agile BPM projects have run into problems, raising the question of whether agile is actually possible for BPM.
The real issue is that many user organizations are not yet ready for fully agile BPM, however attracted they are to the benefits. Experience shows there are four main groups of obstacles to agile BPM, the first of which is the most critical:
Rigid procedures and code freezes Large institutions tend to have rigid procedures, particularly around testing and deployment of mission-critical core applications. These tend to require significant regression testing and, crucially, twice-yearly code freeze windows where new code cannot go live. If the new BPM code must integrate with applications that are subject to these restrictions, testing and releasing that code in an agile manner will be difficult.
Unwillingness to accept incomplete code Agile means accepting software in small stages, and perhaps introducing manual workarounds to deal with the fact that not all components are initially available. However, it is often difficult to negotiate exactly what functionality the business can do without, and how much impact on business as usual the stakeholders will accept.
Non-availability of subject matter experts (SMEs) Agile needs dedicated business users, co-located with the development team and with the authority to sign off requirements. Some organizations are unwilling or unable to make suitable SMEs available full time.
Lack of agile experience within the IT function Many organizations have little experience of running agile projects. Infrastructure and support teams, too, may not yet be geared up for rapid delivery of code into the live environment.
You can use the points above as a checklist to see if your organization is ready to go fully agile. If not, you can adopt what I’ll call a hybrid approach: one that introduces your organization to the benefits of agile but makes some compromises.
With true agile delivery, there is a series of code drops – small sets of prototype components that get accepted and put into production so that the live application is built up in stages. Agile delivery teams consist of end users and developers working together with a minimum of formal project ceremony and little or no documentation.
With hybrid delivery, you still use iterative techniques to deliver the code, producing small sets of prototypes that are not thrown away but evolve into the live software. However, they don’t go live until a largish, self-contained segment of code is available, so users can accept and implement the system in a more conventional, waterfall-style manner, and deployment can fit in with code freezes.
Hybrid projects can compensate for the fact that SMEs are not always available by documenting requirements with use cases, as you would in a conventional development project. For hybrid delivery, these can be fairly lightweight – they just need to give enough detail to allow the developers to get going on a build. The requirements are then refined through frequent playback sessions of working code with the SME community. (This means that, as in true agile development, SMEs must have the delegated authority to sign off requirements, otherwise development will be delayed.)
Even if you have to compromise at first and go for a hybrid approach, you can work to bring about the cultural shift that your organization needs in order to embrace true agile development. This will often become easier once the business has seen the benefits of a hybrid approach.
The real question, therefore, is not whether agile BPM is possible, but when.
Many thanks to my colleagues Raj Sharma and Mandip Panesar whose accounts of their experiences have helped me write this piece.
