9 ms·

Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of w

Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration." That caused so many problems with tech debt. Stories began to take longer due to the increasingly large and discombobulated code base, but the expectation was that we continue to deliver the same number of story points each sprint. Then we got blasted for losing pace. "Why are you under-performing? We are just adding little features. You've already implemented this button on another form before? Why does it take longer the second time? You already know how to do it!" It became absurd and no one could hear or understand what was happening was easily predictable and in fact -- was predicted by several members of the team many months prior. When the project management was informed of these predictions now having come true, the development team was accused of intentionally causing the delays.

xyzzy_plugh 7y ago
This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!
- forinti 7y ago
  Best PM I ever had dropped by every week or so to ask if we needed anything.
  - allthecybers 7y ago
    That's what the best ones do.
- mixmastamyk 7y ago
  > "How could it possibly take that long? How do you not know how long it will take?" Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.: "How long would it take for you to earn a green belt in karate?" "Hmm, what does a green belt entail?" "Exactly, you don't even know what you don't know, yet."
  - saagarjha 7y ago
    > A witty retort may be in order I don't think this will score you a lot of points.
    - coldtea 7y ago
      Depends. Are we talking self-esteem/dignity points, or good doggie/loyalty points?
      - reinhardt 7y ago
        I'd guess career-progression points, or even keep-getting-a-paycheck points at worst.
        deleted 7y ago
        [deleted]
        mixmastamyk 7y ago
        This low-stakes exchange won't affect much, it's about putting Mr. Incomp in his place. Remember it's a PM we're talking about, not "the Boss."
  - xyzzy_plugh 7y ago
    They did, and I replied "We don't know because we've never done this before, and we can only compare to the most similar work we've done, and any existing data." Before I could say more, they I interrupted: "You have to know, it's your job, or you don't know what your doing," or something along those lines. It was the most heated I've felt. I know what I'd reply with today, but I was younger and more naive then.
- matwood 7y ago
  In these situations I shift the conversation to what is the PM really after. I explain that I can tell them any estimate they want (or they can make it up on their own - no need to even discuss), but does that really do them any good when it is missed? There is usually some pushback at first, but when items are delivered within estimate a few times in a row they realize it's better to take whatever hit up front than it is to miss and adjust. Also, someone asking how could something take so long is not a belittling question. I don't see any problem with either question.
