I completely second this! And I would like to extend the view from an Agile angle:
In Scrum, the Daily Standup is to inspect and adapt to reach the Sprint goal. We always do a "Walk the board", where the complete team focus on what do we need to do, to get an item to progress towards done. Which is a discussion using the swarm intelligence.
When only focusing on the (outdated) three questions (What have you done yesterday, what do you plan to do today and do you have any impediments), that not only feels like a status meeting, but also ignores the goal and collaboration.
I work with lots of companies that have different variations. I have to agree my favourite daily/standup is a walk the board style.
Often it's the retro where I spend a lot of time trying to encourage the team to do it "properly". I've had one that just wanted to do kumbaya sessions where they pat each other on the back for the last sprint. It feels great, but it's not what the retrospective was designed to work toward -- continuous improvement (Kaizen).
Just as a sidenote, because I was using Spectacle as well. JFYI: As it is no longer maintained, I switched to Rectangle (https://github.com/rxhanson/Rectangle) and can highly recommend it.
Yeah, I'm just putting off switching because Spectacle still works, and has never broken or even behaved in a way that seemed weird or less than ideal, even across multiple monitors, with changing screen situations (hiding/un-hiding the dock), et c. It is one of the very few pieces of software I run that has given me precisely zero problems of any kind. Ain't broke, don't fix it, and all that.
Not sure why you were down-voted, but this is a good point. In fact, it is the base problem of all software methodologies. Planning depends on knowing how long an activity will take. Estimating is most reliable when you are estimating something you've already done before. Unless you're working in just such a low-novelty environment, your results will not be predictable and you should understand that the backlog is a priority-ordered list and velocity will let you give a "forecast".
Kanban doesn't "fix" this -- it just changes the frame through which deadline-buzzards get to look at it.
I would say, if you absolutely need an estimate on how long a project will take (and often you don't), do a proper study on it, don't just pull a number out of your a*. Software project estimation is doable, but it takes some effort. It (IMHO) cannot be replaced by a clairvoyance seance, AKA planning poker.
I’ve said this previously but I don’t agree that software estimating is possible in theory. It’s a form of the halting problem. You can’t, even in theory, know how long something will take until you do it.
It’s certainly possible to estimate to a rough-order-of-magnitude but the problem is that the ROM quickly becomes a target, and then a commitment.
I have a couple of positions that I take.
First, the old adage still applies: “better, faster, cheaper - choose two”. If you set a deadline then you have to be willing to drop features or quality, because Brooks already demonstrated you can’t add resources after you start.
Second, if you do need to set a deadline then prioritise it, stick to it and celebrate it. Too many times deadlines are used as a whip, and my or my team have wiped themselves out to meet it, only to be told it wasn’t really needed. This is insanely demoralising and strongly affects productivity in the long term.
My personal (and unpopular) preference is to prioritise completion of stand-alone features rather than building to deadlines, which means you can release a product at almost any time with fewer, but better quality features. This approach has a demonstrable positive impact on the ROI but because it’s more complex and provides less short term certainty, it’s frowned upon.
I think in pure compsci theory you might be right, but in practice (industrial SW production), we usually limit ourselves to algorithmic solutions that do not involve halting problem, so estimation is possible. For example, an upper limit for a rewrite of a system is how long it took to create the original system (provided you understand the tradeoffs and issues of the original architecture).
I don’t understand. The halting problem says you can’t tell if an algorithm halts without running it - you can’t be sure any program will run to completion in a specific time. It applies to any non trivial program.
And it’s well established that a rewrite is dangerous. The second system effect suggests that rewrites will always take much longer.
My point was that OS dispatchers don't spend time working out how long things will take to compute, to allocate resources (such as CPU time) properly into the future; what they do instead is they just put the stuff to compute into a dispatch queue and go from there. Then if it's a novel thing or million times repeated thing doesn't really matter.
BTW, one indication that Scrum is bad is that nobody is doing its analogue (syncing everybody once a day?) in computing. Sane project management practices should be universal, and should also work for operating system schedulers.
Kanban was originally designed for production lines in car factories, so it works. If you go to any McDonalds and look at the screens in the back you'll see orders represented a lot like tickets.
In Agile, "points" are just an abstraction around work to try to normalize it in the same way that every burger+fries combo should be roughly equivalent.
I prefer to use a different company for my domains, as for other services--like Mail, Web, Hosting. Therefore, if something happens to one, it doesn't affect my other services.
As you mentioned, you are from Germany. I can highly recommend https://INWX.de —I use them myself, and for hosting, I use Hetzner as well.
Thanks a lot. Signed up a few minutes ago on https://INWX.de and quite like what I see so far. It's nice that they are specialized in domains. For Hetzner it's just another service.
reply