3 ms·

How do you handle people that simply don't do well on this? I have for example a front-end guy who's not really good in UX and always jumps in to code instead o

How do you handle people that simply don't do well on this? I have for example a front-end guy who's not really good in UX and always jumps in to code instead of discussing a mockup first.

tonyarkles 8y ago
I've been thinking about this a fair bit lately. How do you get from where you're at right now to something better? I haven't yet figured out any kind of holy grail approach that works, unfortunately :) What I have been thinking about quite a bit is the idea of "initial conditions" in software. If a project starts out in a super cowboy way (let's not think about requirements, bring on the code!) and proceeds relatively successfully that way for a while, it's damned hard to reign that back in to a process where you do requirements and think about the problem before starting to write code. Best I can tell, the way to keep things like this from getting out of hand is to nip them in the bud early before they become habits. That, unfortunately, doesn't help teams that are in the "nothing is thought out" swamp... Edit: I just remembered the Scott Adams article on HN today too, talking about systems. That's exactly what this is all about: making systems where it's just assumed that you're going to do the requirements work up front. You can still do this in an Agile way, you just don't immediately pluck a card off and start writing code; you normalize the fact that the person is going to spend some time thinking about the solution first and writing those thoughts down. That, too, is easier said than done. One team that I've worked with was heavily resistant to a 4 point checklist that was automatically added to their pull requests... It was not a burden and was specifically tailored to catching common mistakes they'd been making, but there was still a lot of resistance and ultimately the idea was abandoned.
- anotheryou 8y ago
  Thank you for reply. I think it also depends a lot on the individual. You need more motivation to invest some thoughts instead of just getting it over with.
  - tonyarkles 8y ago
    Is this front-end guy an employee? Or a contractor? That changes things a little bit, but I think things below still apply. > You need more motivation to invest some thoughts instead of just getting it over with. That's where your team's standards help, especially if you get them set up early. If, at the point this employee was hired, it was standard to (per the article's example) spend 40% of the task time up front thinking about the problem and writing it out, then the motivation is simple: If I don't do it this way, then I won't fit in with the team that I joined and I'll probably get fired. Onto the situation you're in right now, where this person has been on your team for a while and not doing this... Do the other teammates do this? Is there code review? Do they flag the fact that this person is implementing features sloppily and push back on that at review time?
    - anotheryou 8y ago
      I joined the team half year ago and since then we started code review (but quite technical, so sloppy UX won't be caught here), I write actual concepts (instead of just 1/2 page of a rough draft before implementation starts), we discuss and adjust the concepts together and there is a roadmap (not super agile, but suits what we currently do best). So there is little culture to build upon, but we take steps in the right direction (though time pressure from upper management makes progress plateau a bit here). About the (sole) front-end guy: he's an employee and a little less independent than the others. Thank you for the encouraging me to develop the culture a further. Currently I try to get the devs to write propper tickets themselves at least (in a way that lets QA do their job afterwards).
      - tonyarkles 8y ago
        > I write actual concepts (instead of just 1/2 page of a rough draft before implementation starts), we discuss and adjust the concepts together and there is a roadmap (not super agile, but suits what we currently do best) Keep doing what you're doing! That's awesome!

How do you handle people that simply don't do well on this? I have for example a front-end guy who's not really good in UX and always jumps in to code instead of discussing a mockup first.

tonyarkles 8y ago

I've been thinking about this a fair bit lately. How do you get from where you're at right now to something better? I haven't yet figured out any kind of holy grail approach that works, unfortunately :) What I have been thinking about quite a bit is the idea of "initial conditions" in software. If a project starts out in a super cowboy way (let's not think about requirements, bring on the code!) and proceeds relatively successfully that way for a while, it's damned hard to reign that back in to a process where you do requirements and think about the problem before starting to write code. Best I can tell, the way to keep things like this from getting out of hand is to nip them in the bud early before they become habits. That, unfortunately, doesn't help teams that are in the "nothing is thought out" swamp... Edit: I just remembered the Scott Adams article on HN today too, talking about systems. That's exactly what this is all about: making systems where it's just assumed that you're going to do the requirements work up front. You can still do this in an Agile way, you just don't immediately pluck a card off and start writing code; you normalize the fact that the person is going to spend some time thinking about the solution first and writing those thoughts down. That, too, is easier said than done. One team that I've worked with was heavily resistant to a 4 point checklist that was automatically added to their pull requests... It was not a burden and was specifically tailored to catching common mistakes they'd been making, but there was still a lot of resistance and ultimately the idea was abandoned.

anotheryou 8y ago
Thank you for reply. I think it also depends a lot on the individual. You need more motivation to invest some thoughts instead of just getting it over with.
- tonyarkles 8y ago
  Is this front-end guy an employee? Or a contractor? That changes things a little bit, but I think things below still apply. > You need more motivation to invest some thoughts instead of just getting it over with. That's where your team's standards help, especially if you get them set up early. If, at the point this employee was hired, it was standard to (per the article's example) spend 40% of the task time up front thinking about the problem and writing it out, then the motivation is simple: If I don't do it this way, then I won't fit in with the team that I joined and I'll probably get fired. Onto the situation you're in right now, where this person has been on your team for a while and not doing this... Do the other teammates do this? Is there code review? Do they flag the fact that this person is implementing features sloppily and push back on that at review time?
  - anotheryou 8y ago
    I joined the team half year ago and since then we started code review (but quite technical, so sloppy UX won't be caught here), I write actual concepts (instead of just 1/2 page of a rough draft before implementation starts), we discuss and adjust the concepts together and there is a roadmap (not super agile, but suits what we currently do best). So there is little culture to build upon, but we take steps in the right direction (though time pressure from upper management makes progress plateau a bit here). About the (sole) front-end guy: he's an employee and a little less independent than the others. Thank you for the encouraging me to develop the culture a further. Currently I try to get the devs to write propper tickets themselves at least (in a way that lets QA do their job afterwards).
    - tonyarkles 8y ago
      > I write actual concepts (instead of just 1/2 page of a rough draft before implementation starts), we discuss and adjust the concepts together and there is a roadmap (not super agile, but suits what we currently do best) Keep doing what you're doing! That's awesome!