DEV Community

Cover image for  Daily Standup Meetings are useless
Davide de Paolis
Davide de Paolis

Posted on

Daily Standup Meetings are useless

Yes, Daily standup meetings, also know as Daily Scrum, are useless, if done in the following way.

Everyone stares at the Trello, Asana or JIRA board, the PjM or TechLead address each team member with a question about the tickets they are working on, and something similar to this conversation happen:

(PjM) John, how is it going with ticket XYZ?
(John) Quite well! I worked on that, I did this and that, almost done, just need some final touches, polish the code, add a couple of test, stuff like that. I should be done today.
(PjM) Great, let's move on. Maria, what's the status of your ticket?
(Maria) I am done with it, unless Bob has comments - he is reviewing my Pull request.
(PjM) Sounds awesome. Don't be too nitpicking Bob, right?!

wink wink

This is not a standup round, this is just a status update, and, i find it totally useless.
I have access to the JIRA Board, i can open it anytime and see under which column your ticket is ( assuming you were so kind and disciplined to move it from open to in progress and from in progress to in review...), what is the point in you just rephrasing it loud in front of the team?

The most important thing in a standup is clearly communicating any deviation from what is expected, asking questions and asking for help. Maybe some blockers are slowing you down, maybe you depend on other teams to achieve your tasks. Please let the team know. Don't just "reassure" everyone, in some vague gut-feeling way that everything will be ok...

Another case when Daily stand-ups are useless, and a waste of time is when one or more developers start discussing technical implementations or bug-fixes in detail. If there are developers that are not involved in that project / feature / tech stack ( imagine a cross-functional team of many developers ) then you will be sure after 30 seconds all other team member will zone out, and will not get back even when you move on to the next topic or developer.

zoning out

Standup are not about technical details, even though some technical context can help to frame the arisen complexity and allow PjM and Leads to take the necessary steps to enable you achiving your tasks ( additional meetings, extending the deadline, reestimating the task within the sprint, set up pair programming sessions etc).

According to the official docs the Daily Scrum is a 15-minute event for the Developers of the Scrum Team.

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and produce an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

Honestly I am not so sure about the last point, due to the short time allocated to it, it can indeed generate other meetings, follow-ups between Tech Lead and (some of ) the developers, or between the team and the stakeholders, or among developers which decide to tackle an issue with pair programming. But I agree that this additional meetings allow the team to be more aligned, progress faster and avoid wasting time in working on the wrong thing or struggling on a problem someone else already solved etc.

I must admit I fall myself in the temptation of hijacking the standup into a technical discussion, but really, the standup purpose should be,

  • pointing out blockers,
  • give a shout out about problems and request for help
  • share valuable information.

Yesterday I updated the dependency of the Test framework we are using and realised the pipeline was broken even though No breaking changes was announced, unfortunately it took longer than expected but I can now go on with TDD for the current feature.

or

Yesterday I checked out the repo to work on my feature but I was not able to run the app locally due to this and that - has anyone experienced that? Is there someone that can double check that with me later?

or

I am halfway through the implementation but I realised the data being sent by our backend is different from what is documented in the ticket. I had to start a conversation with the backend team and found some misunderstandings in the feature requirement. Can we set up a meeting with the stakeholders to clarify those points?

