Earlier quoted context omitted.
...for anyone who already knows that waterfall isn't iterative
Can I start a waterfall every two weeks?
Sure, but if they're on the same project it might be called something else.
You don't need Scrum, you just need to do Kanban right (2022)
231–240 of 341 posts
Re: You don't need Scrum, you just need to do Kanban right (2022)
#232Earlier quoted context omitted.
I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. The sad truth is that most management teams would prefer their e…
I don't see retrospectives being that much of a time-sink, it's a 30min/1hr meeting every 2 weeks. Even when I was on a kanban team they still had a fortnightly retrospective, it's useful to have a checkup occasionally.
Every time someone hates Scrum they always complain about 2 week sprints, which are an insane choice (should be 4 weeks), that shows they aren't doing Scrum, they are micromanaging with "Scrum" as the excuse.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#233Earlier quoted context omitted.
Yes, predictability is better for business, but business also needs to accept that there are limits to the amount of predictability you can achieve in software development, and trying to force too much process is only going to predictably increase delivery time. In my experience, working with high level estimates which you keep updating from time to time is the best compromise.
There's no limit to predictability achievable in software development per se. You can have perfectly predictable software development -- if you know exactly what it is you're going to build. The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and t…
The only way to increase predictability is to pad estimates to the point of meaningless, and management won't accept that. Predictability creates crunch that creates bad choices that waste time and push delivery of working product out further.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#234Earlier quoted context omitted.
Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all. -"It is impossible to do accurate estimates" -"You will get better at it" I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". Do anyone else share this experience?
Estimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?
Constructions remains a terrible analogy for software development, as it always has been.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#235Earlier quoted context omitted.
nah it's all good. it's just the "estimation value" which is technically arbitrary, but a common practice is in a 2-week sprint, 1x eng 1x sprint is ~5 points. By saying 8pts the team is effectively saying it's probably a 2 sprint job and individual tickets are not supposed to be 2 sprints long meaning there's complexity that either needs to be broken apart or on the rarer case, team agrees the ticket is fine as-is t…
Is that common? I thought it varied depending on the team, but usually that 1 pt is the shortest meaningful piece of work. Where I work now, 5 pt is not especially much. We have total story points delivered in a sprint around 120.
You didn't say how long a sprint is nor how large your team is, which makes me suspect that you don't handle measurements well in general.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#236Earlier quoted context omitted.
The main point of points is that they are not supposed to be equivalent to x amount of time. They're supposed to represent a measure of complexity. How much time that then takes depends on who does the work, the order in which tickets are implemented, how much distraction there is, luck (do you encounter any unforeseen problems), and so on. They're then used to see how many issues will fit in a sprint, which is a mea…
That’s the theory but it doesn’t help managers so they still convert it back to time somehow.
Scrum was never for managers. If a manager is involved in predictions, it's not scrum.
Scrum is about delivering the best you can each month, with client/management setting priorities and then appreciating what they get, instead of trying to steer the car from the boot.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#237Earlier quoted context omitted.
No idea what you mean with outcomes vs means/tasks. Just put outcomes as cards in your Kanban board, they don’t have to be tasks.
I think they mean it from a softer perspective - Scrum encourages more time ensuring all the team and tasks are clearly directed towards an outcome for that sprint. Just putting outcomes as cards on a kanban board will not have that same effect in all instances, as it's more about the soft points of engagement and teamwork driving towards that common goal.
Thank you for your answer. Actually it’s perfectly doable, just put an outcome swimlane in your kanban, with a rule that says there can only be one card in the « doing » column.
I’m starting to realize that most people don’t know how customizable Kanban is. You can put as many columns and swimlanes as you want, and then implement constraints in the system with rules around how cards move on the board.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#238Earlier quoted context omitted.
I also don't fully understand what "doing Kanban" means - like you, I see Kanban as a type of board rather than a method of going through said board (maybe because of a lack of understanding of process & an over-indulgence in Trello's marketing). That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thi…
> in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint That's not Scrum then. You don't add stuff mid-sprint, that's the whole point. Unless the world is literally on fire, you don't touch the sprint content. What's your scrum master doing when you get stuff added? It's their job to prevent it. And if work overflows, you need to spend time grooming the tasks to manageable…
That's not a rule in Scrum that I'm aware of. It's an aspiration for sure since an injection implies some sort of emergency or unanticipated work. Ideally you avoid those sort of things. But if they happen it's not an issue to inject something. Constantly doing so usually means something has broken down in planning and/or quality is so bad the team is going from fire to fire.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#239Earlier quoted context omitted.
As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers. Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at…
Franky, scrum teams I worked in were pretty much worst in all the points you list, except higher management feeling of control. Especially in alignment between developers point. The cooperation is never really good in scrum, it is sorta kinda passable at best. Interpersonal relationship are either horrible or passive to non existence. > Unfortunately developers are rarely extroverts, and they often don't have the ski…
> I mean, what are you exactly talking about here? Because developers do criticise each other all the time, both in code review and outside of it. If they have trust, they talk plenty. If you do not see developers communicating, it is because of how you lead a process.
It's not just communication which is needed. It's effective communication. For example, criticism without structure and consideration comes across as unkind and destructive. This is the piece which I rarely see working well without a framework. It doesn't have to be scrum. I just see scrum solving this and many other problems really well.
> Scrum is so inflexible, that it literally prevents accommodations for issues like this. And that is not even speaking about the fact literally this should be job of people management. This is literally what leaderships should do, because they have actual power to change the things.
Scrum doesn't have to be inflexible. It should be tailored to the needs of the team. The catch is that changes should be agreed by all, rather than one member going rogue. "Rockstars" hate scrum.
As for the "job of people management," if you're punting the responsibility of collaborative team dynamic to your leaders, be prepared for them to lead you. With scrum.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#240Earlier quoted context omitted.
See that's the main problem with strict scrum. Why can't you add things to the sprint mid sprint? Sometimes things come up that you didn't think of. There's really no point being that strict. I think two week meetings/sprints are good for keeping focus and as an opportunity to agree short term priorities. But the point is to get work done, not to precisely obey scrum rules.
Depends on what the "you" is here. If the "you" is the team, go ahead. Add anything you want, as long as you deliver what you promised in the beginning of the sprint. If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No.". Then they can start discussing if it is so urgent and important that it can't wait 1-10 business days…
> If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No.
I hate working with people like this. So unhelpful.