6 ms·

This is why I still like Agile and Scrum, as much as other devs might hate it. “Yeah I want REAL deliverables after the first or second week”. Keeps me honest.

by ratww 4y ago

This is why I still like Agile and Scrum, as much as other devs might hate it. “Yeah I want REAL deliverables after the first or second week”. Keeps me honest. And will keep me from working with architecture astronauts don’t really deliver anything but hot air and build ultra-extensible structures that are actually impossible to extend beyond the fantasy world of their maker. Or the equivalent for designers.

jokethrowaway 4y ago
I'd bet you a large sum of money this agency used Agile. Agile is not a guarantee of deliverables you care about. There is a lot of useless stuff you can deliver.
- protonbob 4y ago
  Well, if you are doing it correctly, you are supposed to make a sprint goal of a deliverable that has value.
- ElectricalUnion 4y ago
  Well, waterfall used to not deliver anything at all. Not delivering anything is pretty useless.
  - lelanthran 4y ago
    > Well, waterfall used to not deliver anything at all. Not delivering anything is pretty useless. That's pretty much untrue; had this project been a waterfall project then: a) The devs would not have gotten paid until they hit particular milestones, b) The deliverables would have been scoped upfront, c) The agency would have eaten the cost of developing useless things, not the customer. Because this was obviously an agile/Agile project: a) The payment milestones were not specified upfront, b) The devliverables remained unscoped until feedback was needed (which was well into the development phase), c) The client eats the cost of developers time, whether or not milestones are hit.