Yes, sometime it requires a bit of courage and lots of confidence to openly speak about what slowed us down ( we don't want to look dumb, incompetent, nor blame other colleagues or team), but this is what those meetings are for.

Be clear, be honest, be informative, and proactive.

If we stick to these simple rules and don't lie ( here you can find another post about why we usually lie during standups), those meetings are indeed a precious time for our teams!

Photo by Jason Goodman on Unsplash

Discussion (49)

Collapse
thumbone profile image
Bernd Wechner • Edited on

It's interesting to read diverse views on stand up meetings here. For my part (and it's easy to imagine it's a naive or at least not vogue part), I always viewed the main points and benefits of routine stand up meetings were:

  1. To keep it short and sweet (hence standing up)
  2. To keep a collective and physical finger on the pulse of the team. Specifically face to face and not YASTSA (yet another screen to stare at).
  3. To get these screen-glued geeks out of their shells a little
  4. To promote accountability. Having to front-up and physically share, briefly what you've done, what you're stuck on or what you plan to do next, is kind of motivating and inspiring at some level.

But of course, any one thing (routine stand up meetings in this instance) is many things to many people. It's interesting to read here, the diverse takes and experiences.

Collapse
uclusion profile image
David Israel

I agree that any one thing is many things to many people but have trouble seeing how point #4 is not universally offensive.

Enforcing accountability that way would be rejected by almost any other profession - lawyers, doctors, professors, managers, etc. Is there some reason that developers are not deserving of the same respect?

Collapse
thumbone profile image
Bernd Wechner

I can't see how it's offensive. Most any profession can and does similar indeed in my experience. If there's a team conducting surgery, I don't doubt for a minute they have a collective and very probably stand up debrief just before it starts, at intervals during if it's long and after it's done (I could of course be wrong, my lack of doubt is not proof of anything - hospitals are diverse after all). But it comes into its own in soft endeavours ...

What is a soft endeavour? Ironically software is one. Research is too (I worked in research a lot), I classify the endeavour as "soft" hear to indicate that performance is impossible to measure. It simply does not relate linearly to output. Research is classic in that space, and software development as well. They aren't like assembly lines at Ford, nor construction sites for skyscrapers, they are not paper pushing at a bank or in the public service even (though there are jobs in the public services similar, legal stuff, law, and legislation touches on similar "softness").

Because they are soft, employee motivation and drive or lack of it can create significant shifts in net output that micromanaging cannot. Micromanagement is about scrutinising every task and whether it's late or on time and it very very useful in many context and can even reap significant rewards in software (I successfully managed software projects for some years using Steve McConnell's three-point estimation methods). But there remains a rather strong soft component because I can legitimately spend one day or three on a given job and easily convince most anyone who isn't scrutinizing every keystroke that that's just how long it took. It's not insulting to anyone to observer the reality of that property of software development. It didn't insult us to recognize it in research either (I was working in a research facility in the steel industry at the time). In the latter (research) it has long been conventional to deliver verbal reports to the entire team at intervals. Generally it was a more formal 5 minute talk cycle over longer periods, say quarterly.

In software when I participated and organised routine meetings I admit I can't help but notice that for a good many staff (it's not universal, nothing is) the need to share openly and the routine of doing, and in the case of stand ups to added requirement to focus on brevity, poignance, the key issues, was well received, helped to motivate and inspire... a good many people don't perform as well left to their own devices, but actually flower in the light of recognition and caring at this level across a team. Yes, others again flower better under more one on one recognition with a supervisor too. We are diverse, nothing decks everyone's needs all the time - made famous by Lincoln as "You can please some of the people all of the time, you can please all of the people some of the time, but you can't please all of the people all of the time”.

In any case it's a long way from universally insulting. But I can easily accept that some would and do find it that way yes. But they can generally be talked through it ;-). Remember the meeting is not about "enforcing" anything, it's about giving everyone a hearing and lending everyone an ear and being public, being open with your progress that is all. And many people do,like it or not, feel motivated by, or inspired by, the need to live into their public image in that way. It works well.

The converse, that I have seen, is an office full of communication challenged geeks (all in business suits no less in some cases) sitting behind screens at keyboards clack clacking a way, in a dead quite open plan office, and you walk in and what say "Morning all!" and maybe start by doing that in your first weeks before you realise half these people are on the spectrum ;-) and their grunted replies are not encouraging so you falter ... I'll take a morning standup meeting any day over that.

Thread Thread
uclusion profile image
David Israel • Edited on

Its a mandatory meeting ie enforced and requiring it for accountability reasons is clearly offensive. Also "communication challenged geeks" is obviously very offensive - its possible you have no ability to empathize.

Edit - just noticed the half on the spectrum part - very nice.

Thread Thread
thumbone profile image
Bernd Wechner

On "communication challenged geeks" is obviously very offensive:

I have worked in IT for decades and never found one offended at the reflexive observation than many of us have communication challenges and equally many are very happy with the labels geek or nerd even them having been long ago made objects of pride by the tech boom, Gates, Jobs, Wozniak, Torvalds and more ... few of us in my experience find such reflections offensive and I'm deeply surprised to find one on dev.to I have to admit. That said, clearly the intent is in no way to offend, simply the assessment as to what is offensive differs and I am long enough in the tooth and familiar enough with an age in my youth where my own physical and social traits attracted open derision and ridicule in the form of tropes like the nerd and the 98lb weakling that were stock pop culture ... so I'm not in the least bit insensitive to your feedback, just a little surprised to find it here on dev.to a forum of IT developers.

