3 ms·

Well, I see the point of a senior: with enough practice you should not need rituals of this kind anymore. Some seniors don't even need a kanban board on a fast

Well, I see the point of a senior: with enough practice you should not need rituals of this kind anymore. Some seniors don't even need a kanban board on a fast moving project, they just know what needs to be done now to create value at lowest cost, they just feel it. It's not like when you're junior, you've never done any standup and you don't know when you've been blocked long enough to switch task or ask for support, you've never done any poker planning if you're techie, or value estimations if you're product / sales, you've never prioritized by complexity / value score if you're manager - or equivalent. For this reason, I think there's still value in such rituals when there are non seniors in a team. However, I prefer text-chat based standups myself and feel like they produce the same value and cost less time.

rusk 7y ago
Very interesting point. When you have senior guys that know the important things work then the importance of process, beyond some key staging points, diminishes. From a business and strategic planning perspective could this be some kind of a risk? There's the old "hit by a bus" (or just quits) trope of course, which is related to the "single point of failure" systems analogy. Then there's the management ideology of control, which can be subverted when individuals are on the critical path for projects. I also wonder how this jives with change management: If you have guys mired in the details around whom changes pivot, what happens when there's significant changes e.g. in personal life of these guys, or organisationally, or migrations to new architectures etc. I also wonder how putting individuals at the centre of a business jives with external compliance requirements such as ISO and GDPR ... EDIT also recalling personal experience: What about growth, where you want to grow the business and bring new (senior or otherwise) team members in, but everything is vested in the idiosyncracies of a few individuals?
- 1337shadow 7y ago
  I agree that processes are going to be necessary to scale. My comment focused more on the conditions that seemed to make the article relevant: a small team making a new project that's not really in production (fast moving) and apparently with only seniors who don't need even a voice-based standup ritual.
  - rusk 7y ago
    sorry, this is one of those instances where I should have read the fine article before posting
matthewmacleod 7y ago
Some seniors don't even need a kanban board on a fast moving project, they just know what needs to be done now to create value at lowest cost, they just feel it. These are always the worst people to work with, because they think they know much more than they do. Frankly the most difficult parts of effective engineering are nothing to do with software and all to do with good team communications.
- 1337shadow 7y ago
  I'm sure sure we're talking about the same things: not communicating daily is obviously going to be a problem, such as not giving the team a chance to change your priorities. But a senior knows basic needs for a product to live on like stable production, continuous integrations, unit/functional tests, code reviews, continuous deployment, infra & application monitoring, alerting, backups, service & dependency versions upgrades, fix regressions introduced by new features, with test ... and all sorts of quick wins for the product that come out of a casual discussion with a product / sales person etc ... The kind of usual things that becomes a daily routine and may just take the day to the point where you couldn't move any new feature card in the kanban anyway. Is it necessary to create a kanban ticket every time they do a package update, fix an impediment or do something in 0day ? It can surely be useful, not sure if it's more useful than just reporting on a text based chat, can it be harmful by polluting the kanban with tickets that don't create any obvious value (tech debt treatment) ? as long as communication goes through it's fine with me unless someone wants to build a report at the end of the month (ie. billing), I believe the practice matters more than the tool. But I'm more trying to understand the point of this article, searching for conditions that would validate it, rather than defend it in all case. For me daily communication and the three questions are important (but I prefer async / text based, and even twice a day: when I check-in and check-out), for the rest it depends, I can understand why some seniors would feel like blindly applying procedures may seem un-necessary or harmful sometimes, like they say : it's the dose that makes a cure or a poison.
olodus 7y ago
Was just about to comment on this myself. As one of two new devs on a team I am very glad that the seniors of our team has chosen to start having standups again (which they didn't before). It is great for us new guys to get a quick look in at what everyone is working on and they get a natural way of seeing if we are a bit stuck with our "new guys tasks". But I can also very much see us abandoning it once we are more up to speed with the others. Or maybe we just keep them extreamly short as I've seen some other suggest here.

rusk 7y ago

Very interesting point. When you have senior guys that know the important things work then the importance of process, beyond some key staging points, diminishes. From a business and strategic planning perspective could this be some kind of a risk? There's the old "hit by a bus" (or just quits) trope of course, which is related to the "single point of failure" systems analogy. Then there's the management ideology of control, which can be subverted when individuals are on the critical path for projects. I also wonder how this jives with change management: If you have guys mired in the details around whom changes pivot, what happens when there's significant changes e.g. in personal life of these guys, or organisationally, or migrations to new architectures etc. I also wonder how putting individuals at the centre of a business jives with external compliance requirements such as ISO and GDPR ... EDIT also recalling personal experience: What about growth, where you want to grow the business and bring new (senior or otherwise) team members in, but everything is vested in the idiosyncracies of a few individuals?

1337shadow 7y ago
I agree that processes are going to be necessary to scale. My comment focused more on the conditions that seemed to make the article relevant: a small team making a new project that's not really in production (fast moving) and apparently with only seniors who don't need even a voice-based standup ritual.
- rusk 7y ago
  sorry, this is one of those instances where I should have read the fine article before posting

matthewmacleod 7y ago

Some seniors don't even need a kanban board on a fast moving project, they just know what needs to be done now to create value at lowest cost, they just feel it. These are always the worst people to work with, because they think they know much more than they do. Frankly the most difficult parts of effective engineering are nothing to do with software and all to do with good team communications.

1337shadow 7y ago
I'm sure sure we're talking about the same things: not communicating daily is obviously going to be a problem, such as not giving the team a chance to change your priorities. But a senior knows basic needs for a product to live on like stable production, continuous integrations, unit/functional tests, code reviews, continuous deployment, infra & application monitoring, alerting, backups, service & dependency versions upgrades, fix regressions introduced by new features, with test ... and all sorts of quick wins for the product that come out of a casual discussion with a product / sales person etc ... The kind of usual things that becomes a daily routine and may just take the day to the point where you couldn't move any new feature card in the kanban anyway. Is it necessary to create a kanban ticket every time they do a package update, fix an impediment or do something in 0day ? It can surely be useful, not sure if it's more useful than just reporting on a text based chat, can it be harmful by polluting the kanban with tickets that don't create any obvious value (tech debt treatment) ? as long as communication goes through it's fine with me unless someone wants to build a report at the end of the month (ie. billing), I believe the practice matters more than the tool. But I'm more trying to understand the point of this article, searching for conditions that would validate it, rather than defend it in all case. For me daily communication and the three questions are important (but I prefer async / text based, and even twice a day: when I check-in and check-out), for the rest it depends, I can understand why some seniors would feel like blindly applying procedures may seem un-necessary or harmful sometimes, like they say : it's the dose that makes a cure or a poison.

olodus 7y ago

Was just about to comment on this myself. As one of two new devs on a team I am very glad that the seniors of our team has chosen to start having standups again (which they didn't before). It is great for us new guys to get a quick look in at what everyone is working on and they get a natural way of seeing if we are a bit stuck with our "new guys tasks". But I can also very much see us abandoning it once we are more up to speed with the others. Or maybe we just keep them extreamly short as I've seen some other suggest here.