[serial_dev]

Good point, happened to me today.

The UI requirements to my ticket didn't make sense. The changes the other dev wanted would have took us possible days. I was hesitant to start, so I asked another dev... He said something totally different, he kept referring to something the designer wanted, but it didn't make sense to me, either. I called the designer and she told me she never said that and we agreed on something else. After confirming with another dev in chat that the designer was right, I could start coding.

In the end, after 20 minutes of calls/chat and around 30 minutes coding, the issue was resolved. I saved so much time (days, really) just by being a bit sceptical.

I'm new on the team, so first I thought it is just me who can't follow everything, then asked around and realized that the level of miscommunication is shocking and people don't even realize that they don't understand things and act like everything is trivially simple (the team looks good, though).

[arendtio]

Just in case you aren't aware, but this is what agile is actually about. Big part of it is communicating with the team. Not having a fixed plan and adjusting when having new insights is also part of it, but I think the communication part is often overlooked.

In the classic methodologies, you had some document, that told you what to do. In agile you should talk about things and just use a few notes to summarize what should be done.

Acceptance criteria are a (good) tool to drive the discussion into a specific, rather than abstract, direction, but should not replace verbal communication.

[taurath]

Why do you have to ascribe good practices such as confirming work necessities as being “Agile” or not? The word (as a proper noun) to me has lost all meaning having been inane different workplaces, all of which claim to be “Agile”.

[chiefalchemist]

I've also witnessed agile being used as a excuse for "We're not going to take the time to understand the problem. We're not going to work with the client so that they understand their own problem. Nah. Insted, just do the work. Do what you're told. If we miss the target we'll fix it in another sprint. They're paying. NBD."

[tcbasche]

It’s funny because that outcome is almost certainly the opposite of agility. Just do the work and hope it’s what they wanted.

[arendtio]

Actually, because I also feel that the word has been used in many contexts and I would like to sharpen the meaning. So you might say, that I could go around an find all things that work aka good practices and say 'This is Agile', but in fact Martin Fowler (one of initial authors), said, that they even discussed calling it 'Conversational' but ultimately choose 'Agile' [1]. I think that example shows, how important verbal communication is, from the perspective of the Agile Manifesto.

[1] https://youtu.be/G_y2pNj0zZg?t=1399

[chiefalchemist]

Perhaps. But methodology should be independent of being able and willing to ask questions. A close colleague recently left a company because the talk was "we're agile" but the walk was "don't ask questions, just do what you're told."

[arendtio]

> But methodology should be independent of being able and willing to ask questions.

What if asking questions significantly increases quality and productivity? I mean, strictly speaking, Agile is no methodology but more a set of values [1], that defines a culture rather than a methodology. Yes, there are agile methodologies (Scrum, XP, etc.), but those are worthless without the right culture.

In fact, I think you are better off with the waterfall methods, if your company has no ambitions of changing the culture. So the correct combination of culture and methodology is critical.

[1] https://agilemanifesto.org/

[chiefalchemist]

Culture > methodology

Culture either allows and values questions and improvememt or it doesn't. If it doesn't then methodology will not override (read: fix) that.

Waterfall or not, or otherwise isn't really relevant. Culture is.

[jonpurdy]

You are 100% correct. This is why Acceptance Criteria are a thing: so the person working on the ticket knows exactly what it means to be "Done". If they're unclear, they must be made clear (by questioning as you did).

Often, unclear description or Acceptance Criteria means that the ticket hasn't been though out properly and needs to be clarified (or scrapped).

[btschaegg]

Not to dismiss your point, but I'd like to add that simply adding an "acceptance criteria" section to all tasks also isn't a solution.

I've just recently encountered a ticket from a certain person that does this all the time. The problem is that their criteria still only describe the solutions they imagined themselves, which are often… very suboptimal.

In the end, what you want is someone who is capable and willing to properly root cause a problem and weigh multiple possible solutions against each other. If nobody does this, no amount of superficial process will help you.

[zikzak]

Many of the process improvements we have made where I am over the last ten years boil down to "ok, stop, does this still make sense?" at each hand off. It helps that we make data driven decisions so the stakeholders know what they need rather than "yeah, can you make me a button that doubles or revenue?"

[BurningFrog]

Keep communicating with everyone, and you may lead this team in 6 months.

[capableweb]

Well, make sure that's actually wanted before jumping into assumptions.

I had the misfortune of assuming people want to communicate more in order to avoid miscommunication but it turned out that the team (~5 developers in a ~15 person company) actually wanted more walls around them, minimize communication and focus on silo'd development (one frontend, one backend, one ios, one android and one infrastructure with 0 sharing of tasks even if one was behind/in front) with as little communication between devs and others in the company as possible. Only the person dedicated for communication should do the communication.

I didn't agree with this so I no longer work there, but there was a few months of pain because I assumed everyone wanted to communicate but didn't have the experience/tools/processes to do so. I was wrong, which took time to discover as I assumed everyone wanted agile collaboration.