On mandatory meeting ie enforced and requiring it for accountability reasons is clearly offensive:

Two issues with that observation:

  1. No-one suggested that the only or even prime motivator, and the only benefit of regular meetings is related to accountability and the motivation and inspiration that may provide, only that this is one of the features of regular team meetings.

  2. Even if it was, I can in no way see that as clearly offensive. I do detect a little projection of your social norms onto the subject matter, and it's not surprising of course that a global forum brings together folk with disparate social norms. I've worked across a number of industries in all manner of contexts and a good chunk of it in IT but have yet to come across any context in which regular meetings and an expectation to attend them for a quick sharing was viewed by anyone as offensive. Bothersome yes, offensive, never. That said, simply because I don't recall it doesn't mean it didn't happen, there are the issues indeed that you allude to, of my noticing to begin with and subsequently remembering (as I cast my mind back to say imposed regular meetings on us in the late '80s and my reaction then and those of my peers).

I take your feedback gladly David, but I do think you're reading a lot more into what was shared than I imagined possible and have a penchant for assuming things clear that are far from clear .... Cultures, and workplace cultures are extremely diverse not least on global fora like this and it is so easy to assume that what seems clear to me here is generally clear ... but that has name: projection.

Thread Thread
uclusion profile image
David Israel

You can read Marcus Geduld's response to your accusation at quora.com/Why-are-most-developers-...

Developers are out there every day writing blogs and books, they are not bad at communication, programming is itself a form of communication.

But that's the beauty of this "standup" for accountability isn't it - get people in a room together and then you can endlessly berate them for lack of "soft skills" if anything goes wrong on the project.

Thread Thread
thumbone profile image
Bernd Wechner

Nice. And on the money. Geduld is right. You're still reading way more into this than intended though and taking more from Geduld than he wrote. For example I totally agree that communication styles can misalign (heck I've done enough courses in that over the years and been classified any number of ways on charts as have most I've worked with). And I concur with you that developers are blogging wildly, ad nauseum even and often great at communicating even (as in I read stuff on-line that can't make sense of too or that I'd classify as poor communication, just writing does not make it great comms but we digress as I concur, often developers are great communicators).

But none of that impacts a broader observation that if you know a great many and haved in a great many offices the overriding pattern is almost universally observed and it's not unjust or insulting just an observation. And it becomes a trope, and I think you're a little sensitive to it. And we could pick it apart and try and paraphrase it but no need, we both what it is ... and you find that trope offensive I suspect? While I've seen the Tech boom simply move that trope from a pejorative to a mere descriptor ... having validated it, having badged it as OK, acceptable.

Folk today are routinely unashamed to describe themselves as on the spectrum, or talk about "me Asperger's". In fact there was an observation in circulation about 10-15 years ago now that by the clinical definition of Asperger's syndrome recently tabled then, a good third or more of programmers would qualify ;-). That was a meme spread among programmers here anyhow ... that travelled across the sector.

It also doesn't change the reality that you will meet and I have met, and work with, and I have worked with, programmers that have excellent written communication skills and struggle verbally. Heck I have have described myself that way regularly, and regularly not as well. Contextually some people communicate well given time to absorb, process, and formulate a response, a luxury they are robbed of in verbal contexts often. The quick of tongue are often those that move into management, or politics etc I suspect, while others take to writing and blogging has lent this demography a wonderful platform and voice and it rocks! We all love it.

I doubt that we disagree on much really - I doubt, given enough discourse, many people experienced in similar fields do - and essentially we've seen a small thing I though (that one value I see in a routine meeting to touch base and report and especially if it's brief and a pulse check more than a time wasting theatre is that it inspires and motivates in part again through the vehicle of public display and accountability) touched a raw nerve in you about disrespect, distrust, and professionalism, and meetings gone wrong. And oh, don't we all know meetings that have gone wrong ;-). Brainstorming meetings are my favourite, vogue for so long, and almost always an unproductive schmozzle and oh so popular with management for so long - I'm glad to be rid of them. And undisciplined meetings where one or two people are on monologue contests while others roll their eyes, resist nodding off or playing with their phones ;-) ... the worst.

