4 ms·

Just once in my career I'd like to work on a project that resembles the original intent of agile. So far I've had 3 jobs that "did agile" and in each case there

Just once in my career I'd like to work on a project that resembles the original intent of agile. So far I've had 3 jobs that "did agile" and in each case there was a long list of requirements and a fixed deadline many months in the future for each "agile" project. No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint".

superchroma 4y ago
I've had one and it was by necessity as we were building something new and we were a tiny company. It's great when it works.
- shortstuffsushi 4y ago
  This has been my experience as someone who has worked at a variety of large and small companies. Do you have a (generally B2B) product to market, with fixed release increments, and features set by some external marketing / sales team? Your agile is probably going to be "that agile." Are you a small company developing a new product that you don't fully understand yet as you're still developing it? Your agile will probably be closer to the experience people are seeking.
kube-system 4y ago
> No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint". You need a good PM who knows how to handle this for you. I did agile correctly in a large bureaucratic organization because our PM shielded us from those requests, and basically told the business that they could prioritize the requests appropriately in the next sprint planning session. If they showed up and participated, they got to duke it out with the other competing business units about who got priority. If they didn't show up, we told them that their work was not prioritized because they failed to attend the planning session.
- lumost 4y ago
  All this really means is either - You can only ever work on projects which are finished in one sprint. - You have no idea how, when, or even why the big initiative you're working on will finish. It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? what happens when a multi-sprint project becomes a multi-year forever project? You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. At best, the absence of autonomy for an individual in a scrum team might be the point of the whole process.
  - user_named 4y ago
    Your first point is exactly true. We design concepts with certain goals in mind, then that gets cut down into something that takes one or two sprints of work "to see the results", which never come because it does not even cover mvp use cases. Then the rest never gets built. Absolutely lack in long-term thinking, goals and vision.
  - kube-system 4y ago
    If you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks. > It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? Someone has to own the project, and have the final say on priority. If the project is at risk due to shifting priorities, you need to escalate this to them for a final decision. > You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. If you have everything in your backlog, you can judge velocity to come up with an estimated timeline given all of the assumption at the current state. This isn’t a promise, it’s an estimate. When the business shows up to sprint planning and sprinkles around new ideas for high priority tasks, you always remind them that this means deprioritizing other tasks which will affect timeline. > what happens when a multi-sprint project becomes a multi-year forever project? Yes, at the end of the project you will likely have done something very different than what you originally put in your backlog, because the business will have changed their minds 100 times. This is the point! The point is to track close to building what they want, not to build what they wanted 8 months ago.
- BLKNSLVR 4y ago
  This is true for any management role: protect those under you from the ridiculousness coming from above. Filter out the crazy (which can be the entirety) and then pass down to the team the best way you can figure to move things forward. I managed to do this for a while. It's hard on the ol' mental health though.
- theshrike79 4y ago
  This is exactly the job of the Scrum Master in the Agile process. <insert meme of soldier protecting sleeping child>[0] The SM is supposed to be part of the team, not part of management. [0] https://pics.me.me/the-silent-protector-sales-department-managers-scrum-master-customers-developers-61821422.png https://pics.me.me/the-silent-protector-sales-department-man...
  - kube-system 4y ago
    Yeah, in theory you’re technically correct, but in my experience, because “scrum masters are on the team” they’re usually a developer with little political or managerial power. I prefer having the scrum master and the PM on the team. As a pair they can navigate technical challenges and business politics effectively.
