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.
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.
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 ;-)
The physical version brings a level of ritual/ceremony that I suspect is helpful. It's the discussion and change out of the digital into physical that's more value than the colorful output I suspect.
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?
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?
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.
nulagrithom's answer was really good and true but here's maybe a simpler way to put it:
"planned work" is really "prioritized and agreed to" work.
"ad-hoc" work is just the urgent priority of (usually) one person.
After years of dealing with the conflict, I've found the easiest answer is always "I'd be happy to give you what you need. Which of these planned tasks from you (or your boss) are you willing to sacrifice or postpone for your urgent task?" 80% of the time that's enough. If not, you walk them over to their boss and ask them the same question. Then, you can go back to your desk and work and let them hash it out or hash it out with your boss to convert this "ad-hoc" request into a "agreed to, planned request."
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. :)
"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."
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.
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.
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.
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.
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.
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.
> 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.
At some point though, once you've decided what tasks to work on, how much they cost (in time, dollars, risk, etc.) is a very important question. The answers will always be guesses, but tracking what actually happens over time helps to improve future guesses.
> - It's possible to estimate how long those tasks will take to complete.
One cannot eliminate all uncertainty, but it is possible to decrease it over time. A way to do this that I found works well is to look for past tasks that are sufficiently similar in size and complexity to the one being estimated and use the tracked data to anchor the new guess. You track as you go in order to build this log.
I should emphasize that I think this data should be there to help developers improve their estimating abilities, and not for the management to judge developer performance.
> 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.
Very true. However, never measuring or logging anything out of a desire to avoid the things you've enumerated can deprive a team of valuable information and lead to missed learning opportunities. The trick is to find the right balance.
> 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.
> 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.
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