And yet that brings us to precisely the style of meeting we're discussing, a brief, stand up (to encourage brief) well chaired - so reigning in segways and detailed monologues - routine meeting has some benefits (and can go pear shaped of course too). But one of those benefits is precisely bringing the team together face to face to practice a quick share and listen and get away from screens.

Of course such an idea will only have appeal if you are not already overburdened with meetings. And that speaks to the background culture from which we are speaking. If your background culture is one already overburdened with pointless meetings, this would just be another one. If your background culture is one with few if any meetings (as is mine), this one routine can be seen for the value it adds.

Thread Thread
uclusion profile image
David Israel

I read a meme that said that most managers are sociopaths so I guess it's okay to explain to a boss that he is most likely one?

If your background culture is one already overburdened with pointless meetings, this would just be another one. If your background culture is one with few if any meetings (as is mine), this one routine can be seen for the value it adds.

No if that were the case attendance would be voluntary. A mandatory meeting where at least part of the point is accountability is not that meeting at all.

Thread Thread
thumbone profile image
Bernd Wechner

Yeah, lots of managers are sociopaths and CEOs reputedly psychopaths. Believe it or not we can joke about that here too. Perhaps that's a difference between Australia and the US? And if you had a major falling and were quitting or being sacked it would be totally cool to suggest that your boss too yeah ;-).

Can't help but think you have a very different work culture background. Wouldn't surprise me, I've not worked in the US but with many who have and had many US customers and the take home has indeed usually been a huge difference in workplace culture (and rarely flattering of the US I might add).

See I'm not even sure what you mean by mandatory and voluntary. These are not words that crop up much in working life here in any context, let alone meetings. Much rather we would speak of expectation that you attend a given meeting, and of course the importance in a sense, of any such expectation would depend on who is doing the expecting ... Certainly for team wide meetings.

Very small meetings, two or three people to discuss something, of course, the expectation is high and he meeting rescheduled if one of the required participants is not there (fails to show for whatever reason).

For a team wide meeting the expectation is always between your poles of mandatory and voluntary, not quite at either of them. If you can't make it fine. If you have a conflicting priority, fine. In that sense, not mandatory. But you are expected to attend and not coming without some reason would encourage a conversation (between the expector and the expectee) and the nature of that conversation is entirely defined by the relationship between the expector and expectee and nature of the expectation and non-compliance. But by no means does that qualify for the label voluntary. So neither mandatory, nor voluntary have any place in our meeting workplace culture.

Are these common terms in yours? In the US generally?

Thread Thread
uclusion profile image
David Israel

Its not a voluntary meeting - quit playing semantics (or does that not translate either?).

Thread Thread
thumbone profile image
Bernd Wechner

David, semantics are not a play! Semantics are the study of meaning. And meaning and intent are central to communication and comprehension. There is no such thing as "just" semantics.

We clearly have very disparate work cultures and experiences. As stated, yes, it's not voluntary, nor is it mandatory, it's expected ... I suspect this linguistic difference relates to our distance from the UK (in time). That is the US separated a good century before Australia and so our language is far close to the UK than yours still (has had less time to diverge). And harsh words like mandatory are not so common here in workplace. They exist, but are reserved for things like legal obligations.

I find it puzzling that in one comment you speculate that I maybe lack empathy,and in another you dismiss these cultural differences as playing semantics, as if people don't react differently to different presentations (another thing we've both agreed they do).

Is your work culture devoid of expectation? No-one expect you to come to work? To deliver any outcomes? To execute any tasks? Our work relations are driven by expectations. What is it to you if in addition you are expected to attend a meeting? I have honestly never encountered such stubborn insistence that a workplace expectation as simple as attending a 10 minute meeting routinely should be deemed so offensive, in particular if accountability figures in any way shape or form in the motivation or justification for the meeting.

I admit I am finding that novel in the extreme. I wonder if any other punters will weigh in, I'd like to see a seconder, someone else who find these things so offensive. It's totally new to me.

Thread Thread
dvddpl profile image
Davide de Paolis Author