woutr_be 4y ago
In one company that proclaimed to do “agile”, our release was suddenly halted by the business, because they came up with some new requirements. These were regulatory requirements they of course long knew about, but only now decided to throw at us, because “agile” and it’s an ongoing product. All good and well, except that they now demanded the product to be released within two weeks, because that’s when the marketing campaign went live. Of course, our PM and scrum master, just went along and put us all into a room, to estimate and figure out how we could deliver. All our estimates were proclaimed wrong, and we had to estimate again, eventually devs just gave a number to make it fit within the two weeks. Needless to stay, the product did not launch, and the developers got blamed for not being flexible enough. That’s how agile works in big companies, use agile as a term for everything wen it fits, use it as a way to blame others. Scrum masters are just there to pass along communication from the business, and absorb complains from developers. It’s just another one-way street of communication.
- the_af 4y ago
  > All our estimates were proclaimed wrong I've seen something like this happen, and I must wonder. The only ones that can give an estimation are the people who will actually do the work. This estimation will likely be also wrong, but it's their job and their estimation. How can anyone else dispute it? Very tempted to reply "well, how about you do it in two weeks then?". I never do, because I want to keep my job. And nobody is ever punished for missing deadlines, anyway.
  - irrational 4y ago
    They dispute it because they assume that developers are padding their estimates. You know, it will probably take 2 weeks, so double it and then double it again.
    - ahtihn 4y ago
      If developers consistently miss deadlines and the business consistently pushes back on estimates, maybe the original estimates weren't padded? This should be fairly easy to communicate to the business people.
eyelidlessness 4y ago
I’ve worked on three teams which have to some degree been agile in spirit. The first didn’t really have a planning philosophy at all, and was mostly agile in spirit by virtue of that other than when crunch time got really chaotic and stressful. The next took a minor opportunitistic rebellion to achieve, in the midst of a significant culling of management and a sympathetic view from one of the remaining leadership. My current job is thematically between the two and surprisingly adaptable even while being conscious of pressures. All of these have been unusual work environments so I’m not sure I have reproducible insight to offer (though the second case probably is more reproducible than not at all, and I highly encourage anyone with the opportunity to throw down and choose your own planning adventure to coordinate with your team and see what shakes out; you have nothing to lose but your estimation poker hand).
de6u99er 4y ago
There's nothing wrong with a full backlog. And also not with a deadline defining when something should be available. Sometimes such deadlines come from third parties (e.g. retirement of an already deprecated API version), a larger corporate program that requires multiple projects to deliver in sync, or opportunities based on external factors where marketing is already concentrating on a specific date, ... My approach is the MVP way, where the team delivers everything that is necessary to meet the customers goals. All the bells an whistles can be qdded once those goals are met. If the goal can't be met within the given timeframe, then it's a problem of unrealistic expectations. But most of the times we have met the deadline while otheres with their bloated waterfall projects were late.

superchroma 4y ago

I've had one and it was by necessity as we were building something new and we were a tiny company. It's great when it works.

shortstuffsushi 4y ago
This has been my experience as someone who has worked at a variety of large and small companies. Do you have a (generally B2B) product to market, with fixed release increments, and features set by some external marketing / sales team? Your agile is probably going to be "that agile." Are you a small company developing a new product that you don't fully understand yet as you're still developing it? Your agile will probably be closer to the experience people are seeking.

kube-system 4y ago

> No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint". You need a good PM who knows how to handle this for you. I did agile correctly in a large bureaucratic organization because our PM shielded us from those requests, and basically told the business that they could prioritize the requests appropriately in the next sprint planning session. If they showed up and participated, they got to duke it out with the other competing business units about who got priority. If they didn't show up, we told them that their work was not prioritized because they failed to attend the planning session.

lumost 4y ago
All this really means is either - You can only ever work on projects which are finished in one sprint. - You have no idea how, when, or even why the big initiative you're working on will finish. It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? what happens when a multi-sprint project becomes a multi-year forever project? You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. At best, the absence of autonomy for an individual in a scrum team might be the point of the whole process.
- user_named 4y ago
  Your first point is exactly true. We design concepts with certain goals in mind, then that gets cut down into something that takes one or two sprints of work "to see the results", which never come because it does not even cover mvp use cases. Then the rest never gets built. Absolutely lack in long-term thinking, goals and vision.
- kube-system 4y ago
  If you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks. > It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? Someone has to own the project, and have the final say on priority. If the project is at risk due to shifting priorities, you need to escalate this to them for a final decision. > You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. If you have everything in your backlog, you can judge velocity to come up with an estimated timeline given all of the assumption at the current state. This isn’t a promise, it’s an estimate. When the business shows up to sprint planning and sprinkles around new ideas for high priority tasks, you always remind them that this means deprioritizing other tasks which will affect timeline. > what happens when a multi-sprint project becomes a multi-year forever project? Yes, at the end of the project you will likely have done something very different than what you originally put in your backlog, because the business will have changed their minds 100 times. This is the point! The point is to track close to building what they want, not to build what they wanted 8 months ago.
