231–240 of 298 posts
Earlier quoted context omitted.
If no one will read it, then maybe it's not important, so you don't need the meeting either? ;-)
If I don't go to gym, does that mean exercise is not important? Some things are not very enjoyable, but still necessary.
Standups are one of these in my honest opionion.
One comment - the article mentions that Waterfall was basically the only approach used prior to agile. This is false. In some industries waterfall was used, but in others software was designed and driven incrementally just as with core agile. The work I did in fixed income brokerages in the early 90s was largely ad hoc agile.
That's my experience also. Since the early 80's, every project I've been involved in was managed with a semi-flexible, pragmatic approach that involved breaking down the problem into smaller chunks, regular communication with the customer, etc.
Earlier quoted context omitted.
The far biggest time sink is not what you logged though, but how you need to pad estimates and delay work to please the Scrum Lords. Like, the burndown chart has to be nice and steadely go to zero. There is no way to do that without decoupling reported hours and estimated hours from actual hours. Or points. It doesn't matter which.
"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course. Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity. Then... "that's too many files in a PR! break it up! no one can r…
This realy grinds my gears. I had a recent experience with a scrum master (technically a delivery lead but in practice a scrum master). Really nice guy, smart, easy going. We had many discussions about the value of estimates, and the whole "it's complexity, not time" trope would come up. So I asked what the estimates were used for. Turns out they're used to forecast cadence / velocity. Of course, knowing that we were going to be asked why a small story was taking two weeks to complete, we'd start sizing based on time. After all, we're humans, biased and flawed.
Now you tell me, how do you want a measure of complexity to be a predictor for cadence when these 2 things are at best orthogonal?
Earlier quoted context omitted.
Just by switching from Scrum to Kanban one can improve progress a lot. For being two very similar pull based systems the difference in effectiveness is just incredible.
Agreed. We use Kanban and are very happy. We used to not do any estimates but have voices from others asking for them to do better planning of marketing and sales activities. I understand where they are coming from but so far it's mostly guessing So: Do you do estimation in Kanban and if so, how?
If sales and marketing need to do planning, then they need to tell what they want to push back to the backlog so that the feature they want are on time.
I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…
"people had fewer than 3-4 hours per day to actually work" had the same experience. the unwritten expectation was to pull 8 hour coding days /plus/ all the Scrum overhead. if you don't like it, there's 1000 guys waiting to take your place, partly thanks to remote. a core reason we haven't fire you yet is that it is costly to ramp up new people, but don't try our patience. see also "hire fast fire faster"
Same. Even worse, spread out in between meetings. Some days I'd have barely started understanding the work to be done and it was time for the next meeting. Rinse and repeat for each "non-meeting" slot throughout the day and the whole day is a write-off.
Earlier quoted context omitted.
Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.
Kanban came from elsewhere. The word comes from post-war Japanese car factories, but the principle is older. Kanban boards were physical boards, with tokens representing various machines' or workers' availability, and the presence of things to work on. It's more a work-scheduling mechanism for known, understandable, repeatable work. https://en.wikipedia.org/wiki/Kanban
I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…
> everyone meeting This is one of the things I've added to me repertoire when I interview with teams: I always ask how often they meet and how they structure their meetings. Big red flag is there is a daily all hands (yes, I've seen this in a 16 person startup) I think it's emblematic of a few things about the founder/cofounder/lead: 1) they are an egomaniac and just needs to see everyone reporting in, 2) they don't…
I once mysteriously turned into "not a culture fit" after several rounds of interviews with excellent feedback up to that point and I'm fairly sure asking a couple of similar routine questions about their dev process was what got me tagged with that label. I do consider that one a bullet dodged - if your process is so bad that you're worried about a candidate asking about it or you think they're being awkward for doing so then that says everything really - and I still ask similar questions of anyone I might work directly with/for today. But if there's a place you really want to work it's worth keeping in mind that some people apparently get rubbed the wrong way by this kind of question.
Earlier quoted context omitted.
Agreed, Scrum is a death march. Kanban is the way.
Yeah, you are doing it wrong if scrum is deadlines. I've worked with people who had to pull all nighters to get all sprint content done before the sprint closes. I'm using it more as a window to do some cheap analysis on our progress.
Earlier quoted context omitted.
If I don't go to gym, does that mean exercise is not important? Some things are not very enjoyable, but still necessary.
We know scientifically that exercise is important. I highly doubt the same level of evidence exists for the importance of these short meetings. Also, if your boss tells you to read the emails, and you don't, then you can get fired. You can't get fired from your job for not exercising. If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.
The boss has no easy way to tell if you read the emails or not. The consequences of lack of information are often hidden / long term.
In many countries, it's pretty much impossible to fire employees for forgetting to read an email.
> If you can ignore the emails and not get fired, that's proof in itself that the emails are not important, at least not to your boss.
I'll try a proof in a similar style - if Scrum was so wildly inefficient, the companies practicing it would be a long time out of business since companies with no meetings would easily outcompete them by offering better products/services for lower costs. Yet Scrum (or similar methodologies) are used in many successful companies all over the world, that's a proof that Scrum works.
How do you like them now, these oversimplistic "proofs"?
Earlier quoted context omitted.
Agreed. We use Kanban and are very happy. We used to not do any estimates but have voices from others asking for them to do better planning of marketing and sales activities. I understand where they are coming from but so far it's mostly guessing So: Do you do estimation in Kanban and if so, how?
You don’t do estimation without prioritization. As a consultant, my default way of working is kanban, often setup on Trello. Once I deconstructed the project into features, the first thing I do with the client is arrange them by priority and arrange them into sets for releases. If sales and marketing need to do planning, then they need to tell what they want to push back to the backlog so that the feature they want a…