Earlier quoted context omitted.
Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.
You won't gain that understanding until you actually complete both of those projects. Industries and occupations that manage estimates well do so because bulk of the work is repeatable and predictable, and the people doing that work have done nearly identical kind of work before. There is some variability involved, but there's only so much of it, and it yields to tried and true classical project management techniques…
You don't need Scrum, you just need to do Kanban right (2022)
251–260 of 341 posts
Re: You don't need Scrum, you just need to do Kanban right (2022)
#252I've heard over and over from managers that scrum is better at anticipating delivery dates. Even when the dates are consistently missed. They'd rather slow teams down with process so they can have a date to give their stakeholders, regardless of its accuracy.
You can calculate the team velocity pretty easily in Scrum (amount of story points completed per sprint) and from that you can estimate what gets done in what time. BUT it needs the exact same team to be together on the same codebase. You add or remove people, the velocity changes. You change projects, velocity changes. People also need to be honest when estimating tasks, don't be a 10x cowboy and say something is a…
Raw value here refers to lack of statistical analysis.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#253Earlier quoted context omitted.
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)
#254Earlier quoted context omitted.
> 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…
> 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 does not help with effective communication at all. Its only tools for f…
Sure, scrum is a team tool, not a personal development plan tool. The latter is best handled with one's manager. Note that I am not claiming scrum is an everything tool. It won't solve world hunger either. How on earth does scrum "prevent effective, safe, and compassionate communication"?? It just sounds like you're throwing accusations at the wall now to see what sticks.
It sounds like we've had vastly different experiences. I'm sorry to hear yours have been so unpleasant.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#255Earlier quoted context omitted.
Genuine question: How does Scrum help with less predictable work? From my experience, the opposite is true: New things are discovered during sprints, but at that point it's already too late because that work item has already been estimated in the sprint planning (most of the time incorrectly). Also the arbitrary sprint deadlines don't help either.
When new information exposes issues with the current piece of work in a sprint, you discuss it, and then change whatever part of the plan no longer makes sense given the new information. Will it mess up the numbers? Absolutely, but only for that piece. And as a result of the change of plans being entered into the current sprint (with something perhaps bumped to make room, or maybe the work itself bumped to a later sp…
Re: You don't need Scrum, you just need to do Kanban right (2022)
#256Earlier quoted context omitted.
But velocity of code written is not the same as velocity of value delivered. In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows. That's the whole point of agile, to deliver value rather than code.
The differences I've observed between successful-and-unsuccessful, Scrum-and-Kanban have been dominated by people over process (yes, I know). 1. Does the team have the right people, with the right skill sets, wearing the right hats? (e.g. BAs or PMs doing those actual jobs) 2. Does the team have self-motivated, high-performance people? I have yet to see any process that can overcome "No and no." Large tech org's knee…
Re: You don't need Scrum, you just need to do Kanban right (2022)
#257Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend all the cruft that comes with Scrum, the article seems like a bit of a straw man.
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…
Re: You don't need Scrum, you just need to do Kanban right (2022)
#258Earlier quoted context omitted.
Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.
If revenue they bring is estimated you may only need relative comparison. After all if dev team days that more perspective project is very likely cheaper to make, why would you choose the other one? See? No need for detailed answers if there is sufficient difference in qualities.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#259Earlier quoted context omitted.
Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.
Meh. The time it takes to complete a project is usually somewhat flexible. What really matters is how valuable the project is. That is what needs to be estimated explicitly, and not just "I really like these two ideas lets do the cheaper one".
Re: You don't need Scrum, you just need to do Kanban right (2022)
#260Earlier quoted context omitted.
Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it. Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team d…
> It creates the illusion of accountability while creating artificial touch points I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless. > The question in my mind then is if I haven't seen a sin…
That was a reply to "...but for many the accountability of Scrum..." in the parent comment. There's an idea that Scrum creates accountability by making it possible to measure how well a team is meeting their commitments. It really doesn't. The metrics that Scrum exposes are little more than semi-random numbers. You're asked as a team to "commit to completing" some mostly arbitrary total of these numbers that has been determined to be your teams "capacity".
The entire premise of this kind of estimation is fallacious on face. It completely ignores the skill level, overall capabilities, and specializations of your developers and effectively equates them to an common minimum of mediocrity. Worse, it pre-supposes that your team fully understands all of the places that a particular task can go sideways which is almost never the case.
About the only way I can see it working is a situation where you know exactly what needs to be done, step by step, from or near the very beginning of a project. Otherwise, all you're doing with Scrum is forcing the team to make decisions on a Sprinted cadence rather than at natural break points along the completion of a project. This creates artificial delays, particularly when other teams are also working on sprinted cadences because you're likely to be requesting things that won't make it into some other teams sprint. Creating at least a sprint long delay before your team can complete their work, and well, breaking your sprint goals, etc..
Sigh ... Hence the accountability and predictability that's supposed to come out of Scrum is illusory at best and usually self deception.