Work that is done by someone or a group of people that is not tracked anywhere is invisible work! This could be something that is an interruption to your day, this could be a side project that you are doing with someone else in your organisation, or anything along these lines, that is not covered as part of your daily stand-up or updates.
In fact, no one apart from those involved in the work know that this work is being done and it doesn’t really have many stakeholders apart from the ones doing the work.
Top secret projects or something strategically significant that you run a secret project that is well protected from the rest of the organisation and the outside world to avoid leaking information to competitors. This work is visible to the stakeholders and its progress is quite often tracked very closely.
You tend to trivialise complexity of the work that someone is doing as they brushed off the complexity saying - it is just a one-off request. This lack of clarity makes you wonder why the priority work is taking longer than expected.
You fail to recognise the accomplishment of the person(s) who just completed this work
You are unable to foresee any dependencies on (up/down)stream teams, which you could have unblocked for your team to make progress
You are unable to communicate progress on this invisible work because you didn’t know it was being worked on in the first place
Ever experienced any of that?
I have had an instance where there was an incident or rather difficulty that my team caused by changing the version of a core library that forced users to go update dependencies on their underlying modules as they were now migrating to our platform. I don’t want to go into the details as I would have to explain everything about my project. But I guess that gives you a gist of the problem.
The worst part, as an engineering manager, I didn’t even know this happened, until my manager got wind of the issue as feedback from the head of engineering of the team that was affected. I was lost for words! I didn’t know my team was working to help them with this! No sign of this work on our beloved JIRA board!
What are the downsides of this - as a team member?#
You cannot understand how long something has been in progress
every standup - you keep repeating - it is almost done
When the said work is completed, nobody knows that you worked so hard to finish it. Leading to lack of recognition
Your team members do not know that you could have benefited from their help
The story of taming invisible work - inspired by true events#
There was a small insurance managing agency that had an even smaller IT department. It comprised of 8 developers or less, some application support staff, the CTO, a business analyst and a couple of scrum masters. They thought they embraced agile and were proud of it. They knew IT was going to be core for the future of the organisation so hiring was in full swing.
There was no particular team topology.
Every team owned every application in the organisation. Teams were delivery machines. But team topology is not the focus of this story. So ignore this part.
The IT department in this organisation was serving several different departments:
finance
underwriting
claims
marketing
the Chief Innovation Officer’s next big idea
It might sound like a small list but trust me there were a lot of asks from everywhere. But no one could see these or know the priorities of them.
No platform/tool where customers could be on top of their feature requests. All the stakeholders generally spoke to the honorable Business Analyst
BA would give a rough estimate of the feature and ETA to the customer prior to consulting with the team. This was gold - the team would have estimated this work very differently
BA vaguely knows what is currently being worked on. Gets to attend the sprint reviews.
We overestimate the power of human brain here - small company, not too many asks of IT, this will do… until it doesn’t
When passing by on the floor or on an instant messaging program, the business analyst would tell the scrum masters that there was this work to be delivered which should nwo be done by this new date!
Teams were already working on an existing commitment - previous feature, now interrupted by this surprise priority
Scrum masters and teams have to discuss how to cater to the new feature request, sometimes mid sprint, sometimes on the first day of the sprint. This made planning extremely painful
The business analyst always looked at velocity of one team regardless of the size of the team and compared it with another with the logic that “if 5 people can deliver 30 points, then 2 must be able to deliver at least 5 points”
These artificial deadlines forced teams to cut corners so that they could deliver on time
It is not a surprise that too many shortcuts used in solutions would result in code quality that would be trash.
Technical debt went high - making it much harder to make further changes. Teams are starting to wondering how this was agile.
Developers were getting increasingly frustrated with the deadlines that were set. They saw a total neglect to quality as a lack of craftsmanship. The lack of ownership fuelled the increase in technical debt as solutions were often implemented as a stop-gap mechanism with the excuse “we’ll fix it for now. let someone else clean this up later”.
The scrum masters lost their patience. As usual, during one of their weekly pub hangouts they decided, they had to do something to prevent losing engineers. The decided it is worth speaking to this business analyst and getting a dump of all the work that we are supposed to do in a backlog somewhere everyone could see.
This was pre-covid times. Meetings in pubs were normal.
As they were scrum masters, they decided to call a meeting with the business analyst who for reasons unknown was also called a product owner - only that was no product to be owned. The scrum masters asked the BA to work together and produce a visual representation of all the work to be done. Started with a bunch of post its on a board. Ended up covering an entire wall.
As much as they were relieved of being able to see the work that was promised on the wall, they were equally scared and excited.
They realised we need to change to expect better results.
Finding a team to be the guinea pig was not too difficult. There was already an application that was pretty popular and had a team of engineers who had a pretty decent tenure at the organisation and knew the context and codebase pretty well.
This was the beginning of the experiment. A new product owner was hired for the team as the team already had a scrum master.
The large backlog of work on the board, was then refined to extract work related to this application and put into the team’s backlog.
But wait, the team needs to relearn scrum. The department decided to create a sprint 0 for the team to train on scrum and come up to speed with iterative delivery and the agile manifesto and things.
If the scrum masters and the business analyst had not put the all the work that had been committed on a wall, nobody would have known how much there was to do. Nobody would have known in what order, work should have been done!
A simple exercise of publishing the work from the Business Analyst’s head to a bunch of sticky-notes helped them all understand:
The size of the challenge ahead of them
It gave them the vision that they had to hire
They had to take immediate action
The fact that maybe some of the scope must be renegotiated
This is why visualising work is extremely important. This triggered the change that was to follow.