- lmm 4y ago
  > I'd bet you a large sum of money this agency used Agile. They probably said the word "agile" a lot and then continued doing something else, that seems to be the usual pattern. > Agile is not a guarantee of deliverables you care about. There is a lot of useless stuff you can deliver. Which is why it's the product owner's responsibility to prioritise.
  - josefx 4y ago
    > Which is why it's the product owner's responsibility to prioritise. The company didn't seem to have issues prioritizing the authors tasks into no mans land. So they seem to have that part down great already. However I find the consistent two week deliveries early on a bit disturbing, in my experience two weeks is exactly one sprint and fixing deliverables to that time window means that you can't really do any agile planing with it, your team just has to accept that this work has to be done and can't give random work that seems to pop up every now and then the attention it deserves. To be really agile and allow your sprint planing to reflect that you shouldn't promise anything in time spans less than two months.
    - lmm 4y ago
      The whole point of agile is that you deliver something every two weeks. Whatever it is you're suggesting, it's not agile.
      - josefx 4y ago
        Delivering "something" and delivering specific items at a fixed rate are different things.
        lmm 4y ago
        Agile never promised to do the latter (and I've never seen a methodology that succeded at it in a way that was useful in practice).
- chiefalchemist 4y ago
  > I'd bet you a large sum of money this agency used Agile. Probably not. Larger relatively successful design / marketing agencies are - based on my experience - poorly run, poorly managed, and poorly led. This gets exasperated by high turn-over (read: good people leave, dead weight stays behind). Training, etc.? Not a priority. Revenue, it's all about revenue. They're "creatives", not business problem-solver types and presume mess and excessive friction are unavoidable.
- ratww 4y ago
  Even if they're using agile, it's up to the customer to ask for deliverables that they care about if they want them. Of course it would be much better if the agency were honest, but if for seven months the deliverables were only "promises", then it's definitely not agile...
doctor_eval 4y ago
Agile and scrum are in practice such nebulous terms that while I don’t doubt that you have had good experience with the particular version of these concepts that you yourself use, the agency could well consider itself to be using the same concepts - yet here we are. The older I get, the more I come to understand that the problem with projects is people, not methodology. 30% of IT projects still fail, despite “agile” now being widespread. The first value of the agile manifesto is “Individuals and interactions over processes and tools”. Unfortunately, most implementations throw this one out first.
- abakker 4y ago
  only 30%? I'd have guessed that most IT projects at least fail to achieve goals if they don't crater completely. the bigger the projects, the more they resemble interplanetary collisions.
  - doctor_eval 4y ago
    Well, that’s according to the PMI. Finding the link will simply lower my level of happiness for the day, but you should be able to Google it (sorry). The thing is that as far as I can tell, “success” is measured post-hoc, so all sorts of shenanigans might have taken place in order to determine that a project was “successful”. Having worked with my fair share of corporate project leaders, I’m quite certain that the actual number of failed projects would be much higher if measured by the original criteria used to justify the project in the first place.
  - pmontra 4y ago
    Helmuth van Moltke (1880): "No plan of operations reaches with any certainty beyond the first encounter with the enemy's main force." It applies to software projects too, especially large ones. The enemy is the real world (or our lack of understanding of the real world.) If we look at the original requirements every single project is a failure. If we look at the strategic goals and keep track of all trade offs maybe 30% is a fair guesstimate.
- lelanthran 4y ago
  > 30% of IT projects still fail, despite “agile” now being widespread. That's a very optimistic statistic, unless "fail" is defined to be something other than "the opposite of success". IOW, a fail is any project that goes over time, over budget or delivers under scope. If you're defining success as "well, we delivered eventually, and we delivered 80% of the requirements, and it only went over budget by 20%", then, sure, only 30% of IT projects "fail".
danjac 4y ago
Scrum is really for low-trust environments where management fundamentally don't trust the developers to deliver - whether because the developers aren't experienced, not very good at self-management, or too easily distracted by shiny things, or because you're an archetypal MBA type who distrusts any underling who might be smarter than you. If you trust your developers (whether in-house or contractors) to do the job you can pretty much let them manage themselves with whatever kanban-ish system that works for them. If you don't, you have a ready methodology that gives you meetings upon meetings and two week deliverables and every little thing broken down to the smallest unit under the guise of "empowerment".
- Cthulhu_ 4y ago
  While this is definitely true (I've worked in both kinds of environments), I think the scrum process isn't for low-trust per se, but for managing expectations, especially if you have a larger IT organization. Your direct product owner needs a way to determine how long the development of features can be done, so that they can coordinate and manage expectations with other product owners and other stakeholders (management, customers, etc). I see it as a way to abstract away the individual developers and dev work. And you probably know that there's a BIG portion of developers who aren't as self-organized or disciplined. You mentioned the shiny things distractions, I think that was a factor in the original post. The other being mismanagement on the agency's side, where they allowed their designers to go out of scope. And I'm not even convinced it's mismanagement, because they turned a $7K project into a $46K project, a 6.5x increase in their revenue off of some small side project.
- ratww 4y ago
  That's not entirely wrong, but Scrum is also great for high-trust environments where you want to have deliverables from sprint one. And it is actually more useful when things are flipped, and the team doesn't really trust the client/customer/manager. Which is often what happens more frequently. But you're totally right that Scrum can get kinda heavy on the meetings side. Which tends to be the rule, not the exception. The only times I had this exception it was when we had a technical person working on the requirements, though. No designer or product owner making nebulous Jira tickets.
deleted 4y ago
[deleted]

by ratww 4y ago

jokethrowaway 4y ago

I'd bet you a large sum of money this agency used Agile. Agile is not a guarantee of deliverables you care about. There is a lot of useless stuff you can deliver.

protonbob 4y ago
Well, if you are doing it correctly, you are supposed to make a sprint goal of a deliverable that has value.
ElectricalUnion 4y ago
Well, waterfall used to not deliver anything at all. Not delivering anything is pretty useless.
- lelanthran 4y ago
  > Well, waterfall used to not deliver anything at all. Not delivering anything is pretty useless. That's pretty much untrue; had this project been a waterfall project then: a) The devs would not have gotten paid until they hit particular milestones, b) The deliverables would have been scoped upfront, c) The agency would have eaten the cost of developing useless things, not the customer. Because this was obviously an agile/Agile project: a) The payment milestones were not specified upfront, b) The devliverables remained unscoped until feedback was needed (which was well into the development phase), c) The client eats the cost of developers time, whether or not milestones are hit.
lmm 4y ago
> I'd bet you a large sum of money this agency used Agile. They probably said the word "agile" a lot and then continued doing something else, that seems to be the usual pattern. > Agile is not a guarantee of deliverables you care about. There is a lot of useless stuff you can deliver. Which is why it's the product owner's responsibility to prioritise.
- josefx 4y ago
  > Which is why it's the product owner's responsibility to prioritise. The company didn't seem to have issues prioritizing the authors tasks into no mans land. So they seem to have that part down great already. However I find the consistent two week deliveries early on a bit disturbing, in my experience two weeks is exactly one sprint and fixing deliverables to that time window means that you can't really do any agile planing with it, your team just has to accept that this work has to be done and can't give random work that seems to pop up every now and then the attention it deserves. To be really agile and allow your sprint planing to reflect that you shouldn't promise anything in time spans less than two months.
  - lmm 4y ago
    The whole point of agile is that you deliver something every two weeks. Whatever it is you're suggesting, it's not agile.
    - josefx 4y ago
      Delivering "something" and delivering specific items at a fixed rate are different things.
      - lmm 4y ago
        Agile never promised to do the latter (and I've never seen a methodology that succeded at it in a way that was useful in practice).
chiefalchemist 4y ago
> I'd bet you a large sum of money this agency used Agile. Probably not. Larger relatively successful design / marketing agencies are - based on my experience - poorly run, poorly managed, and poorly led. This gets exasperated by high turn-over (read: good people leave, dead weight stays behind). Training, etc.? Not a priority. Revenue, it's all about revenue. They're "creatives", not business problem-solver types and presume mess and excessive friction are unavoidable.
ratww 4y ago
Even if they're using agile, it's up to the customer to ask for deliverables that they care about if they want them. Of course it would be much better if the agency were honest, but if for seven months the deliverables were only "promises", then it's definitely not agile...

doctor_eval 4y ago

Agile and scrum are in practice such nebulous terms that while I don’t doubt that you have had good experience with the particular version of these concepts that you yourself use, the agency could well consider itself to be using the same concepts - yet here we are. The older I get, the more I come to understand that the problem with projects is people, not methodology. 30% of IT projects still fail, despite “agile” now being widespread. The first value of the agile manifesto is “Individuals and interactions over processes and tools”. Unfortunately, most implementations throw this one out first.

abakker 4y ago
only 30%? I'd have guessed that most IT projects at least fail to achieve goals if they don't crater completely. the bigger the projects, the more they resemble interplanetary collisions.
- doctor_eval 4y ago
  Well, that’s according to the PMI. Finding the link will simply lower my level of happiness for the day, but you should be able to Google it (sorry). The thing is that as far as I can tell, “success” is measured post-hoc, so all sorts of shenanigans might have taken place in order to determine that a project was “successful”. Having worked with my fair share of corporate project leaders, I’m quite certain that the actual number of failed projects would be much higher if measured by the original criteria used to justify the project in the first place.
- pmontra 4y ago
  Helmuth van Moltke (1880): "No plan of operations reaches with any certainty beyond the first encounter with the enemy's main force." It applies to software projects too, especially large ones. The enemy is the real world (or our lack of understanding of the real world.) If we look at the original requirements every single project is a failure. If we look at the strategic goals and keep track of all trade offs maybe 30% is a fair guesstimate.
lelanthran 4y ago
> 30% of IT projects still fail, despite “agile” now being widespread. That's a very optimistic statistic, unless "fail" is defined to be something other than "the opposite of success". IOW, a fail is any project that goes over time, over budget or delivers under scope. If you're defining success as "well, we delivered eventually, and we delivered 80% of the requirements, and it only went over budget by 20%", then, sure, only 30% of IT projects "fail".

danjac 4y ago

Scrum is really for low-trust environments where management fundamentally don't trust the developers to deliver - whether because the developers aren't experienced, not very good at self-management, or too easily distracted by shiny things, or because you're an archetypal MBA type who distrusts any underling who might be smarter than you. If you trust your developers (whether in-house or contractors) to do the job you can pretty much let them manage themselves with whatever kanban-ish system that works for them. If you don't, you have a ready methodology that gives you meetings upon meetings and two week deliverables and every little thing broken down to the smallest unit under the guise of "empowerment".

Cthulhu_ 4y ago
While this is definitely true (I've worked in both kinds of environments), I think the scrum process isn't for low-trust per se, but for managing expectations, especially if you have a larger IT organization. Your direct product owner needs a way to determine how long the development of features can be done, so that they can coordinate and manage expectations with other product owners and other stakeholders (management, customers, etc). I see it as a way to abstract away the individual developers and dev work. And you probably know that there's a BIG portion of developers who aren't as self-organized or disciplined. You mentioned the shiny things distractions, I think that was a factor in the original post. The other being mismanagement on the agency's side, where they allowed their designers to go out of scope. And I'm not even convinced it's mismanagement, because they turned a $7K project into a $46K project, a 6.5x increase in their revenue off of some small side project.
ratww 4y ago
That's not entirely wrong, but Scrum is also great for high-trust environments where you want to have deliverables from sprint one. And it is actually more useful when things are flipped, and the team doesn't really trust the client/customer/manager. Which is often what happens more frequently. But you're totally right that Scrum can get kinda heavy on the meetings side. Which tends to be the rule, not the exception. The only times I had this exception it was when we had a technical person working on the requirements, though. No designer or product owner making nebulous Jira tickets.

deleted 4y ago

[deleted]