Agile Delivery in Hostile Environments

Publish date:

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 […]

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.

Related Posts

agile

For Scrum and Agile experts, starting a new assignment with the right questions is the answer

Rik Pennartz
Date icon September 10, 2020

How a measured, practical questionnaire can help you hit the ground running – every time

ADMnext

Your path to Agile at Scale: avoiding common pitfalls

Robert Wegener
Date icon August 5, 2020

How a focus on people, change management, credibility, and honesty can form your foundation...

agile

Agile and architecture – lessons from the trenches

Ben Kooistra
Date icon April 28, 2020

Scaling agile teams is a necessity to stay agile and keeping up business value. The agile...