
Tracking where your time went with Lego workstream visualisation - touristtam
https://code.joejag.com/2018/lego-workstream-visualisation.html
======
jaymzcampbell
I really like this. For certain industries & situations, you really do need a
visual way to represent where your time is going. I've found this to be an
area lots of developers seem openly hostile too. I used to do something
similar with post-it notes segmented into quarters. This was at an agency
where we were working on fixed price/deadline projects.

Another commenter here asked if a digital version would be as good. From my
own experience, when we digitized the post-it notes it just became another
reporting/time tracking setup. The physical aspect of it made it very obvious
to the project/product managers as they were stuck up in on a whiteboard in
the middle of the office. When things started spilling off the edge and all
the way over the wall [1] then it was pretty obvious something was up :) We
also used the placing of them to kick off standup in the morning.

It was important to remind ourselves/higher-ups that the tracking wasn't meant
to be very detailed/accurate but instead indicative and a springboard to guide
the weeks planning conversations. To that end, I think it was very effective.

[1] [https://i.imgur.com/1PdBiX7.jpg](https://i.imgur.com/1PdBiX7.jpg)

~~~
Karunamon
Developers seem hostile to it because these kinds of metrics are universally
used against them. As long as the goals are being met, this amounts to
pointless micromanagement. If it’s a developer doing this for themselves,
that’s something else entirely.

~~~
oligopoly
Usually those problems stay in the background while not working on the clock
and your subconscious comes up with solutions.

------
oneeyedpigeon
It begs the question: would a digital equivalent work just as well? What does
the physical version bring - 3d? If this helps to visualise the data, are
there decent tools for collaborative 3d graph editing that include the ability
to move the camera, etc.?

The article says:

"Next up we tried an Excel document, but no one looks forward to tracking
their time in an Excel document. We wanted something visual and tactile.
Something that would cause conversations to happen and be fun to use."

which I totally take on board, but the lego equivalent, however fun it might
be, just might not always be practical. Essentially, I'm thinking is there an
equivalent that's less like Excel and more like Minecraft ;-)

~~~
ccozan
What if, instead of normal Lego bricks, someone designs a "smart" brick and a
"smart" Lego Board, so that while you add bricks of different colors, and put
on different columns, it creates a digital twin on a server, that is nicely
displayed on a dashboard of your choice?

Same fun, right?

~~~
icebraining
Sounds like a good project for
[https://dynamicland.org/](https://dynamicland.org/)

------
codemac
Reminds me of the Printable CEO stuff by Dave Seah:

[https://davidseah.com/2005/11/the-printable-ceo-
series/](https://davidseah.com/2005/11/the-printable-ceo-series/)

Can't recommend this stuff enough, and it's buffet style - take what you like.

------
esseti
Out of curisoity, let's say that someone come up with a new request, that is
listed as ad-hoc. how long does it take before it becomse a "planned" work?
what's the distinguish between the two?

As far as I understood you are a dev, so everyhting that is not related with
the development of your software is considered as ad-hoc?

~~~
nulagrithom
I consider it ad-hoc when the request escapes the planning phase and goes
directly in to my pile of work as top/near top priority.

A little bit of this is understandable. You can't wait for _every_ task to get
put in to the backlog and planned out in sprints or whatever. But if you've
ever had a week where 90% of your time goes to everything but planned work
well... it's really frustrating.

There's often a high cost to context switching for developers. There's been
some loose "studies" done that confirm this, and I definitely feel it at a
personal level. A "quick request" isn't just the half hour it takes me to do
the thing. It's the language switch, the environment switch, forgetting what I
was in the middle of, etc, that really causes the bulk of my productivity
loss.

It gets to the point sometimes where I give two time estimates: one where I'm
allowed to shut my door and work, and one where I factor in the likely torrent
of interruptions that will more than double my actual completion time.

------
rb808
BTW Lego sells individual bricks which I'm finding is much better than all
those kits.

[https://shop.lego.com/en-US/Pick-a-Brick](https://shop.lego.com/en-US/Pick-a-
Brick)

You can search for pieces eg BRICK 2x4, which are 21c each.

Also ebay has loads of used lego pieces which are super cheap.

~~~
andrepd
You can try bricklink too: www.bricklink.com

------
oeuviz
Great idea, just still looking for a brick color for 'stacking lego bricks as
a distraction'?

~~~
Freak_NL
Possibly transparent 4×2×1 bricks for time spent doing bugger all (or just
taking a longer break after some taxing task or stressful situation).

I think Lego Friends may have some suitable bricks for the usual Friday
afternoon (down)time spent with colleagues watching someone launch an electric
car into orbit or some other definitely not work-related activity. :)

~~~
walshemj
You mean like programming a pi to run a robotic arm to stak the bricks :-)

~~~
Freak_NL
Exactly! That, and actually ordering the bricks on Bricklink and implementing
Lego workstream visualization for your dev-team. :)

