4 ms·

Yeah it does suck and you’re not wrong. I’ve spent the last 3 years at my company trying to refine our Agile/Scrum process into something that gets out of my en

Yeah it does suck and you’re not wrong. I’ve spent the last 3 years at my company trying to refine our Agile/Scrum process into something that gets out of my engineers way. It basically boils down to the Engineering manager, product manager and project manager or “scrum master” actually putting in a good bit of work to make things run smoothly. 1) keep your stands below 15 minutes. Always. There should also never be more than 15 participants in your stand. 2) The EM/PM/SM or all of the above should be writing high quality tickets that are discrete units of work (they can be tested and have some tangible output). They should never be so large as to take a single developer the entire length of the sprint. 3) Do a single weekly grooming/pointing session. This should take less than 2 hours assuming management did their jobs 4) EM/PM/PM/SM need to actually keep the backlog organized. Don’t make devs sit thru meetings where you slowly drive Jira 5) Do demos, retro and planning in a 3 hour time block with breaks. Balance what went well with what speed bumps you encountered and call out exceptional work done by team members 6) Make judicious use of doing “proof of concepts” to help spec out features/APIs/Integrations before running off to plan larger initiatives 7) Appoint an “Epic Captain” to each epic (group of related tickets). This is dev who is the subject matter expert and has some decision making authority. Defaults to the EM but they should appoint other devs to take proactive ownership over things 8) Proactively track and discuss technical debt and raise it during retrospectives; EM follows through by ticketing it up. 9) Actually do planning when launching major initiatives. A few discussions between devs before leaping into several weeks long project won’t make you waterfall and will actually reduce meetings in the future For us, the average time per week an engineer spends in meetings is less than 5 hours total, or <1 hour per day on a team of 8. Kinda high but things run smoothly and nobody is out of the loop

throwuwu 4y ago
This sounds nice. Can you recommend any materials I can forward to my (inexperienced)PM?
koonsolo 4y ago
> Engineering manager, product manager and project manager What kind of Agile are following that has these roles defined?
- spamizbad 4y ago
  Your “product manager” is your stakeholder and your project manager is your scrum master but do agile processes really have no technical managers involved? Engineering manager can be “tech lead” or “lead developer” too I suppose but their workload is going to be skewed away from being an IC. If Agile is being implemented in a way where engineering has zero formal authority or stakeholders that goes a long way to explain why engineers hate it.
  - koonsolo 4y ago
    A project manager is very different than a scrum master. Quoting this website https://www.coursera.org/articles/scrum-master-vs-project-manager https://www.coursera.org/articles/scrum-master-vs-project-ma... "the Project Manager plays the leadership role by leading the planning for the execution of the project. Scrum Master plays a support role for the team members" Agile development teams should be self organizing, and so a lead that decides on things is really strange. See the 11th principle of Agile: 11. Best architectures, requirements, and designs emerge from self-organizing teams. If the team wants to appoint a tech lead, then fine. But forcing a tech lead onto an Agile team is not how it's done. I get it that "Agile" is the hype and every company claims to do "Agile". I would love the see the companies that really implement the 4 items of the manifesto and 12 Agile software development principles. I'm sure most companies are doing the reverse than what is stated there.
    - spamizbad 4y ago
      Correct, it's not "pure" agile, because that version of agile is extremely frustrating to implement inside any organization that's not a consultancy. That shouldn't surprise you: capital "A" Agile grew out of consultancies. It's not a good fit for product-driven technology firms, but product-driven firms try to adopt small "a" agile principles. The temptation to say "If you're not enjoying yourself you're doing it wrong" doesn't really work here. Agile was not shaped by technology firms or a product culture. Its roots are in a contract job to rewrite a payroll system at a Fortune 500 company and if that's your line of work then you can hew closer to “pure” agile. The rest of us are handed a process we have to make work inside an existing org.

throwuwu 4y ago

This sounds nice. Can you recommend any materials I can forward to my (inexperienced)PM?

koonsolo 4y ago

> Engineering manager, product manager and project manager What kind of Agile are following that has these roles defined?

spamizbad 4y ago
Your “product manager” is your stakeholder and your project manager is your scrum master but do agile processes really have no technical managers involved? Engineering manager can be “tech lead” or “lead developer” too I suppose but their workload is going to be skewed away from being an IC. If Agile is being implemented in a way where engineering has zero formal authority or stakeholders that goes a long way to explain why engineers hate it.
- koonsolo 4y ago
  A project manager is very different than a scrum master. Quoting this website https://www.coursera.org/articles/scrum-master-vs-project-manager https://www.coursera.org/articles/scrum-master-vs-project-ma... "the Project Manager plays the leadership role by leading the planning for the execution of the project. Scrum Master plays a support role for the team members" Agile development teams should be self organizing, and so a lead that decides on things is really strange. See the 11th principle of Agile: 11. Best architectures, requirements, and designs emerge from self-organizing teams. If the team wants to appoint a tech lead, then fine. But forcing a tech lead onto an Agile team is not how it's done. I get it that "Agile" is the hype and every company claims to do "Agile". I would love the see the companies that really implement the 4 items of the manifesto and 12 Agile software development principles. I'm sure most companies are doing the reverse than what is stated there.
  - spamizbad 4y ago
    Correct, it's not "pure" agile, because that version of agile is extremely frustrating to implement inside any organization that's not a consultancy. That shouldn't surprise you: capital "A" Agile grew out of consultancies. It's not a good fit for product-driven technology firms, but product-driven firms try to adopt small "a" agile principles. The temptation to say "If you're not enjoying yourself you're doing it wrong" doesn't really work here. Agile was not shaped by technology firms or a product culture. Its roots are in a contract job to rewrite a payroll system at a Fortune 500 company and if that's your line of work then you can hew closer to “pure” agile. The rest of us are handed a process we have to make work inside an existing org.