6 ms·

There isn't anything here about having to do daily standups: https://agilemanifesto.org https://agilemanifesto.org https://agilemanifesto.org/principles.html

There isn't anything here about having to do daily standups: https://agilemanifesto.org https://agilemanifesto.org https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum: https://scrumguides.org/scrum-guide.html#daily-scrum https://scrumguides.org/scrum-guide.html#daily-scrum

vegetablepotpie 2y ago
There isn’t anything in the agile manifesto on how to do anything. It’s a statement of preferences and values. Business demands process for people in functions to follow. Scrum outlines meetings for programmers to attend, and specific process outputs like user stories to produce and close. Scrum is agile in business because business cannot do agile.
- stetrain 2y ago
  Right, so when someone says they are doing Agile instead of Scrum but don't like it because of the invasive status meetings, they're probably actually doing some form of Scrum whether or not they realize it.
  - bluGill 2y ago
    There are agile processes other than Scrum. Scrum has gotten all the press for some reason, but there are other options. I personally prefer Kanban. The sprint is not a useful deadline for me so I want to ignore it.
    - stetrain 2y ago
      Agreed. But Kanban also often incorporates some of the processes from Scrum like daily standups that aren't prescribed anywhere in Agile. Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.
      - bluGill 2y ago
        Agile is not against processes when needed. Agile is against too much process.
        JohnFen 2y ago
        And yet, the most process-heavy places I've ever worked at have been "agile" shops.
bluGill 2y ago
The business has a need for a regular status update from everyone. You can call it a standup or not. You can call it not agile, but in the end the business has needs and you cannot ignore those needs. The business needs to know when something will be done as they need to make promises to customers. The business also needs to know when things will be done as that is a proxy for cost - they need to make sure they are not spending more creating a thing than it will deliver (this is a hard problem as some sales will not happen until it is done and there is typically a competitor customers could go with). That is nearly impossible to say how long engineering will take doesn't mean we don't need to know how long it will take!
- stetrain 2y ago
  Sure. I'm not saying there shouldn't be status updates. I'm just saying that those status updates aren't because they are "doing Agile." There isn't really any such thing as "doing Agile", it isn't a prescribed process to follow. And saying that you use Agile instead of Scrum but dislike the invasive status meetings isn't actually congruent with the actual definitions of Agile or Scrum.
- seadan83 2y ago
  Agile is meant to be a collaborative process with a user or customer to discover the truly desired objective. Baked into agile is the notion of changing courses. A business that wants a deliverable by a certain date wants a contract - not Agile. How can a route be predictable look with a process that explicitly seeks to regularly change course. We could also get into the theory of whether it is actually possible to say how long software will take at all. Business might bevroutineky asking for the impossible using the wrong methodology for what they think they want
  - jiggawatts 2y ago
    Software with business utility is never "finished" unless the business is finished. Trying to estimate when software is finished is tantamount to asking when the last light will be turned off forever in the warehouse. I keep trying to tell PMs that around the release date is when developers are the most busy, including afterwards. It's not some magic deadline after which developers are no longer needed.
happymellon 2y ago
Its also not for the business. > The Daily Scrum is a 15-minute event for the Developers of the Scrum Team The business doesn't actually need a daily update. They think they do because they dont want to give you the ability to deliver anything.
makeitdouble 2y ago
It's been a long time since I last read it, and it's interesting how times changed. On daily standups, from he manifesto: > Business people and developers must work together daily throughout the project. > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. The "standup" theatrical part isn't in it, but that begs for daily meetings in the same physical place really. Also...no. Verbal communication isn't effective or efficient. It's fast and natural, and perhaps comfortable to many. In our current corporate environment, effectiveness (providing the right info in the right form) and efficiency (minimizing back and forth) will probably be better achieved with documents and open chat with all the parties involved, even if (in particular if?) it means slower throughput and more deliberate communication.

vegetablepotpie 2y ago

There isn’t anything in the agile manifesto on how to do anything. It’s a statement of preferences and values. Business demands process for people in functions to follow. Scrum outlines meetings for programmers to attend, and specific process outputs like user stories to produce and close. Scrum is agile in business because business cannot do agile.

stetrain 2y ago
Right, so when someone says they are doing Agile instead of Scrum but don't like it because of the invasive status meetings, they're probably actually doing some form of Scrum whether or not they realize it.
- bluGill 2y ago
  There are agile processes other than Scrum. Scrum has gotten all the press for some reason, but there are other options. I personally prefer Kanban. The sprint is not a useful deadline for me so I want to ignore it.
  - stetrain 2y ago
    Agreed. But Kanban also often incorporates some of the processes from Scrum like daily standups that aren't prescribed anywhere in Agile. Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.
    - bluGill 2y ago
      Agile is not against processes when needed. Agile is against too much process.
      - JohnFen 2y ago
        And yet, the most process-heavy places I've ever worked at have been "agile" shops.

bluGill 2y ago

The business has a need for a regular status update from everyone. You can call it a standup or not. You can call it not agile, but in the end the business has needs and you cannot ignore those needs. The business needs to know when something will be done as they need to make promises to customers. The business also needs to know when things will be done as that is a proxy for cost - they need to make sure they are not spending more creating a thing than it will deliver (this is a hard problem as some sales will not happen until it is done and there is typically a competitor customers could go with). That is nearly impossible to say how long engineering will take doesn't mean we don't need to know how long it will take!

stetrain 2y ago
Sure. I'm not saying there shouldn't be status updates. I'm just saying that those status updates aren't because they are "doing Agile." There isn't really any such thing as "doing Agile", it isn't a prescribed process to follow. And saying that you use Agile instead of Scrum but dislike the invasive status meetings isn't actually congruent with the actual definitions of Agile or Scrum.
seadan83 2y ago
Agile is meant to be a collaborative process with a user or customer to discover the truly desired objective. Baked into agile is the notion of changing courses. A business that wants a deliverable by a certain date wants a contract - not Agile. How can a route be predictable look with a process that explicitly seeks to regularly change course. We could also get into the theory of whether it is actually possible to say how long software will take at all. Business might bevroutineky asking for the impossible using the wrong methodology for what they think they want
- jiggawatts 2y ago
  Software with business utility is never "finished" unless the business is finished. Trying to estimate when software is finished is tantamount to asking when the last light will be turned off forever in the warehouse. I keep trying to tell PMs that around the release date is when developers are the most busy, including afterwards. It's not some magic deadline after which developers are no longer needed.

happymellon 2y ago

Its also not for the business. > The Daily Scrum is a 15-minute event for the Developers of the Scrum Team The business doesn't actually need a daily update. They think they do because they dont want to give you the ability to deliver anything.

makeitdouble 2y ago

It's been a long time since I last read it, and it's interesting how times changed. On daily standups, from he manifesto: > Business people and developers must work together daily throughout the project. > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. The "standup" theatrical part isn't in it, but that begs for daily meetings in the same physical place really. Also...no. Verbal communication isn't effective or efficient. It's fast and natural, and perhaps comfortable to many. In our current corporate environment, effectiveness (providing the right info in the right form) and efficiency (minimizing back and forth) will probably be better achieved with documents and open chat with all the parties involved, even if (in particular if?) it means slower throughput and more deliberate communication.