honestly i find these distinctions pointless.
we are at work, we are supposed to be working, we are paid to do so.
there are requirements, expectations to be met, performance standards to be achieved.
some meeting are declared as mandatory - like an All Hands from C levels - or mandatorylike - considered part of the team routing, ie sprint planning, standups and other techincal discussions - and voluntary - like those meetings to face some incident and any people that thinks that contribute can join.

work culture is in fact different, and not only from country to country, but from company to company. honestly i have no idea what the consequence of missing a mandatory meeting could be.. a reprimand, being dismissied, low rating in performance feedback? this is not the point right here.
honestly i don't know anymore what your point is @uclusion about the article and standups in general since you have been jumping around picking words and starting threads about those derailing the main discussion.

Thread Thread
thumbone profile image
Bernd Wechner

I have a feeling that David has just had a bad hair day (or so the idiom goes in Australia). It's been sort of fun, I like hearing diverse perspectives and from different work cultures. But with his strong and adamant and judgmental voice, I fear David has not been a walking advertisement for Uclusion. There is much room for diversity in this world including those who see value in different things.

Thread Thread
dvddpl profile image
Davide de Paolis Author

i share the same view. thank you for expressing it so well.

Thread Thread
camerenisonfire profile image
Cameren Dolecheck

This was an interesting thread to read through. Your responses were well explained and thorough, surprisingly so given the tone of the other participant.

Collapse
dvddpl profile image
Davide de Paolis Author

I don't find it naive at all. Agree on all points. Especially the accountability part and the intrinsic motivation of listening others speaking about their job. Thanks for sharing

Collapse
uclusion profile image
David Israel

And also the "communication challenged geeks" and half on the spectrum part?

Collapse
nssimeonov profile image
Templar++ • Edited on

You are so wrong... so damn wrong about stands being useless. Try running your own company and you will soon figure out why standup meetings exist. That and a lot of other stuff.

You are right about one thing - the standup purpose IS to point out blockers, give a shout out about problems and request for help and directions. Not to share valuable information - technical meetings are for this, not stands. Stand should be just to keep track on the team pulse.

Also think about them from a different perspective - some people keep slacking until the very last moment unless they know someone will check what they do. If they know, that they will have to lie in front of you they may actually do something instead of nothing, right?

Cheers.

Collapse
dvddpl profile image
Davide de Paolis Author

if you read the article, not event in its entirety, but just at the second line.. :wink you clearly see that the title is slighly clickbaity. I find them useless because most of the time they miss the point. they should be done right, and they are great.
we might have different opinion about what valuable information is, but not about the fact standups are valuable indeed!

Collapse
f3ropeadope profile image
Michael Clinton

Sounds like you just have a bad agile practitioner facilitating your standups.

Here's what I do:

  1. Pleasantries as folks trickle in (1-2 mins)
  2. Trivia or Riddle (5-7 minutes)
  3. Anything you need feedback on? Discuss anything impeding progress. (1-5 minutes)

This assumes you trust your teams to progress through their work and have other measures in place (colocation, strong practices in chat apps) to foster collaboration.

You're blaming the wrong thing

Collapse
williamlawrence profile image
Will Lawrence

When I see stand ups, there is usually a format that all stand ups follow:

  1. What I did yesterday
  2. What I am doing today
  3. Are there any blockers?

In my mind, the first one is actually bad. It forces you into a performance of why you are valuable and deserve to be on a team. It's totally not needed. What are you are doing today, and do you need help is more than enough.

Collapse
dvddpl profile image
Davide de Paolis Author

in a perfect world, we would not need any of the 3 points.

  • would you like to know what i did yesterday? check TOOL_OF_YOUR_CHOICE for tickets I moved to DONE
  • would you like to know what I will be doing today? check TOOL_OF_YOUR_CHOICE for tickets I moved to IN PROGRESS/FOR DEVELOPMENT
  • would you like to know if I am somehow blocked? check TOOL_OF_YOUR_CHOICE for tickets I moved to BLOCKED
  • would you like to have more details about that? read the comments in those tickets. No need for such a meeting at all. Reality though is way different from any textbook or manifesto, and people have different levels of work ethic, discipline, different skills, different cultural background and language, and this is why having a meeting gives a better overview and helps some things to emerge. It is not perfect, but it is the best way we have - and we can always to our best to improve it, until it is completly unnecessary.
Collapse
uclusion profile image
David Israel

Hi Davide,

