6 ms·

My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companie

My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can improve but it takes time, dedication, and support.

some_account 8y ago
I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that. It just complicates everything and makes me less connected and known in the company.
- vannevar 8y ago
  I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. How exactly does agile prevent you from talking to your teammates and getting feedback from them?
  - betenoire 8y ago
    If I have a full and well-groomed backlog waiting for me at my desk, what's there to talk about? Sure, you can, but the the whole point of the PM is to take that off your shoulders and the parent is saying he doesn't want that lifted from him.
    - vannevar 8y ago
      A well-groomed backlog is not working code. So I don't get how that somehow means there's nothing to talk about. If there's an agile MVP, it's "write some working code, get feedback on it, then repeat until everyone's happy within some tolerance." Scrum is designed to increase feedback, but it's a floor, not a ceiling.
      - betenoire 8y ago
        Sure, but the PM is there for a reason and the PM has roles. There is overlap with what developers can be doing, but we are trained/encouraged to punt to the PM for such decisions, questions, and suggestions. I get it, but it's now how I do my best work, proxying questions and discussions through a gatekeeper.
        vannevar 8y ago
        We do agile, but also use Slack and email, and walking across the room. If your organization is actively discouraging communication within the team unless it goes through the PM, that's bizarre. On the other hand, if the PM is acting as a gatekeeper with customers, that's not unusual. The reality is that you can't have everyone on the team talking directly to the customer, for a whole host of good reasons. Regarding decision-making, that can be a problem---some PMs and product owners are micromanagers, hamstringing their team. But they would be micro managers with or without agile.
        majormajor 8y ago
        IME the PM works best when acting as a shield from random questions or future things or other not-important-this-instant distractions, but shouldn't block direct clarifying questions or feedback from you to a stakeholder. I'd keep them in the loop, but the ones I've worked with haven't wanted to just be a glorified "I deal with the goddamn customers so the engineers don't have to!" middleman for basic things like that.
        alexchamberlain 8y ago
        As a tech lead in a Scrum team, this shield causes more problems than it solves in my experience. We often get questions missing context or find out about a decision too late to provide meaningful input on a technical level.
  - some_account 8y ago
    Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information.
    - geezerjay 8y ago
      > Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information. Scrum processes are just a way to ensure that no stakeholder, including team members, is left out of those talks, left in the dark, or left unheard. Having a clique single-handedly and unilaterally dictating changes without communicating them or listening to any stakeholder doesn't serve anyone's interests. That's how projects fail.
    - vannevar 8y ago
      A good team knows how and when to share information. True. Scrum is a floor, not a ceiling. Nothing prevents the team from going above and beyond the daily standup and the sprint review in terms of communication, and I've never been on a team that didn't communicate a lot more than that. But doing that standup every day ensures that there is at least a minimum of communication, every day.
  - decode 8y ago
    I'm pretty sure that when he says "the rest of the employees" he means what Scrum calls stakeholders, not members of the development team.
- srtjstjsj 8y ago
  Why haven't you told your manager that you are willing to do your job plus the product owner's job for only your pay plus half the product owner's pay?
  - s73v3r_ 8y ago
    Because that just doesn't work. It sounds clever, but in reality, it would get you laughed out of the office. And then the PO finds out that you offered to get him fired, and now the working relationship is ruined.
- jon-wood 8y ago
  For a long time I felt that way as well. There are days when I still do, and this is from my current perspective as a tech lead who spends ~50% of their time in meetings with other parts of the company. Sadly once a team scales up past a certain size its not practical to have developers also going out, finding out what people want built, and handling all the feedback on that. You need someone (or a team of someones) gathering the often conflicting requests coming in, and prioritising them against each other. Having said that, I do believe once a piece of work makes it to a point where people are likely to start working on it the developers who will be doing that work should be involved in the process. They should understand not only what is being requested, but also why its being requested, in my experience that often results in them suggesting alternative solutions that either bet solve the problem, or provide a 90% solution with significantly less cost. It also gives them the context needed when deciding on technical trade-offs involved in different design choices.
- gregmac 8y ago
  I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that. Part of little-a agile is making changes and adapting -- it's literally in the name. If you have a process in place that prevents you talking to the people you need to talk to, change or delete the process.
- maxxxxx 8y ago
  "I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them" I am the same way. I much prefer talking to users directly and come up with a solution instead of having a middle man. But I have noticed that a lot of devs much prefer somebody filtering things for them. I guess to each his own...
