5 ms·

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." Its just a methodology in the end. It can help keep those that tend to have wa

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." Its just a methodology in the end. It can help keep those that tend to have wandering minds focused, but for high performing teams the overhead slows them down. The assumption of a standard programmer is just never a reality as well. I actually saw a startup try to go full religious agile and only hire "full stack" developers to try to homogenize them so that they would fit the agile mold better. It didn't seem to work very well, people are people and naturally gravitate towards data modeling, or UI, etc.

dagw 8y ago
My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." And honestly that is all that most companies actually want/need. Most teams are mediocre and most projects only need a mediocre result. Getting something as good as a mediocre results out of your mediocre teams would be a massive improvement for a lot of place.
- s73v3r_ 8y ago
  To be honest, that wouldn't be a problem if more companies were up front about it. But every company out there has this idea that they have to hire "the best".
  - dagw 8y ago
    every company out there has this idea that they have to hire "the best". Maybe in Silicone Valley, but most companies are happy if they can just find a programmer that knows how to program.
- jon-wood 8y ago
  I would rephrase it from "mediocre results" to "good enough results" - not everything needs to be a work of art. Especially in the startup world, where there's never enough people to go round, there's a huge value in knowing when you've done enough that the project you're working on is no longer the thing that'll deliver the most value. What agile does when executed right is to fully embrace that, and wrap it in a process that ensures that when you reach that point you're able to finish the current iteration, ship what you've got, and move on leaving things in a good enough state. For me that's the core of agile, and in my experience at least you can't pull that off with a mediocre team. You need a team where at least some members have the experience and the pragmatism to know the difference between delivering a minimum viable product and cutting corners in a way that'll hurt in the future.
  - yebyen 8y ago
    When I learned about the concept of "just barely good enough" I was thrilled by it. Lots of people been using the expression "good enough" and to me it feels like a defeatist idea. "They did their best! It's good enough, isn't it?" http://agilemodeling.com/essays/barelyGoodEnough.html http://agilemodeling.com/essays/barelyGoodEnough.html Given the constraints of the estimate we've made for a story that could really go much longer, except that we've only allocated two days... I think the problem you're hinting at is that different people have different ideas of what the Minimum Viable Product should look like. Accordingly, on my team where we're all under-trained with respect to Project Management and mostly just making this shit up as we go along, we've identified several other points on the curve. It's suggested that one should make some nominal efforts to identify, and stop for a sniff along the way to JBGE: "that's definitely not good enough, try again" "I'll know it when I see it, but I'm sure that isn't it" "kinda-sorta good enough" "that's nearly good enough, except for this one thing..." Identifying some of these points along the way (and making sure you notice when you've arrived at them) in my opinion is a great way to help ensure you're not actually aiming for points somewhere deep on the wrong side of the curve. The mediocre team also may have trouble getting to Just Barely Good Enough because of overshooting. But in my experience that's usually not the problem. Nobody is working far past JBGE into the wee hours of the "OMG this is too much, I love it but how long did it actually take?" If anything, the feature has to be shelved or scrapped, or handed off to someone else, because it's taking too long due to an error in calculation of trajectory. Spending too much time on the wrong things. Incremental progress is the goal, and perfect is the mortal enemy of good.
srtjstjsj 8y ago
"Agile" is completely independent concept from "full stack" or "homogenized" development.
- kevstev 8y ago
  This is true. With the emphasis that Agile puts on "blockers" though it becomes apparent that the typical model of having a simple person own a component with maybe a backup person or two is problematic. "Only Amy knows that code, and she is working on X which is also critical" is one of the more frequent types of issues that comes up in standups. To combat this, this individual decided to try to reduce the specialization as much as possible. Everyone would do everything was the thought process, so no one could ever hold anything up. This was a non-technical founder of a now dead startup, but it died of the much more typical problem of market fit- they did launch, and the site worked. It may be interesting to mention he was also using entirely offshore development teams.

dagw 8y ago

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." And honestly that is all that most companies actually want/need. Most teams are mediocre and most projects only need a mediocre result. Getting something as good as a mediocre results out of your mediocre teams would be a massive improvement for a lot of place.

s73v3r_ 8y ago
To be honest, that wouldn't be a problem if more companies were up front about it. But every company out there has this idea that they have to hire "the best".
- dagw 8y ago
  every company out there has this idea that they have to hire "the best". Maybe in Silicone Valley, but most companies are happy if they can just find a programmer that knows how to program.
jon-wood 8y ago
I would rephrase it from "mediocre results" to "good enough results" - not everything needs to be a work of art. Especially in the startup world, where there's never enough people to go round, there's a huge value in knowing when you've done enough that the project you're working on is no longer the thing that'll deliver the most value. What agile does when executed right is to fully embrace that, and wrap it in a process that ensures that when you reach that point you're able to finish the current iteration, ship what you've got, and move on leaving things in a good enough state. For me that's the core of agile, and in my experience at least you can't pull that off with a mediocre team. You need a team where at least some members have the experience and the pragmatism to know the difference between delivering a minimum viable product and cutting corners in a way that'll hurt in the future.
- yebyen 8y ago
  When I learned about the concept of "just barely good enough" I was thrilled by it. Lots of people been using the expression "good enough" and to me it feels like a defeatist idea. "They did their best! It's good enough, isn't it?" http://agilemodeling.com/essays/barelyGoodEnough.html http://agilemodeling.com/essays/barelyGoodEnough.html Given the constraints of the estimate we've made for a story that could really go much longer, except that we've only allocated two days... I think the problem you're hinting at is that different people have different ideas of what the Minimum Viable Product should look like. Accordingly, on my team where we're all under-trained with respect to Project Management and mostly just making this shit up as we go along, we've identified several other points on the curve. It's suggested that one should make some nominal efforts to identify, and stop for a sniff along the way to JBGE: "that's definitely not good enough, try again" "I'll know it when I see it, but I'm sure that isn't it" "kinda-sorta good enough" "that's nearly good enough, except for this one thing..." Identifying some of these points along the way (and making sure you notice when you've arrived at them) in my opinion is a great way to help ensure you're not actually aiming for points somewhere deep on the wrong side of the curve. The mediocre team also may have trouble getting to Just Barely Good Enough because of overshooting. But in my experience that's usually not the problem. Nobody is working far past JBGE into the wee hours of the "OMG this is too much, I love it but how long did it actually take?" If anything, the feature has to be shelved or scrapped, or handed off to someone else, because it's taking too long due to an error in calculation of trajectory. Spending too much time on the wrong things. Incremental progress is the goal, and perfect is the mortal enemy of good.

srtjstjsj 8y ago

"Agile" is completely independent concept from "full stack" or "homogenized" development.

kevstev 8y ago
This is true. With the emphasis that Agile puts on "blockers" though it becomes apparent that the typical model of having a simple person own a component with maybe a backup person or two is problematic. "Only Amy knows that code, and she is working on X which is also critical" is one of the more frequent types of issues that comes up in standups. To combat this, this individual decided to try to reduce the specialization as much as possible. Everyone would do everything was the thought process, so no one could ever hold anything up. This was a non-technical founder of a now dead startup, but it died of the much more typical problem of market fit- they did launch, and the site worked. It may be interesting to mention he was also using entirely offshore development teams.