4 ms·

Aren’t you putting all your faith in the PM in this methodology? The way you describe it, a developer’s role is to point out stories and jointly perform the wo

Aren’t you putting all your faith in the PM in this methodology? The way you describe it, a developer’s role is to point out stories and jointly perform the work the PM has allocated. Instead, if those same developers understood the users, use cases and metrics and co-created the work the team does, the team would have 10 or mor engaged minds all working to make a better experience instead of the one super PM.

latchkey 7y ago
It isn't black and white like that. The team always has a voice and can express it at any time. Communication is always key and that is the whole point of developers pointing stories. They could just call a story 8 points and the PM would never get it into the backlog. =)
- ec109685 7y ago
  Right, but that is different than the PM asking the development team what we should do this iteration.
  - latchkey 7y ago
    The PM is the conduit between the business needs and the developers. The PM and the lead team dev decides the backlog. Devs just pick the next story from the queue, but of course they have input on things as well and can convey this in any of the meetings or directly with the core dev or PM.
    - ec109685 7y ago
      Yes they can coney things, but it isn’t by default. Having conduits, etc. is a waterfall approach.
faeyanpiraat 7y ago
There are lots of devs who have a personality that benefit from having a leader (PM). Also when you are doing the 101st CRUD type function in an app, you probably cannot be that enthusiastic about managing yourself either.
- whatshisface 7y ago
  How can this state of affairs where developers grind out CRUD features and complain about how bored they are be stable? The identifying feature of areas where automation would be profitable is human boredom, and this is something where developers are the ones bored. Why hasn't all of the repetition in CRUD stuff been dealt with by now?
  - gombosg 7y ago
    Saying this is saying like "why do we need architects to design houses if all of them are just four walls and a roof?" Software engineering is not that different from mechanical or civil engineering or whatever other kinds of it. However you automate any design process, you'll still need engineers to properly utilize that automation, customize, verify, maintain (oversee manufacturing or software deployment) and fix problems.
  - imtringued 7y ago
    CRUD has been automated a long time ago. It's trivial to create forms with 120 fields based on scaffolding and automate the DB access with an ORM. It is time intensive to actually make software that is better than the paper equivalent. The scaffold puts everything on one page so you split it up into 10. You still have to interact with other systems to autofill form fields. Implement app specific access controls (only users in the same department can see each others forms, only X can actually edit). Implement the actual workflow (ask for digital signature from superior, send email, send end result to SAP or whatever).
twic 7y ago
Teams often work this way in practice. The product owner has ultimate responsibility for choice and priority of stories, but like any competent leader, they will exercise that responsibility on the advice of their team. If the team's programmers are "product-minded" [1], then the PO will be getting lots of input from them, and in a healthy team will be going along with most of it - the PO is in a "first among equals" kind of position. If the programmers are not like that (junior, new to the domain, just not built that way), then the PO will make the product decisions without them (but still with the support of a product designer, hopefully!). There's an excellent leadership principle in the UK armed forces (and i'm sure elsewhere) that a leader must consult their subordinates before making a decision, but that once a decision made, subordinates must go along with it. The PM - programmer relationship around prioritization is an example of that. [1] https://blog.pragmaticengineer.com/the-product-minded-engineer/ https://blog.pragmaticengineer.com/the-product-minded-engine...

latchkey 7y ago

It isn't black and white like that. The team always has a voice and can express it at any time. Communication is always key and that is the whole point of developers pointing stories. They could just call a story 8 points and the PM would never get it into the backlog. =)

ec109685 7y ago
Right, but that is different than the PM asking the development team what we should do this iteration.
- latchkey 7y ago
  The PM is the conduit between the business needs and the developers. The PM and the lead team dev decides the backlog. Devs just pick the next story from the queue, but of course they have input on things as well and can convey this in any of the meetings or directly with the core dev or PM.
  - ec109685 7y ago
    Yes they can coney things, but it isn’t by default. Having conduits, etc. is a waterfall approach.

faeyanpiraat 7y ago

There are lots of devs who have a personality that benefit from having a leader (PM). Also when you are doing the 101st CRUD type function in an app, you probably cannot be that enthusiastic about managing yourself either.

whatshisface 7y ago
How can this state of affairs where developers grind out CRUD features and complain about how bored they are be stable? The identifying feature of areas where automation would be profitable is human boredom, and this is something where developers are the ones bored. Why hasn't all of the repetition in CRUD stuff been dealt with by now?
- gombosg 7y ago
  Saying this is saying like "why do we need architects to design houses if all of them are just four walls and a roof?" Software engineering is not that different from mechanical or civil engineering or whatever other kinds of it. However you automate any design process, you'll still need engineers to properly utilize that automation, customize, verify, maintain (oversee manufacturing or software deployment) and fix problems.
- imtringued 7y ago
  CRUD has been automated a long time ago. It's trivial to create forms with 120 fields based on scaffolding and automate the DB access with an ORM. It is time intensive to actually make software that is better than the paper equivalent. The scaffold puts everything on one page so you split it up into 10. You still have to interact with other systems to autofill form fields. Implement app specific access controls (only users in the same department can see each others forms, only X can actually edit). Implement the actual workflow (ask for digital signature from superior, send email, send end result to SAP or whatever).

twic 7y ago

Teams often work this way in practice. The product owner has ultimate responsibility for choice and priority of stories, but like any competent leader, they will exercise that responsibility on the advice of their team. If the team's programmers are "product-minded" [1], then the PO will be getting lots of input from them, and in a healthy team will be going along with most of it - the PO is in a "first among equals" kind of position. If the programmers are not like that (junior, new to the domain, just not built that way), then the PO will make the product decisions without them (but still with the support of a product designer, hopefully!). There's an excellent leadership principle in the UK armed forces (and i'm sure elsewhere) that a leader must consult their subordinates before making a decision, but that once a decision made, subordinates must go along with it. The PM - programmer relationship around prioritization is an example of that. [1] https://blog.pragmaticengineer.com/the-product-minded-engineer/ https://blog.pragmaticengineer.com/the-product-minded-engine...