spronkey 7y ago
Personally I believe this is one of the major gaps in Scrum, and there is no prescripted way to solve this problem. XP's focus on technical aspects is much better in this regard, but the possibility of runaway technical debt still exists. There are so many places where this can sneak in and become an issue, too: - The development team can groupthink, underestimate and/or fail to account for technical debt payback in planning poker. They may estimate the cost for the new feature, but not include any time for refactoring to keep the codebase healthy - The Scrum Master may not shield the development team from pressure to deliver coming from the product owner, which may cause the team to cut the above corners - Codebase health may be split out from vertical stories into its own tasks that get deprioritised by the product owner - Even if the development team identifies the need for codebase health, this may not be communicated back to the product owner in a way that makes business sense ("but we can still get this feature out the door quickly and fix the mess later, right?" - yes, once or twice, but the downside is a slowing of velocity) - Even if the team started well with ground rules the Scrum Master is supposed to enforce surrounding technical quality, the Scrum Master may not be effective in enforcing the process - either because they lack authority or because they lack the ability or knowledge to do so Among several others. In your situation, the big red flag is that the team predicted the issue many months prior. The process has failed to extract that information from the team members and deliver a consensus between them and the product owner. Though ultimately, as with any project, if the product owner has more organisational authority than the development team and chooses to exert this authority, no process will be able to save you.
alexashka 7y ago
It's easy to say something is shit. The tricky bit is having a solution and implementing it. Having something well thought out is hard work. Is hard work rewarded? Is initiative to even try rewarded? I'd say the answer is no. The answer becomes yes in small teams that are given time, freedom and resources, or in times of crisis (same thing as small team really, minus the time bit), as far as I can tell. Otherwise, most people's natural tendency (including me) is to phone it in. We'd be wise to let people in software development and many other professions that are not manual labor, to switch careers after 30-35 if they haven't done anything worthwhile by then. Working with people who have to phone it in for the next 30 years and know it is modern day hell for anyone with an iota of ability. It's permanent compromise and insincerity, or being an outcast that's temporarily tolerated for doing 5-10x the work of the person next to you.
Bombthecat 7y ago
Because Tech debt and I reading messy code base never happened in waterfall... The problem is always : features and customer request over bug fixing or design fixes. The system, project type does not matter. That's why some PO recommend 10 percent allocation to devops / ops, 10 percent to improving code base . And "no bug survives the Sprint" philosophy. And what is left,is you next feature or customer request.
hnlmorg 7y ago
For every example of scrum operating badly there are examples of scrum working well. The common denominator in all of those situations - good and bad - is the project and middle/upper management.
- etripe 7y ago
  In business process analysis, when a process is dependent on individual people, you don't have a mature process but an ad hoc process. In other words, Scrum methodology in itself is not mature as a methodology and depends on individual fiat, just like any project that doesn't have any process at all. The only tangible benefit to Scrum might be paying lip service to development departments while firmly retaining the status quo.
  - hnlmorg 7y ago
    Scrum is no more or less dependant on individual people as any other methodology. The rest of your post is just warping your initial conjecture to arrive at conclusions you'd already decided upon. I neither agree with those conclusions nor the chain of twisted logic you used to arrive that. I'm not going to stand on a soapbox and sing for the glory of scrums. People - like yourself it seems - can get very tribal when talking about such things. Which is as weird to read as it is pointless for you to argue. In my experience leading different teams using different methodologies, the thing that really makes the big noticeable impact is people and not methodologies. If you work in a blame culture or have colleagues in your team who don't follow process - then whatever process you put in place will be undermined at every opportunity regardless of it's methodology. However if you work in an environment where people respect one another and want to collaborate in getting work done, then you pick a methodology that works best for the day to day work (eg project work or support operations) and for the way people like their work organised. All the rest of the arguments are superfluous.
- matwood 7y ago
  > good and bad - is the project and middle/upper management. Yep. People do not realize that the whole company has to adopt agile/scrum for it to work. It's a shift that many companies can not or will not make. They are tied to fixed deadline, fixed scope for various reasons.

xyzzy_plugh 7y ago

This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!

forinti 7y ago
Best PM I ever had dropped by every week or so to ask if we needed anything.
- allthecybers 7y ago
  That's what the best ones do.
mixmastamyk 7y ago
> "How could it possibly take that long? How do you not know how long it will take?" Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.: "How long would it take for you to earn a green belt in karate?" "Hmm, what does a green belt entail?" "Exactly, you don't even know what you don't know, yet."
- saagarjha 7y ago
  > A witty retort may be in order I don't think this will score you a lot of points.
  - coldtea 7y ago
    Depends. Are we talking self-esteem/dignity points, or good doggie/loyalty points?
    - reinhardt 7y ago
      I'd guess career-progression points, or even keep-getting-a-paycheck points at worst.
      - deleted 7y ago
        [deleted]
      - mixmastamyk 7y ago
        This low-stakes exchange won't affect much, it's about putting Mr. Incomp in his place. Remember it's a PM we're talking about, not "the Boss."
- xyzzy_plugh 7y ago
  They did, and I replied "We don't know because we've never done this before, and we can only compare to the most similar work we've done, and any existing data." Before I could say more, they I interrupted: "You have to know, it's your job, or you don't know what your doing," or something along those lines. It was the most heated I've felt. I know what I'd reply with today, but I was younger and more naive then.
matwood 7y ago
In these situations I shift the conversation to what is the PM really after. I explain that I can tell them any estimate they want (or they can make it up on their own - no need to even discuss), but does that really do them any good when it is missed? There is usually some pushback at first, but when items are delivered within estimate a few times in a row they realize it's better to take whatever hit up front than it is to miss and adjust. Also, someone asking how could something take so long is not a belittling question. I don't see any problem with either question.