------
detritus
In a similar vein, but with a bit of complexity in the background...
[http://specialprojects.studio/project/bit-
planner/](http://specialprojects.studio/project/bit-planner/)

"Bit Planner is a physical and digital time planner made out of lego bricks
that magically synchronises with any cloud based calendar to help you better
organise your projects and get more out of every day."

------
gd2
I like the physical simplicity of one hour equals a colored block. I've got
minor quibbles so will modify it, but good idea.

------
WhiteOwlLion
dork

------
matte_black
If you could set up this system with a series of internet connected scales for
each category, you can take the weight of the bricks from different work areas
around the company and know in real time what people are doing while
simultaneously recording the information in physical lego form.

~~~
karlmdavis
You forgot the <sarcasm/> tags, I think (I hope).

~~~
matte_black
Not really. You could skip legos all together and have 3D printers that print
out layers of work over time as well, no need to measure weight then as you
track it through an API.

------
bitwize
You're not really doing Agile until you're meticulously tracking each hour
spent. If this sort of thing helps, so be it. But those hours have to get into
JIRA _somehow_.

~~~
sillyquiet
Are you being sarcastic? I ask because Agile methodology, when done correctly
as a bi-directional contract between team and stakeholders, does not have to
be like that at all.

~~~
bitwize
At any organization whose business model has evolved beyond "burn through
investors' money, ask investors for more money", management NEEDS to have
meaningful answers to these questions:

* What remains to be done?

* How much will it cost?

* How long will it take?

* Is the team on track or falling behind?

Forget contracts. Answers to these questions are non-negotiable for the team.
Because the PM or engineering manager will be held accountable for those
answers by the executives.

The best way to provide those answers is to adopt a _data-driven_ approach.
You have stories in the backlog. At the start of each sprint, the developer(s)
to whom the stories are assigned break the story down into tasks and assign an
estimate IN HOURS to each task. As the tasks are completed throughout the
sprint, each developer logs how many hours they spent on that task, preferably
daily.

This amplifies the benefits of Agile because the manager doesn't have to
guess, they can look at the burndown chart and _see_ \-- are the developers
meeting their estimates? If not, by how much are they missing? Are they taking
on an appropriate amount of work each sprint? Should they do less? More? Who
is doing well and who is struggling? Then, decisions can be made with respect
to who should do how much work on what, with _rapid_ turnaround time.

"If it can't be measured, it can't be managed." This is _fundamental_ to
management, and has been a maxim in software management even during the
Waterfall days. What Agile gets you is shortened feedback cycles and more
rapid turnaround.

~~~
ryanbrunner
Your system makes two assumptions that have been thoroughly, repeatedly proven
wrong:

\- It's possible to know what tasks are required to complete a project at the
outset of a project.

\- It's possible to estimate how long those tasks will take to complete.

Any team I've ever seen who claims to do well with both of the above points
either had massive sandbagging problems, sometimes openly acknowledged by
everyone, and often failed to deliver the best solution they could due to the
rigidity of their project plan and the political consequences of straying from
it.

Furthermore, "if it can't be measured, it can't be managed" is true to a
degree, but over-reliance on metrics can result in tunnel vision towards those
metrics, resulting in accumulation of technical debt, quality issues, less
team cohesion and a host of other problems as your teams myopically focus on
hitting their numbers above all else.

~~~
bitwize
> Your system makes two assumptions that have been thoroughly, repeatedly
> proven wrong:

> \- It's possible to know what tasks are required to complete a project at
> the outset of a project.

Contrariwise, if you can't know what tasks are required to complete a sprint,
your team is in deep shit. You can get a decent picture over a time horizon of
1-3 months, with certainty going down as the time horizon gets farther out.
This is why Agile works.

> \- It's possible to estimate how long those tasks will take to complete.

This is part of why you need to capture estimates and actuals. Even if those
estimates are wrong, in practice, by comparing estimates to actuals by each
developer, a picture will emerge of how far that developer will overshoot or
undershoot their own estimates. Those estimates the become actionable data,
even if they're wrong 100% of the time.

~~~
ryanbrunner
> Contrariwise, if you can't know what tasks are required to complete a
> sprint, your team is in deep shit. You can get a decent picture over a time
> horizon of 1-3 months, with certainty going down as the time horizon gets
> farther out. This is why Agile works.

Fair enough on the level of a sprint. In my experience, management and
stakeholders rarely care about a sprint, they care about the project as a
whole. And again, in my experience, the accuracy of estimates falls off
precipitously once you get beyond 1 or 2 sprints, unless you're willing to pad
estimates or lock down your plans to a degree that will hurt the success of
your project (by not taking into account learnings as you build).

> This is part of why you need to capture estimates and actuals. Even if those
> estimates are wrong, in practice, by comparing estimates to actuals by each
> developer, a picture will emerge of how far that developer will overshoot or
> undershoot their own estimates. Those estimates the become actionable data,
> even if they're wrong 100% of the time.

This would be true if estimates had high precision, but low accuracy (i.e.
developer A consistently overestimates, and developer B consistently
underestimates). In my experience, the opposite is more true than not -
developers have relatively well tuned accuracy, but horrible precision. If
everything goes according to plan, developers can estimate that fairly well.
It's the amount of times things don't go according to plan that's the problem.