vannevar 8y ago
My experience is that a good team does a good job. A bad team doesn’t. Of course that's your experience. If you judge teams based on outcomes, then you're going to conclude that teams that succeed are good, and teams that don't must be bad. Unfortunately that offers no guidance in how to become a good team. The goal of software management as a practice is to find patterns of positive behavior that make good teams. Agile, in general, is a collection of those patterns.
- PeterisP 8y ago
  The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?
  - vannevar 8y ago
    How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment? I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Great teams have both talented people and winning strategy.
    - Retric 8y ago
      Because people regularly do "recruit good people and leave them alone". At my first job I was the only developer working on the project and I rarely spoke with my boss. He came back from a month long vacation and I had not noticed he was gone. That's surprisingly common across the field. Most developers work on small teams doing small but often very long lived projects. Code staying in production for 30 years is surprisingly common outside of SV.
      - 8y ago
kevstev 8y ago
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.
rwmj 8y ago
My experience is that a good team does a good job. A bad team doesn’t. My experience is that sprints interrupt my workflow to such an extent that I can no longer get anything done. In other words, they make a good team bad.
- simonswords82 8y ago
  How so? I'd be keen to hear just in case I'm unwittingly inflicting similar pain on my developers.
  - rwmj 8y ago
    Perhaps it's just me, but I need long periods uninterrupted to work. It's not just the regular status meetings, but other meetings which break up the day to an extent that I can no longer get that.
    - s73v3r_ 8y ago
      Yeah, but that's not a scrum thing. Most days, I have the daily stand up (which occurs right after I get to work), and that's it. The one day where we do all the grooming and retro and demo every two weeks is more or less lost, but that's not much of a problem.
      - AndrewSChapman 8y ago
        What about code reviews?
        s73v3r_ 8y ago
        Code reviews are very important, so I don't complain about time spent doing them.
molteanu 8y ago
Agreed. I've seen a lot of "good practices, methodologies, processes, etc", but none of them even tries to address what is, often times, the most critical issue: a team of good software engineers. Instead of endless meetings and bullet points about how to handle a Jira ticket, maybe focus on how to handle pointers?!. I've really had colleagues who don't know how to program in C and when asked about it said "I don't even want to learn it, we have all this tools and methods", but their title says "C embedded engineer" or thereabout. I can also see the business point of view in this. You want switchable puzzle pieces. Take this developer from this project and move him to that project. This developer knows X, Y, Z and that project needs X, Y and Z. So it's all nice and well. Only it doesn't seem to work in practice.

some_account 8y ago

I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that. It just complicates everything and makes me less connected and known in the company.

vannevar 8y ago
I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. How exactly does agile prevent you from talking to your teammates and getting feedback from them?
- betenoire 8y ago
  If I have a full and well-groomed backlog waiting for me at my desk, what's there to talk about? Sure, you can, but the the whole point of the PM is to take that off your shoulders and the parent is saying he doesn't want that lifted from him.
  - vannevar 8y ago
    A well-groomed backlog is not working code. So I don't get how that somehow means there's nothing to talk about. If there's an agile MVP, it's "write some working code, get feedback on it, then repeat until everyone's happy within some tolerance." Scrum is designed to increase feedback, but it's a floor, not a ceiling.
    - betenoire 8y ago
      Sure, but the PM is there for a reason and the PM has roles. There is overlap with what developers can be doing, but we are trained/encouraged to punt to the PM for such decisions, questions, and suggestions. I get it, but it's now how I do my best work, proxying questions and discussions through a gatekeeper.
      - vannevar 8y ago
        We do agile, but also use Slack and email, and walking across the room. If your organization is actively discouraging communication within the team unless it goes through the PM, that's bizarre. On the other hand, if the PM is acting as a gatekeeper with customers, that's not unusual. The reality is that you can't have everyone on the team talking directly to the customer, for a whole host of good reasons. Regarding decision-making, that can be a problem---some PMs and product owners are micromanagers, hamstringing their team. But they would be micro managers with or without agile.
      - majormajor 8y ago
        IME the PM works best when acting as a shield from random questions or future things or other not-important-this-instant distractions, but shouldn't block direct clarifying questions or feedback from you to a stakeholder. I'd keep them in the loop, but the ones I've worked with haven't wanted to just be a glorified "I deal with the goddamn customers so the engineers don't have to!" middleman for basic things like that.
        alexchamberlain 8y ago
        As a tech lead in a Scrum team, this shield causes more problems than it solves in my experience. We often get questions missing context or find out about a decision too late to provide meaningful input on a technical level.
