Visibility of Effort
So you have a tree??, and you have your tree ornaments ????????, and you have your presents ?????? underneath.
Can you tell how many in one look? How many presents? How many glitter balls? Oh, I know what you’ll say — “Who cares? It’s the outcome that matters, the happiness that the tree and all its ‘components’ bring to one’s life!”
Still, bear with me…
Have you ever played “Guess the number of lollies ?? in a jar??”? Guess and win this awesome prize! 996! 842? 1,117? Not even close!
It’s all fun and games until you have to do it at work—looking at a list, a pile, or (as is in my case) a mountain ?? of issues, stories, and tasks. I am a rock, I am a mountain, I am a formidable foe… The waters that flow around me — whisper the words: “I know.”
And the mountain shifts and changes every day — some of these tasks get resolved, some are updated, new ones are added, subsets are moved to another pile… When I move — the world trembles. It’s silent when I am asleep. Whenever an avalanche happens—people are thinking of me.
With just a team of 25, whole forests of Epics with long trailing “roots” of stories and tasks appear daily as our team analyses and breaks down work to implement crazy ideas that Product Management comes up with. Imagine what happens within organisations of thousands…
From the point of view of the Jira gods (and no, I don’t mean Mike Cannon-Brookes and Scott Farquhar ), we, our teams, and our companies are nothing but machines for processing issues that either track real work (like tickets in JSM or bugs and features in Jira) or, more and more these days — just the “luggage tags” ??? linked to work ?? being done elsewhere, all for the sake of product, project, programme, or some other type of “management.”
It’s hard to argue that we process these effectively — the number of issues we see every time we do a Server to Cloud migration is mind-blowing. It is no wonder that “archiving” was such a coveted feature. Jira has come a long way since 2002, and some companies have literally created mountains of records. And after all, these companies are still in business, somehow fulfilling their core purpose, so surely none of this “work” is just pretence?
But are we processing this work efficiently? ?? Now, this is the question! ??
Ditching the related very obvious concerns of costs and budgets, how about verifying the correctness of your estimates — not just the time ones (does anyone still do that these days?) but the story points ones (and please save me from the T-shirt-sized ones), the ones that are supposed to reflect complexity. With something marked originally as “complex”, was it actually complex? Were the perceived risks real? Was the work spent on mitigating them worth it? Where can we do better next time? What pitfalls can we avoid? Are our processes consistent and repeatable?
People often talk about eliminating bottlenecks, but even in The Phoenix Project, the author had to invoke the metaphor of looking at the factory floor from above to see the whole picture. However, the term “visibility of work” often thrown around has been completely co-opted by the “planning crews” — the desire to see what needs to be done so it can be neatly laid out over the available resources’ capacity and, ultimately, onto the calendar. Are we there yet? Is the “traffic light” ??green or yellow, or crawling into red?
领英推荐
The “actuals,” though still mentioned in some organisations, have either become a blatant lie with everyone just submitting perfect 22 days of 8-hour timesheets at the end of the month ?? or replaced by the team velocity based on the number of story points burned down and thus treating teams as a standing capacity of a certain throughput (and a sunk cost). Some enterprise customers go as far as to build statistical models of their workforce in the context of public holidays, seasonal sickness, and annual leave patterns to predict changes in the expected throughput from month to month.
It doesn’t help when the tool itself doesn’t let you easily select issues pertaining to a single “business project” from the “soup” of everything else and report on the actuals accordingly. If your whole team is dedicated to just one project — count yourself lucky??. If your organisation creates a cross-functional team for each business project and just gives you one Jira project to dwell in — count yourself lucky??. What if, instead, the business project spreads itself over multiple teams — development, marketing, support, and infrastructure, for example? Or, as is often the case these days, it spills into legal and HR spaces and possibly even finance. Bigger enterprises practising Scaled Agile Framework principles will be familiar with this — the whole ecosystem of Atlassian Marketplace apps has sprung up to assist with the visibility of work included in “planning increments” where work done by Programme and Project management is not done in Jira anymore, but rather Jira merely serves as a database being updated by teams with their progress indications.
However, if you want to select all issues for just one business initiative and put it on a wallboard, for example, you are out of luck. Certainly, you can just label them all easily enough, but remember, the mountain ?? moves and breathes, erupts, grows and shifts...
The analogy with the lollies jar is nice, but the size of the jar doesn’t change from day to day. Would anyone cherish the work of tracking the changes down and manually relabelling everything every day just to be able to run a report? ??
One of our government sector customers complained that his team congratulated him on actually delivering the project. Since when has this become a badge?? of honour? I realise that in the world of instant everything, anything that drags beyond a week is just too long, but really?
“Senior leaders often underestimate how much effort is needed to reinforce the strategic direction of a company at every level.” Sure. Sure... “Senior leaders often underestimate how much effort is needed.” Period.
As consumers of goods and services we are all rewarded by the outcomes, but as workers that produce these — we value effort. Effort is important. Effort isn’t just a number — it’s the key to making informed decisions, justifying priorities, and celebrating your team’s contributions. Effort deserves to be seen.
Whether you are an IT or DevOps team looking to report on cross-functional projects, a Professional Services team looking to bill the customer for a project as a whole, or an Agile Project Manager looking for a breakdown of resources, or the Finance team calculating capitalisation or ROI — the outcomes only tell part of the story.
And, in my opinion, finding the other part shouldn’t be a quest. How many lollies are in this jar? ?? ?????
Looking at our own office Christmas tree, completely failing to grasp how much effort went into making it light up the room (speaking both figuratively and literally) — I think the “Visibility of Effort” theme TechTime Initiative Group Limited has chosen for 2025 is fitting.
Head of Services at TechTime
2 个月Visibility of effort is a great theme. I immediately thought of aerodynamics analysis where you plug a model into a fancy program to find patches of the surface with bad airflow. How can you begin to make improvements if you don't know where the "air" (or effort) is flowing poorly? And when you do fix one rough patch, are you creating another?
CFO, CTO, Founder at TechTime Initiative Group
2 个月Credit for “Senior leaders often underestimate how much effort is needed.", and specifically in its abridged form, goes to Brad Quirk https://www.dhirubhai.net/posts/bradquirk_in-2024-i-learned-that-true-clarity-isnt-activity-7277845901665058816-TYN6?utm_source=social_share_sheet&utm_medium=member_desktop_web