If you use Uclusion then all of the purposes of a standup that you listed:

  • pointing out blockers
  • give a shout out about problems and request for help
  • share valuable information

can be in your project management tool as well. Only using us you don't have to wait for the next standup and you don't have to be blocked because we allow asynchronous approval of new stories as well.

Collapse
rolfstreefkerk profile image
Rolf Streefkerk

that's not exclusive to your software. Any Kanban board can indicate problems with items when they're blocking allotted in progress issues or have been worked on over the average issue estimated effort.

Collapse
dvddpl profile image
Davide de Paolis Author

exactly. this is not a software/tool issue, rather a communication/soft skills one.
Since we do remoting (started in March 2021 due to Covid and we will probably go on like that even after) we are doing Slack status updates when everyone signs-off at the end of the day.
They perfectly answer the first question of a Standup ( What did you do yesterday - in this case, today) and I find those updates very informative and very useful. But the main point of the standup is raising the awareness of potential blockers and share information that cannot emerge by moving cards around.

Thread Thread
uclusion profile image
David Israel

A meeting is a tool. There are limits to what can be accomplished with synchronous meetings as there are limits to any tool. No matter how well you run the standup or do soft skills communication the meeting happens point in time.

Thread Thread
dvddpl profile image
Davide de Paolis Author

everything is a tool. language is a tool. outcome varies depending how you use the tool.
in my post I am addressing a specific problem related to communication and softskills in the people attending standups, which I noticed in 10 years of Daily Scrums, in different teams and projects.
I am absolutely fine with Daily Scrum and Kanban, how they are meant, and I am fine with Jira and Trello ( never used other tools so far, so I can;t say) , just wanted to stress how too often we overlook the main point of it, forgetting the blockers and limiting it to a round-up of how was your day yesterday..

Thread Thread
dvddpl profile image
Davide de Paolis Author

having said all that. I'd suggest to continue the conversation about the concept and not about your specific tool @uclusion thanks

Thread Thread
uclusion profile image
David Israel

The concept that we somehow forget to mention our blockers in daily standup meetings?

So you are basically saying that in 10 years of Daily Scrums, in different teams and projects, the only thing you learned is that software developers are deeply incompetent.

Thread Thread
dvddpl profile image
Davide de Paolis Author

ah ah! you can say so :wink. or you can say that developers have really to invest more energy in soft skills and communication.
Personally, I like to talk and discuss a lot about coding and tasks, and normally the awareness of blockers emerge while chatting, via a quiet request of help on slack or by physically seeing that a dev is struggling with an issue or having lots of discussions with other members. I understand that PjM and other stakeholder might need different tools, like daily standups, which unfortunately are not often optimal. not because people are stupid, incompetent, or malicious, rather because of lack of communication skills, experience, confidence.
have a nice day

Thread Thread
uclusion profile image
David Israel

Yes let's imagine for a second that people are not ridiculous enough to attend a meeting whose only purpose is to mention blockers and then forget to mention blockers.

Alternatively let's hypothesize that it's the meetings fault...

Suppose for instance that to a developer a point in time meeting doesn't really serve much purpose. He after all has to continue coding throughout the day. He's going to face blockers the entire day also.

So to a developer whether or not he mentions the blockers at one particular time of day is not very relevant. The meeting makes no sense and so he doesn't take it as seriously as you.

Collapse
katafrakt profile image
Paweł Świątkowski

Can it, really? I always struggled with setting up a kanban board in JIRA which would display blockers properly (full disclosure: I'm by no means a JIRA expert, I don't event have admin rights to it usually, so maybe I miss something). The only way it could be done was by setting up a column called "blocked", but it violates the rule that the tasks should only move forward. Other ways, such as a flag, were not visible enough, when looking at the board.

Thread Thread
uclusion profile image
David Israel

@katafrakt you didn't miss anything. Since other PM tools don't have a notification system that enforces action you are left choosing between flags and columns.

One flag or column for truly blocked and another for stories with outstanding questions or suggestions. (Or you can collapse those two types to one but that again muddles things.)

Thread Thread
rolfstreefkerk profile image
Rolf Streefkerk

you need to set column limits and change your workflow on the kanban board to a pull instead of a push. that means means you'll have two columns per step in your development process. Then you can set alerts if certain items remain for too long or there are too many items in a column.
That way you can spot issues in your development pipeline immediately as they happen