- some_account 8y ago
  Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information.
  - geezerjay 8y ago
    > Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information. Scrum processes are just a way to ensure that no stakeholder, including team members, is left out of those talks, left in the dark, or left unheard. Having a clique single-handedly and unilaterally dictating changes without communicating them or listening to any stakeholder doesn't serve anyone's interests. That's how projects fail.
  - vannevar 8y ago
    A good team knows how and when to share information. True. Scrum is a floor, not a ceiling. Nothing prevents the team from going above and beyond the daily standup and the sprint review in terms of communication, and I've never been on a team that didn't communicate a lot more than that. But doing that standup every day ensures that there is at least a minimum of communication, every day.
- decode 8y ago
  I'm pretty sure that when he says "the rest of the employees" he means what Scrum calls stakeholders, not members of the development team.
srtjstjsj 8y ago
Why haven't you told your manager that you are willing to do your job plus the product owner's job for only your pay plus half the product owner's pay?
- s73v3r_ 8y ago
  Because that just doesn't work. It sounds clever, but in reality, it would get you laughed out of the office. And then the PO finds out that you offered to get him fired, and now the working relationship is ruined.
jon-wood 8y ago
For a long time I felt that way as well. There are days when I still do, and this is from my current perspective as a tech lead who spends ~50% of their time in meetings with other parts of the company. Sadly once a team scales up past a certain size its not practical to have developers also going out, finding out what people want built, and handling all the feedback on that. You need someone (or a team of someones) gathering the often conflicting requests coming in, and prioritising them against each other. Having said that, I do believe once a piece of work makes it to a point where people are likely to start working on it the developers who will be doing that work should be involved in the process. They should understand not only what is being requested, but also why its being requested, in my experience that often results in them suggesting alternative solutions that either bet solve the problem, or provide a 90% solution with significantly less cost. It also gives them the context needed when deciding on technical trade-offs involved in different design choices.
gregmac 8y ago
I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that. Part of little-a agile is making changes and adapting -- it's literally in the name. If you have a process in place that prevents you talking to the people you need to talk to, change or delete the process.
maxxxxx 8y ago
"I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them" I am the same way. I much prefer talking to users directly and come up with a solution instead of having a middle man. But I have noticed that a lot of devs much prefer somebody filtering things for them. I guess to each his own...

vannevar 8y ago

My experience is that a good team does a good job. A bad team doesn’t. Of course that's your experience. If you judge teams based on outcomes, then you're going to conclude that teams that succeed are good, and teams that don't must be bad. Unfortunately that offers no guidance in how to become a good team. The goal of software management as a practice is to find patterns of positive behavior that make good teams. Agile, in general, is a collection of those patterns.

PeterisP 8y ago
The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?
- vannevar 8y ago
  How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment? I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Great teams have both talented people and winning strategy.
  - Retric 8y ago
    Because people regularly do "recruit good people and leave them alone". At my first job I was the only developer working on the project and I rarely spoke with my boss. He came back from a month long vacation and I had not noticed he was gone. That's surprisingly common across the field. Most developers work on small teams doing small but often very long lived projects. Code staying in production for 30 years is surprisingly common outside of SV.
    - 8y ago

kevstev 8y ago

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.

rwmj 8y ago

My experience is that a good team does a good job. A bad team doesn’t. My experience is that sprints interrupt my workflow to such an extent that I can no longer get anything done. In other words, they make a good team bad.

simonswords82 8y ago
How so? I'd be keen to hear just in case I'm unwittingly inflicting similar pain on my developers.
- rwmj 8y ago
  Perhaps it's just me, but I need long periods uninterrupted to work. It's not just the regular status meetings, but other meetings which break up the day to an extent that I can no longer get that.
  - s73v3r_ 8y ago
    Yeah, but that's not a scrum thing. Most days, I have the daily stand up (which occurs right after I get to work), and that's it. The one day where we do all the grooming and retro and demo every two weeks is more or less lost, but that's not much of a problem.
    - AndrewSChapman 8y ago
      What about code reviews?
      - s73v3r_ 8y ago
        Code reviews are very important, so I don't complain about time spent doing them.

molteanu 8y ago

Agreed. I've seen a lot of "good practices, methodologies, processes, etc", but none of them even tries to address what is, often times, the most critical issue: a team of good software engineers. Instead of endless meetings and bullet points about how to handle a Jira ticket, maybe focus on how to handle pointers?!. I've really had colleagues who don't know how to program in C and when asked about it said "I don't even want to learn it, we have all this tools and methods", but their title says "C embedded engineer" or thereabout. I can also see the business point of view in this. You want switchable puzzle pieces. Take this developer from this project and move him to that project. This developer knows X, Y, Z and that project needs X, Y and Z. So it's all nice and well. Only it doesn't seem to work in practice.