If you're like us, you've got a reasonably well-documented expectation for how your engineering should get done. Setting aside the particular methods of a team (agile, kanban, etc.), your work ideally moves from idea to deployment in as straight a line as possible.
That's the textbook answer, anyway. But out in the wilds of development, how is your work actually moving?
Using ourselves as customer zero, we set about finding out. Pinpoint's Issue Workflow view analyzes the raw activity data of actual work as it occurs (derived from Jira, in our case), and converts that raw activity into an interactive, diagnostic graph.
Looking first at our epics, here's what Issue Workflow showed us:
Initial epic workflow (the 'before' picture)
Data mavens and graph hounds will recognize this as a Sankey diagram. The vertical blue bars represent the different work statuses that our Epics moved through. The volume of work moving through a particular flow is reflected by the width of the gray (or red) band. Red bands indicate where work went backward, reverting to an earlier status.
Seeing our own epic workflow illuminated this way, our feeling was: That's too much. Too many exception flows, too much reversion. For an organization our size (i.e. not Google), it shouldn't be so difficult. Armed with the knowledge of the on-the-ground reality, we could see where and how to eliminate waste from the process.
Four months later, here were the results:
Revised epic workflow (the 'after' picture)
Swift, consistent, simple.
Admittedly, the complexity we were solving for is a far cry from what a larger organization faces. How far? Consider the following example, anonymized but based on real data, drawn from an organization of several hundred developers across multiple locations:
Hairy, yes. But no cause for panic. The first step in solving a problem is knowing there's a problem…