It doesn't matter what methodology is used. The most heavily weighted factor by far is whether the product owner and managers understand the implementation details well enough to keep estimates accurate and mitigate scope creep.
You don't need Scrum, you just need to do Kanban right (2022)
101–110 of 341 posts
Re: You don't need Scrum, you just need to do Kanban right (2022)
#102Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…
I have the software engineering uncertainty principle. The more you try to measure and estimate and predict software velocity and delivery the more you slow it down. I think this is probably true of any largely creative and problem solving task, but compounds because most of the uncertainty derives from dependencies requiring those dependencies to likewise measure and slow down. The more complex and interconnected an…
This sounds a lot like the coastline paradox. The more precisely you try to measure a coastline, the harder it gets due to its fractal nature.
Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire the latter.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#103Earlier 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…
Barry Boehm sort of summarised this fairly well in Balancing Agile and Discipline, although I'm sure he would disagree with my characterisation of it:
- If you have unpredictably changing requirements, and a small-ish non-life-critical product to build, and a large fraction of good people on the team, you should use an agile process.
- If you have unchanging or predictably changing requirements, and a large fraction of not-so good people on the team, you should use a plan-driven process.
But what if you have unpredictably changing requirements and a large fraction of not-so good people on the team? No process can save you now.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#104Earlier quoted context omitted.
To be honest I have never seen this materialize. Usually you get some input from product management, the devs estimate it and then do it. I have never seen feedback from estimation to requirements.
Isn't that because the product manager is gathering requirements from other orgs/users? > I have never seen feedback from estimation to requirements. Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.
I'm almost afraid to ask but what unit of time does that "8 or 13" correspond to?
Re: You don't need Scrum, you just need to do Kanban right (2022)
#105The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three. Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint. Kanban specifies fixed scope and quality, letting time be the floating factor for each task. Waterfall specifies fixed time and scope, with the inevitable…
> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically
Re: You don't need Scrum, you just need to do Kanban right (2022)
#106Earlier quoted context omitted.
Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.
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 that can be controlled by high level decisions. (Unfortunately, increased predictability usually means decreased profitability.)
Re: You don't need Scrum, you just need to do Kanban right (2022)
#107Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…
I did scrum once and we were literally always sprinting. The daily standup consisted of trying to think of excuses why the multiweek task wasn't completed (like they expected) and one dude who "zereo'd his inbox" every day.
That the iteration unit of scrum/agile is called a sprint is a huuuuge pet peeve of mine. Sprinting is definitionally an unsustainable pace.
I know, I know, it's just a label applied to the cycle time of the process but labels matter and I think it subtly and subconsciously poisons the whole thing. Especially when managers and PMs start making sprint cycles into hard deadlines.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#108Earlier 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…
Flexibility is good. I agree with that approach. But then I fail to see the benefit in scrum in the first place. The other things you mentioned (measuring all these metrics) does not seem helpful to me at all.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#109Earlier 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…
[deleted]
Re: You don't need Scrum, you just need to do Kanban right (2022)
#110Earlier quoted context omitted.
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…
Flexibility is good. I agree with that approach. But then I fail to see the benefit in scrum in the first place. The other things you mentioned (measuring all these metrics) does not seem helpful to me at all.
When you can measure metrics with some reliability, your executive team can use those metrics to plan out releases (e.g. "the new Fizzbuzz feature is expected in Q3"). That allows your marketing team, budgeting team, and deal flow team to plan around it (with the understanding that it is statistically reliable, not necessarily individually reliable).
If your development situation has high enough stability that kanban will be the best fit, you'll get much more reliable metrics for planning, but less flexibility when something unexpected happens.
If your development situation has enough uncertainty that scrum is the better fit, you'll have less reliable metrics for planning, but a lot of flexibility to deal with the unexpected (which you expect to encounter with some frequency, otherwise you'd be using kanban).
Cutting edge technologies and startups are usually better suited to scrum because they need the flexibility to pivot when needed. Well established technologies (like Oracle DB or MS Office or Ubuntu or Jira or a CRUD app) are likely better suited to kanban because they'll benefit from the streamlining at the cost of flexibility they don't need anyway.