Tracking where your time went with Lego workstream visualisation
code.joejag.com
code.joejag.com
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.
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 ;-)
Same fun, right?
its a lego calendar synced to a digital calendar
https://davidseah.com/2005/11/the-printable-ceo-series/
Can't recommend this stuff enough, and it's buffet style - take what you like.
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?
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.
"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."
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.
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."
* 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.
- 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.
> - 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.
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.
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.