spronkey 7y ago

Personally I believe this is one of the major gaps in Scrum, and there is no prescripted way to solve this problem. XP's focus on technical aspects is much better in this regard, but the possibility of runaway technical debt still exists. There are so many places where this can sneak in and become an issue, too: - The development team can groupthink, underestimate and/or fail to account for technical debt payback in planning poker. They may estimate the cost for the new feature, but not include any time for refactoring to keep the codebase healthy - The Scrum Master may not shield the development team from pressure to deliver coming from the product owner, which may cause the team to cut the above corners - Codebase health may be split out from vertical stories into its own tasks that get deprioritised by the product owner - Even if the development team identifies the need for codebase health, this may not be communicated back to the product owner in a way that makes business sense ("but we can still get this feature out the door quickly and fix the mess later, right?" - yes, once or twice, but the downside is a slowing of velocity) - Even if the team started well with ground rules the Scrum Master is supposed to enforce surrounding technical quality, the Scrum Master may not be effective in enforcing the process - either because they lack authority or because they lack the ability or knowledge to do so Among several others. In your situation, the big red flag is that the team predicted the issue many months prior. The process has failed to extract that information from the team members and deliver a consensus between them and the product owner. Though ultimately, as with any project, if the product owner has more organisational authority than the development team and chooses to exert this authority, no process will be able to save you.

alexashka 7y ago

It's easy to say something is shit. The tricky bit is having a solution and implementing it. Having something well thought out is hard work. Is hard work rewarded? Is initiative to even try rewarded? I'd say the answer is no. The answer becomes yes in small teams that are given time, freedom and resources, or in times of crisis (same thing as small team really, minus the time bit), as far as I can tell. Otherwise, most people's natural tendency (including me) is to phone it in. We'd be wise to let people in software development and many other professions that are not manual labor, to switch careers after 30-35 if they haven't done anything worthwhile by then. Working with people who have to phone it in for the next 30 years and know it is modern day hell for anyone with an iota of ability. It's permanent compromise and insincerity, or being an outcast that's temporarily tolerated for doing 5-10x the work of the person next to you.

Bombthecat 7y ago

Because Tech debt and I reading messy code base never happened in waterfall... The problem is always : features and customer request over bug fixing or design fixes. The system, project type does not matter. That's why some PO recommend 10 percent allocation to devops / ops, 10 percent to improving code base . And "no bug survives the Sprint" philosophy. And what is left,is you next feature or customer request.

hnlmorg 7y ago

For every example of scrum operating badly there are examples of scrum working well. The common denominator in all of those situations - good and bad - is the project and middle/upper management.

etripe 7y ago
In business process analysis, when a process is dependent on individual people, you don't have a mature process but an ad hoc process. In other words, Scrum methodology in itself is not mature as a methodology and depends on individual fiat, just like any project that doesn't have any process at all. The only tangible benefit to Scrum might be paying lip service to development departments while firmly retaining the status quo.
- hnlmorg 7y ago
  Scrum is no more or less dependant on individual people as any other methodology. The rest of your post is just warping your initial conjecture to arrive at conclusions you'd already decided upon. I neither agree with those conclusions nor the chain of twisted logic you used to arrive that. I'm not going to stand on a soapbox and sing for the glory of scrums. People - like yourself it seems - can get very tribal when talking about such things. Which is as weird to read as it is pointless for you to argue. In my experience leading different teams using different methodologies, the thing that really makes the big noticeable impact is people and not methodologies. If you work in a blame culture or have colleagues in your team who don't follow process - then whatever process you put in place will be undermined at every opportunity regardless of it's methodology. However if you work in an environment where people respect one another and want to collaborate in getting work done, then you pick a methodology that works best for the day to day work (eg project work or support operations) and for the way people like their work organised. All the rest of the arguments are superfluous.
matwood 7y ago
> good and bad - is the project and middle/upper management. Yep. People do not realize that the whole company has to adopt agile/scrum for it to work. It's a shift that many companies can not or will not make. They are tied to fixed deadline, fixed scope for various reasons.