000.png

# random

[Z]

000.png

[Z]

@Stefan Oltmann what does mean , no understand ?

[Stefan Oltmann]

@Z Are you asking what the emoji "😄" means?

[Z]

no

[Z]

what did you understand from the quote ?

[Z]

plz

[Z]

@Piotr Krzemiński? what did you understand from the quote ?

[darkmoon_uk]

In my experience Kanban == Scrum without the weekly Scrum ritual of 'getting to the bottom of why ticket X, Y or Z wasn't delivered perfectly / inventing some new useless process that only really applied to that one situation' i.e. most often a navel gazing waste of time that would be better spent just getting on with the next item.

[Stefan Oltmann]

Ah, ok, you are asking what the message is. You could have posted your question together with the image. 😄

So, what I got: If your team/organization doesn’t have the discipline for Scrum, the move to Kanban (as an alternative) will make things worse. In Scrum you have two weeks sprints / work intervals and reviews & retrospectives in between - so that’s the timebox. If you report at the review that you achieved nothing in the last two weeks it will be noticed at that time. Kanban, however, doesn’t habe that control instance.

[darkmoon_uk]

Maybe it says more about the places I've decided to work, but I've seen Scrum work well in precisely one organisation in my career so far. In all others -without fail- management strong-arm changes to the Sprint (disrespecting the process) then angry pikachu face when the sprint doesn't go as originally planned.

[darkmoon_uk]

Kanban makes that less stressful for everyone involved - it's a process that doesn't make promises it can't keep.

[darkmoon_uk]

Scrum worked when it worked, I think it demands more readiness and discipline from the organisation than from the Dev team.

[Stefan Oltmann]

Yeah, surely depends on the execution. My old company also had „scrum“, but only did the daily standups - reviews & retrospectives were considered to expensive. 😄 and yes, they also changed priorities in the middle of the sprint.

With my current company that’s another story. We don’t do the daily scrum because we are a small team, but showing a demo of the current state every two weeks at the review (so all stakeholders see and know it) and discussing at the retrospectives about what went wrong and how to improve things turned out to be really helpful.

[Stefan Oltmann]

The organization must be willing to pay the price of two rather big meetings that occur all two weeks or else it won’t work.

[Stefan Oltmann]

Big in terms of the people attending. A product can have many stakeholders (CEO, CTO, support, QA, etc.) and sometimes a lot to show. My last reviews usually took about 30 minutes and the retrospective afterwards usually an hour.

[darkmoon_uk]

I guess in summary, I disagree with the image.
What I've seen is:
• Kanban is better in dynamic environments as changes are no big deal.
• Scrum can have a higher peak performance but only if the business truly respect the tech teams process (and this is RARE)

[Stefan Oltmann]

My old company really did Kanban in sprints. It was totally strange and every planning of a sprint a waste of time.

It’s good to now have this 2 week timebox. It’s an opportunity to acknowledge that an issue is bigger than I thought (like Google Drive Support 🙄) and a point in time where stakeholders can decide to continue or change plans.

Kanban can easily get out of control if a developer takes longer than expected for an issue and fails to report on that. I saw that often at my old company. If an feature is estimated for three days you might want to have it, but if it takes two weeks you may not (or not now)… if a dev spents two weeks on it without saying a word, that’s really unfortunate… if that happens too often everything gets out of control.

That’s what I think of reading the quote.