For most application workflow projects, the Agile development methodologies have proven a superior approach over the traditional waterfall method.
But even with a proven delivery method like Agile, insufficient understanding of business processes can derail your project. This is especially true when the project involves a complex workflow component.
What Makes Agile Projects with Workflow Components Different?
Projects with workflow components require developers to address end-to-end business processes early in development in order to properly build an application aligned to business needs. This planning provides an architectural pathway that developers can use to properly automate the workflow components of an application.
Many Agile projects begin without proper planning around end-to-end business processes because the team assumes details will be worked out in iterations along the way. Unfortunately, this lack of up-front preparation can be damaging to the project.
Here’s an Example of What Happens Without Adequate Planning.
I was recently involved in an Agile project with Appian, a new, enhanced workflow automation tool. I also had visibility into another Agile Appian project that was occurring simultaneously to mine, but in a different functional area. Here’s how they broke down:
|MY APPIAN PROJECT||THE OTHER PROJECT|
|FRONT-END PLANNING||We took time at the front-end of the initiative to focus on the process analysis and pre-work.||The team developed documentation for numerous low-level business processes.|
|END-TO-END PROCESS PLANNING||We designed the end-to-end business processes, including key exception paths prior to the developers hitting the ground.||The team didn't take the time to design an end-to-end business process.|
|THE RESULT||We designed, developed, tested, and deployed the new application solution in less than 6 months, in an environment where a traditional application change takes much longer to complete.||The project team was months behind schedule/expectations as they were still unable to connect the disparate code modules into a coherent application.|
Why Did the Projects Fare so Differently?
In my Agile project, planning for end-to-end business processes enabled us to properly communicate context to the development team before they’d begin work on automating specific parts of the workflow.
The other project saw different results because the team was busy automating workflows without guidance or context on how to integrate the end-to-end business processes into a usable, functional product for the customers.
How Can You Avoid a Bad Project Outcome?
The two scenarios above highlight some good practices, but also potential pitfalls. Use these 3 key planning activities to keep any Agile project with a workflow component on track:
- Design the end-to-end process early: Spend a sprint at the start of the project designing and documenting a coherent, feasible end-to-end business process with the customer experience in mind. You may not know enough at the start to design the process at a tactical level, but creating context will allow you to articulate the questions at the tactical level, therefore reducing re-work and providing the development team with direction.
- Propose key exception flows: Having the end-to-end process design allows you to start asking intelligent “what if” questions. The more you understand the flexibility your business process requires, the better the team can start to architect how to address those flexibility requirements and code accordingly.
- Embed process analysis/engineering in the development team: Every sprint will involve discussions on user stories, acceptance criteria, and user experience. These design discussions often have end-to-end business process implications that need to be considered. The process analyst should help the product owner review user stories to ensure development is staying consistent with the business process; this practice will mitigate the risk of creating unintended consequences up or downstream.
Do you have experience working on a workflow project in an Agile environment? Can you credit upfront business process planning with your success, or perhaps blame a lack of planning for your struggle? Drop a comment below—I’d love to hear the outcome!