Workflows are not typically something that people get excited about. Workflows are typically some form of codifying a process from start to finish. Perhaps workflows have specific status gates, quality control measures, or even automated triggers. But, in many cases workflows are static and not regularly “managed”.
Standard Workflows
While the following thoughts around workflows can apply to many areas; consider the world of software development — and specifically consider the use of the ticket/release management tool: Jira. Without getting into complex configuration details, it can be said that workflows are usually manually set for a team or group. Workflows are set similarly to the workflow to the left.
The above is a useful standard workflow for agile software development. It tracks everything through various stages of refinement (pre-grooming/grooming), development, review, and acceptance. Additionally, a lot of metrics can be gathered from the movement of tickets/etc. through this workflow. However, this kind of a workflow can be improved to create a dynamic process flow, by incorporating some non-standard ideas.
The Avant-garde Workflow
Two newer ideas being implemented into Jira workflows are:
Statuses should usually not have “gates” post-refinement. tickets/items should be able to move freely up to the point of merging or acceptance. This reduces the chance of a stalled item or extra administrative overhead.
Workflows should incorporate statuses which encourage a pull-based flow. Workflows should encourage the movement of work, through explicitly exposing the current status and/or bottleneck. This thought process is taken in-part from the idea behind “Kanban Guide for Scrum Teams” https://www.scrum.org/resources/kanban-guide-scrum-teams
An example of how a pull-based workflow might look is as follows:
Workflow process order: top to bottom and then left to right
The above workflow incorporates the two newer ideas listed, and encourages a “pull” type flow. This allows tickets/items to move into a given status of the workflow on a more granular level.
For example: An item will leave the “Dev” stage and move to the “Ready for UI/UX Review” stage (assuming a regular circumstances).
Benefits of an Avant-garde/Pull-based Workflow
Beyond the obvious granularity and exposure of statues specifics, a pull-based workflow allows for the collection and review more nuanced metrics. The golden nugget of combining granular statuses, along with metrics, is valuable due to two primary things…
Teams/groups have a better understanding of “where” something is in the workflow, and who is responsible for it given its current status.
Teams/groups gain better insight into their historical & potential throughput through detailed metrics, including expanded cycle time.
Here is an example of the way cycle time can be observed for a team using a pull-based workflow — displayed using the ActionableAgile plugin for Jira:
