Propely done Agile is more to solve the “We have the general idea of what we need but will only know for sure the details of how it will work once the users see it and start playing around with it”.
You still need to upfront know that a wedding is actually needed, but have a process for figuring out and trying out the details of the various elements of it (say, as part of deciding what kind of food will there be for the reception, actually preparing and trying various options) before the whole things actually gets “delivered”.
Agile also works well for environments were software is developed to serve the kind of business which is are constantly changing (for example, certain areas of Finance) or is something totally new being created from the ground up (i.e. many if not most Startups) because the business itself is a sort of a neverending “we’ll figure out what we need and if it works well when we get there and try it out” which matches almost perfectly the fast and scope-limited definition->implementation->feedback cycles of the Agile software development process.
In my experience DoD is too pithy to be a goal. DoD is things like all code checked in, all PBIs done. Sure you’re trying to get your code finished, but your goal is more like add this functionality to the system rather than check in the code and close the PBIs
Isn’t this what Agile* is supposed to solve?
*The actual principles of Agile, not whatever bastardised version your team is doing!
How many story points is it to get to 2nd base?
We’re saving ourselves for marriage, that’s not part of the MVP
Propely done Agile is more to solve the “We have the general idea of what we need but will only know for sure the details of how it will work once the users see it and start playing around with it”.
You still need to upfront know that a wedding is actually needed, but have a process for figuring out and trying out the details of the various elements of it (say, as part of deciding what kind of food will there be for the reception, actually preparing and trying various options) before the whole things actually gets “delivered”.
Agile also works well for environments were software is developed to serve the kind of business which is are constantly changing (for example, certain areas of Finance) or is something totally new being created from the ground up (i.e. many if not most Startups) because the business itself is a sort of a neverending “we’ll figure out what we need and if it works well when we get there and try it out” which matches almost perfectly the fast and scope-limited definition->implementation->feedback cycles of the Agile software development process.
agile is the communism of software developers
In proper agile you don’t have end goal and date set, however management needs end goal and a date.
Doesn’t a definition of done count as a goal?
That’s just how you know when you’ve finished
How is that different from a goal?
Not being argumentative. Just seeing if I’m missing something.
In my experience DoD is too pithy to be a goal. DoD is things like all code checked in, all PBIs done. Sure you’re trying to get your code finished, but your goal is more like add this functionality to the system rather than check in the code and close the PBIs
I see. So dod could be the same across multiple goals.
Also thank you for getting me to think on this, unless I’m challenged I often don’t know how I came to an idea