Your Workflow Already Exists – Are You Actually Seeing It?
TL;DR (AI-powered): Too often teams and organizations settle for either a crude “to do → doing → done” board or an over-engineered list of statuses. Both hide the real flow. The flow already exists; the only question is whether your system makes it visible and manageable — or turns it into a black box that works against you.
Have you ever had a discussion about what kind of statuses, and therefore columns for some kind of board (to provide visibility on work), the workflow should have?
If you have had, I can almost bet that, at best, the discussion evolved around ideas of what good could look like. At worst, most people didn’t really care, and any proto-workflow like “to do → doing → done” (or variations with a slightly different language) was deemed “good enough”.
But here’s the fundamental question that may have been missed:
Do you want your work management system to represent (a model of) reality (and thus make it work in your favor)?
Or are you just using it because you somehow have to (and thus you are OK if it risks working against you)?
Answering that question doesn’t have to be a very thorough exercise, but also shouldn’t either be taken too lightly. And assuming, more often than not, you will tend to see some value in representing reality (and risk making it work in your favor – nothing at all wrong with that, right!?), then let me break something else rather fundamental for you…
The flow already and always exists – it is a ubiquitous thing. All we have to do is make it transparent and meaningfully represent what happens.
Now, take a moment to contrast that with any previous conversation you might have had on this matter, or even think of your current context and how work is being tracked and how. If your experience is at all close to mine, I can also almost bet that you probably have seen this dichotomous pattern at play:
The meaningless overly simplified workflow, which essentially works (in full or in part) as a kind of black box. In which, for instance, “in progress” (or whatever you call in your context the “doing” part of a proto-workflow) is a catch-all for everything that happens after a team starts working on it.
The confusing overly complicated workflow, where someone (or a group of people) did quite some thorough analysis to identify all possible statuses that things could go through (hypothetically), but the reality of whether something is in state X or Y is sometimes nuanced and it’s ambiguous and confusing to properly categorize where the work really is.
Speaking about patterns, at least in my experience and observation, the first dysfunction (over simplification) tends to be a downstream matter (what happens after work has really started from a development standpoint). While the second dysfunction (over complication) is seen more often as part of upstream activities (what happens until something is ready to be picked up development-wise). Although I must say it’s not uncommon to see over simplification on upstream as well – while I can’t easily recall the other way around: over complication at downstream.
Let me assume this somehow resonates, and move forward. Because obviously what matters most is why things like that can matter. And to me, I narrow it down to two pillars which are somewhat intertwined:
Visibility: if getting insight of where precisely we are with work is not immediately accessible as part of the work management system, then I can only assume that, if you get a good grasp of where things are, is coming down at the cost of some additional overhead (i.e., somehow you are keeping that elsewhere, on some ad-hoc basis).
Flow management: chances are that, if the real state of work is somewhat blurred (either by being a kind of black box, in the case of over simplified workflow, or because the overly complicated workflow makes it difficult to properly triage and define the state of things), you are not being sufficiently deliberate and intentional about when things need to change state and what needs to happen for that.
Really, in the end, you lack insight to better understand what are the possible bottlenecks in your workflow, and thus in how you manage work (your processes). And I don’t know about you, but I will always prefer having some instruments so that I, to use an aviation metaphor, don’t need to fly only “by visual reference” (no instruments to guide and signal the right thing to do beyond what one can see or gather by direct observation).
Let’s imagine a concrete example of an overly simplified workflow in the delivery (downstream) side of things – one that’s of the “been-there-done-that” category of issue. Picture this…
At the work level that best matches what customers perceive as (potential) value, and how we even design the work to be executed (effectively a level above the more tactical technical work items that teams break things down to execute), all we currently capture is a proto-workflow.
The implication being that there’s a WIP (work in progress) status that works as that kind of black box: everything that happens from the moment we start working on until it gets to the hands of users, in production, is bundled in that status.
In reality, that means that the flow (oh, you, that ubiquitous thing) might have left out, abstracted away, some states that things go through. The usual suspects are things like:
Sometimes quality assurance is done outside of the team, by representatives of stakeholders or of the user base (it is still rather common in corporations).
Sometimes there’s some kind of governance around how releases are done and changes need to be approved before things can go to production.
Between and around those steps, fundamentally, in the flow of how things really, for the lack of a better word, flow there are effectively queues (waiting to be picked up).
You see where I am going with this?! If all of that, assuming it’s the context and the real flow of how things work, gets abstracted out as a single step in WIP, then all of a sudden you might have lost the ability to have a much deeper insight not only where you are (i.e., on the matter visibility I mentioned before), but even more importantly on the ability to more actively manage that flow (intentionally and deliberately), and with that also decreasing your chances to spot and propose improvements for how things flow.
Once you better represent the flow as your workflow, a bunch of good things and conversations can emerge based on the signals of what we much more easily start to have visibility on, e.g…
Where things are piling up and maybe we were not even sufficiently aware – in other words, where’s our bottleneck?
Does it take too much time for quality assurance to happen?
Or rather it takes too much time for the change to be approved and released?
Or perhaps those stages were rather used as some kind of excuse, and really development is what is taking too long? (In my experience, getting less and less likely, but worth mentioning as in the realm of possibilities)
What are the steps that mostly contribute to the aging of items and thus have the biggest impact in lead time (as a delivery system proxy of time to market).
Are things ‘flowing’ as smoothly as they should be? And what does that inform us about possible need to change and better align processes end-to-end?
That’s what, ultimately, making the work management system work in your favor is about and how it can look like.
To be honest, it often still amazes me how often tricks like these are missed. I don’t mean to say this in a super-critical way about what I observe – it’s just something I can’t help but notice. And I guess it’s yet another reason to keep sharing my thoughts and insights over here, in the hope to somewhat inspire others to dare making (things like) this better.
By Rodrigo Sperb, feel free to connect, I’m happy to engage and interact. I’m passionate about leading to achieve better outcomes with better ways of working. How can I help you?