Thread Thread
uclusion profile image
David Israel

As Pawel noted there are any number of Kanban blogs explaining that is an anti-pattern. I'm just picking one at random linkedin.com/pulse/blocked-bad-bre...

Thread Thread
rolfstreefkerk profile image
Rolf Streefkerk

you don't understand at all what I just said, there is no blocked column at all. Again, review the video I've put down below. It works and the microsoft OS is build using this agile kanban style of working.

Thread Thread
uclusion profile image
David Israel

If there is no blocked column then you are using a flag and that didn't work for Pawel either.

Thread Thread
dvddpl profile image
Davide de Paolis Author

honestly.. i often dont care much if i am sticking to the orthodoxy of a method.
I adapt it to my team, my project, my workflow.

we indeed have the column BLOCKED. and i think it is very usefull because, it clearly shows that a developer CAN NOT work on something - and probably explains why they have more than one ticket IN PROGRESS at once.
but the order for us is:

TO DO - IN PROGRESS - BLOCKED - IN REVIEW - DONE
and there is hardly any going back because blocked is when the work is impossible due to forces external to the team ( further implementation is impossible without other tickets being completed, often from other departments, requirements have to be rediscussed by stakeholders etc). not because dev is sick, or cant solve a bug.

Thread Thread
rolfstreefkerk profile image
Rolf Streefkerk

We're going in circles and it seems clear to me you have an agenda here rather than just looking at the facts and information that has already been presented.

Thread Thread
rolfstreefkerk profile image
Rolf Streefkerk

Agile was never about being rigid in the process, that's the whole point of Agile to take things that work and make them fit within the context you operate.
All this talk about "this is agile", "this is not agile" seems to indicate dogmatic approaches that are actually an anti-pattern.

Thread Thread
dvddpl profile image
Davide de Paolis Author

exactly :-) it is called Agile in the end right?
and i'd like to mention 2 of the points listed here

  • Individuals and interactions over processes and tools
  • Responding to change over following a plan that;s why imho being dogmatic is as @rolfstreefkerk explained an antipattern. let's do whatever fosters good communication and helps us moving forward and faster.
Thread Thread
katafrakt profile image
Paweł Świątkowski • Edited on

let's do whatever fosters good communication and helps us moving forward and faster

Or... How about use a software that let's us use whatever we want, not stick to shitty JIRA that forces use to change the process, because it's so limited? I mean, having the tickets marked as clearly blocked doesn't seem like rigid and dogmatic approach. Saying that you don't need it because JIRA does not support it - does (where using JIRA is a dogma).

Collapse
uclusion profile image
David Israel

Is exclusive if you want to be able to skip the meetings. A Kanban board can be tricked out to display anything but not to get questions answered, pause stories or take up new ones while getting approval online.

On top of which you need a notifications system that does much better than a Kanban + Slack combo.

Thread Thread
rolfstreefkerk profile image
Rolf Streefkerk

The original purpose of Kanban is to get insights into the manufacturing process and that especially includes blockers to progress. So yes, I agree if you do not follow this process and setup your board properly to the process, this will be less effective.

Thread Thread
uclusion profile image
David Israel

It doesn't matter how you setup your board. A Kanban board is a display only tool - you can't effectively have communication inside of it or get approvals for new stories or reviews of existing work.

It shouldn't surprise you very much that 1950's factory sticky notes don't cover all aspects of modern software development.

Thread Thread
rolfstreefkerk profile image
Rolf Streefkerk

This is really making a mockery of Kanban for software development, that's not at all how it's done. I suggest you review this excellent talk from a Microsoft employee on how they've effectively used the Kanban method to tackle issues that we've just discussed.
youtube.com/watch?v=CD0y-aU1sXo

Thread Thread
uclusion profile image
David Israel

Wow the part on estimation in that video is cringey. And naturally it doesn't cover any of the issues we are discussing around the standup like

  • What you do in between standups
  • How can you get asynchronous approvals for a different story in case you are blocked. (And asynchronous reviews as well.)
  • How do you share valuable information (outside of meetings)
Thread Thread
murkrage profile image
Mike Ekkel

What you do in between standups

Work, hopefully 😂

Thread Thread
uclusion profile image
David Israel

Not according to the Scrum guide:

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.