Sounds like they're about to throw out Kanban in favor of quitting
Ditching Scrum for Kanban - The best decision we’ve made as a team
91–100 of 118 posts
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#92> The rituals, mainly the standups and grooming sessions, were fantastic. Standups are a great way to keep everyone aligned on the work. Can anyone elaborate why they find standups useful? The planning board should already communicate what's being done, what's been done and why people are blocked. I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during dail…
You get a quick status update of all the bits everyone is working on. Oh, Bob finished the xyz bit? Great I'll get started on abc now. Jim's stuck with the autobuzzulator? I've used those before, I'll jump in and give him a hand after the standup. Katie's not been able to deliver the turnip functionality? Still can't test the beets either then... It should take no more than a few seconds per person and I find it far…
I prefer ditching standups in favor of constant communication, people should know who they need to talk to and avoid waiting for specific checkpoints.
A not-too-long team meeting once or twice a week to talk about big themes is pretty reasonable, but usually I can't even remember what is said in a standup, because much of it isn't things I need to remember.
If it's forced short, there's usually not enough data, if it's it's too long, everything gets tuned out. It's really another kind of status meeting, and I think meetings should instead produce actionable items.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#93I was curious to understand what exactly software managers were calling by "kanban" now that the name is fashionable. Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.
Can you elaborate?
In physical production (where it comes from), kanban is a lean method for ensuring that you don't spend on producing right now something that is not needed right now.
It works by tokens that "pull" the production from other productive unities that are ultimately "pulled" from external (client) demand.
The article talks about all kinds of rituals and gains, but never once touches that "pulling" activity that is central to the concept, nor the lean objective.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#94Can anyone recommend a good, concise book on Kanban in software - preferably without mingling in Scrum?
There are multiple titles that come up on an Amazon search, all with similar review scores.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#95> The rituals, mainly the standups and grooming sessions, were fantastic. Standups are a great way to keep everyone aligned on the work. Can anyone elaborate why they find standups useful? The planning board should already communicate what's being done, what's been done and why people are blocked. I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during dail…
My current team does not do standups (or Scrum or... any of these things, really). We have a rolling list of open features/cleanups/bugs and a polite triage convention. In my last company we were all-in on what I can only call Scrummerfall.
As far as I can tell, the effectiveness of the team has a lot more to do with people's ability to self manage their workload (under any system) than how much time and effort is dedicated to tracking it.
We are also able to provide other dependent teams with better day to day visibility on specific requests rather than sprint-level visibility.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#96> The rituals, mainly the standups and grooming sessions, were fantastic. Standups are a great way to keep everyone aligned on the work. Can anyone elaborate why they find standups useful? The planning board should already communicate what's being done, what's been done and why people are blocked. I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during dail…
The value is in creating a summary, to collect all the stream of conscience updates into a coherent statement about status and next steps. A daily standup of summaries removes the burden of mentally remembering yesterday's minutiae to reconstruct the current state. I mean, if you want to know the status of a system do you go to the dashboard or do you go review every system event for the past few hours? I hope not th…
>Scrummerfall
My classically trained PM after taking an Agile training class:
First we'll have a planning sprint.
Then we'll have a coding sprint,
Followed by a testing sprint...Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#97Earlier quoted context omitted.
No, at the standup you shouldn't have conversations about things. You should just do a quick recap of what you've been doing and what you'll work on. It's a standup because it's meant to be very quick. On the other hand, if you need a standup to ask questions about stuff you're stuck on, then your work environment has serious issues. It might be 24 hours until the next standup. You need to have colleagues who are ava…
It should not turn into long discussions, but if standup is for mentioning what you're stuck on, it seems really strange that others are forbidden from mentioning how to get unstuck. I'm used to pair programming and communicating all through the day. This is incompatible with the surly loner programmers you describe in the last paragraph.
Are you blocking a whole bored and standing team to get help from a workmate on an issue that is relevant to you only? I hope not. I think the Agile orthodoxy prescribes that any conversation that lasts more than a few tens of seconds should be saved for after the standup. And it makes sense. However, if you were stuck on something, then you've probably been for some time before the standup. So I guess you had plenty of time to ask that knowledgeable team member before.
As for the lone programmers you haven't met: lucky you. I seriously believe that in the "agile" companies I've worked in, scrum was actually intended to make people talk, if only once a day and for a few minutes. What was that line? Ah yes: "individuals and interaction over processes and tools". Good luck.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#98Earlier quoted context omitted.
It adds impetus to appear busy and/or find something to report. I think it was said higher in this discussion: recurring meetings are a form of "social engineering"; and I'll follow that with an assertion that they have more affect on the structure of the team (and individuals therein) than they do on the effort the team is nominally working to achieve. If you want to build software systems, you should engage in soft…
I think motivating factor is the least helpful thing stand ups provide so your assertions are slightly correct if that was the goal of stand ups. Stand ups actually provide: 1.) Better communication of what everyone is working on. 2.) This leads to faster cross training as people are able to ask questions. 3.) Making others on the team aware of issues you are working on so they don't make bad assumptions that you're…
1) Better how? For whom? What's your metric on that and does it hold true in all circumstances and contexts? I'd make a general assertion that "better" communication is written communication as it is more easily reviewed later and by parties not originally involved. An asynchronous persistent communication channel beats a synchronous one when you need to coordinate non-synchronous activity (which often involves coordinating with external teams and stakeholders).
2) People can ask questions at any time, but in a meeting only one person can really have the floor so provides a synchronous block on communication for anyone not involved in the exchange.
3) "Making others aware" so they don't think "you're not doing anything", is the social pressure "face-saving" style I believe has nothing to do with software engineering (at best). At worse, if your entire team is obsessing that you have less to do than they are doing, then they have way too much time to obsess with, probably the time they spend in those meetings; they should take it up with management, who should have knowledge on what's going on anyway due to status reports and a general involvement with the team in an ongoing basis.
...
>>> I disagree. A good manager should have a broad overview of what's going on but, he should be busy in his own job planning etc. to not have to micromanage. A 15 minute stand up each day gives him insight he needs without standing over anyone's shoulder or worse making false assumptions about what they might not be doing.
The term micro-manage is yours not mine. A 15 minute stand-up gives him the power to assert that for 15 minutes each day, he is the alpha-male. That's really all face-time meetings like that do when it is between subordinates and superiors. For everyone else, its a jockeying up position and pecking order. Welcome to the primate side of human culture; I didn't make the rules I simply observe them every time I see it happen.
If he can't get what he needs without appearing to be micro-managing, he lacks the social skills to manage with greatness. But he'll be in fine company as most of his management peers are roughly equivalent. From my own experience good managers are few and far between because to be a good technology manager you need to be a good manager and a good technologist.
However, if a manager is going to pick a team management religion, he'd do best with Zen.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#99Earlier quoted context omitted.
I think motivating factor is the least helpful thing stand ups provide so your assertions are slightly correct if that was the goal of stand ups. Stand ups actually provide: 1.) Better communication of what everyone is working on. 2.) This leads to faster cross training as people are able to ask questions. 3.) Making others on the team aware of issues you are working on so they don't make bad assumptions that you're…
"better communication" and "cross training" are the biggest misconceptions about the stand-ups. A good/proper standup is short and there's no way to communicate and exchange enough detailed information and context to make it a meaningful communication and especially cross training tool. Standups are meant for peer-to-peer coordination on the dev team. This leads to another misconception... Standups are not status rep…
If the dev team isn't coordinating and communicating outside the meeting, then you have problems the meeting isn't going to solve.
I do agree with you that a manager's job is to support the team, and not the other way around.
Re: Ditching Scrum for Kanban - The best decision we’ve made as a team
#100This really resonates with me. My experience with scrum was very similar, and I thought Kanban might be a nice answer to the arbitrary deadlines that frustrated me. Never got a chance to try it, though.