BLKNSLVR 4y ago
This is true for any management role: protect those under you from the ridiculousness coming from above. Filter out the crazy (which can be the entirety) and then pass down to the team the best way you can figure to move things forward. I managed to do this for a while. It's hard on the ol' mental health though.
theshrike79 4y ago
This is exactly the job of the Scrum Master in the Agile process. <insert meme of soldier protecting sleeping child>[0] The SM is supposed to be part of the team, not part of management. [0] https://pics.me.me/the-silent-protector-sales-department-managers-scrum-master-customers-developers-61821422.png https://pics.me.me/the-silent-protector-sales-department-man...
- kube-system 4y ago
  Yeah, in theory you’re technically correct, but in my experience, because “scrum masters are on the team” they’re usually a developer with little political or managerial power. I prefer having the scrum master and the PM on the team. As a pair they can navigate technical challenges and business politics effectively.

woutr_be 4y ago

In one company that proclaimed to do “agile”, our release was suddenly halted by the business, because they came up with some new requirements. These were regulatory requirements they of course long knew about, but only now decided to throw at us, because “agile” and it’s an ongoing product. All good and well, except that they now demanded the product to be released within two weeks, because that’s when the marketing campaign went live. Of course, our PM and scrum master, just went along and put us all into a room, to estimate and figure out how we could deliver. All our estimates were proclaimed wrong, and we had to estimate again, eventually devs just gave a number to make it fit within the two weeks. Needless to stay, the product did not launch, and the developers got blamed for not being flexible enough. That’s how agile works in big companies, use agile as a term for everything wen it fits, use it as a way to blame others. Scrum masters are just there to pass along communication from the business, and absorb complains from developers. It’s just another one-way street of communication.

the_af 4y ago
> All our estimates were proclaimed wrong I've seen something like this happen, and I must wonder. The only ones that can give an estimation are the people who will actually do the work. This estimation will likely be also wrong, but it's their job and their estimation. How can anyone else dispute it? Very tempted to reply "well, how about you do it in two weeks then?". I never do, because I want to keep my job. And nobody is ever punished for missing deadlines, anyway.
- irrational 4y ago
  They dispute it because they assume that developers are padding their estimates. You know, it will probably take 2 weeks, so double it and then double it again.
  - ahtihn 4y ago
    If developers consistently miss deadlines and the business consistently pushes back on estimates, maybe the original estimates weren't padded? This should be fairly easy to communicate to the business people.

eyelidlessness 4y ago

I’ve worked on three teams which have to some degree been agile in spirit. The first didn’t really have a planning philosophy at all, and was mostly agile in spirit by virtue of that other than when crunch time got really chaotic and stressful. The next took a minor opportunitistic rebellion to achieve, in the midst of a significant culling of management and a sympathetic view from one of the remaining leadership. My current job is thematically between the two and surprisingly adaptable even while being conscious of pressures. All of these have been unusual work environments so I’m not sure I have reproducible insight to offer (though the second case probably is more reproducible than not at all, and I highly encourage anyone with the opportunity to throw down and choose your own planning adventure to coordinate with your team and see what shakes out; you have nothing to lose but your estimation poker hand).

de6u99er 4y ago

There's nothing wrong with a full backlog. And also not with a deadline defining when something should be available. Sometimes such deadlines come from third parties (e.g. retirement of an already deprecated API version), a larger corporate program that requires multiple projects to deliver in sync, or opportunities based on external factors where marketing is already concentrating on a specific date, ... My approach is the MVP way, where the team delivers everything that is necessary to meet the customers goals. All the bells an whistles can be qdded once those goals are met. If the goal can't be met within the given timeframe, then it's a problem of unrealistic expectations. But most of the times we have met the deadline while otheres with their bloated waterfall projects were late.