9 ms·

The article mentions Plan->Iterate->Ship a lot. How is this essentially different from Scrum sprints?

by macco 4y ago

ecshafer 4y ago
Plan -> iterate -> Ship is different than scrum. One big difference is that its not usually time boxed into sprints. Another is that there may be multiple independent projects being worked on on one team. So you might have a team with project A being in the final touches, while an engineer leads on the plan phase for project B, as another person might be leading C in Iterate.
lostdog 4y ago
1. Scrum sprints have all sorts of goofy restrictions, that you don't need to waste time on with a true-agile process. You don't need to plan out exactly two weeks. You don't need to worry about having too much or too little work in the sprint. 2. Scrum requires you to break things down pointlessly, when really most teams can execute on higher level goals. 3. Teams do not need to meet for a standup every day. 4. Effort estimates can be extremely approximate and wrong, but scrum tries to force you to spend way too much time on them. The "plan" in a non-scrum environment is much better at focusing on what matters, rather than ticking all the scrum boxes.
- treis 4y ago
  You can do anything badly. Like point one, no you don't need to plan out exactly two weeks. You estimate what you want to get done in two weeks and then at the end you see how close you got. It's supposed to be a reality check to see how well estimates are matching up to actual effort. Which I don't really see why you shouldn't do something like that.
  - dubswithus 4y ago
    Our pointing sessions sometimes last 1.5 hours and involve the whole team regardless of expertise. Just imagine how much money we are wasting to determine: is this story a 1 point or 2 point story.
    - treis 4y ago
      Goes back to the original point. If you do something badly then it's no surprise the results are suboptimal.
      - dubswithus 4y ago
        Yeah but if we do it well I still have to sit through a 1.5 hour retro. My therapy sessions are shorter.
        nprateem 4y ago
        I'd say 95% of sprint ceremonies I'm in are a complete waste of time. Still, amen for WFH.
        treis 4y ago
        Again, goes back to the point of you can do anything poorly. Ours are 30-60 minutes and usually have good conversations about issues the team sees. More often than not meaningful change comes out of it.
        dubswithus 4y ago
        You're having 60 minutes of issues every few weeks? And you think something isn't done poorly? That's way too long.
        icedchai 4y ago
        The only meaningful change I ever saw come out of a "retro" was making daily standups async twice a week (done over Slack.) Then the manager didn't like that, so it was rolled back. Most of the retros I'd just roll my eyes at. "What can we do differently?" cancel the retros...
        dubswithus 4y ago
        Haha. Tell them we can't do anything differently because that would mess up the meticulous Jira/Agile flow we've setup in other meetings and have affirmed in retros.
heisenbit 4y ago
There is no Scrum Master but Tech Leads. The former in their degenerated but sadly all too common enterprise form know primarily process, shy away from deeper knowledge and focus on enforcing the former. Shipping becomes the side effect of process. It is safer that way as process can always be controlled the challenges of shipping a deliverable not - at least for the scrum master.
nprateem 4y ago
Can't even find a blogpost where this is explained. Anyone got any links please? * What form does planning take? * Does someone from the business side approve the UX before it's implemented, etc.? * Is progress not tracked at all or only informally? * Are people actually treated like adults to ask for help to unblock things instead of needing 8 people on a call so one person can say they're having an issue and need one other person's help?
- olliej 4y ago
  Planning is what makes sense for the project scope, and can easily be recursive through orgs and teams. Each layer works out the core components needed, then which teams would be needed for those components. Those teams then work out what sub components are most effectively done by which teams, and repeat recursively. Teams may find overlap for components and assign subsets from multiple teams to work together to plan for those overlapping areas. This would seem like the obvious way to plan for anything. Why would business side have significant input into UX - that’s the whole reason you have hired UI and HI teams? An effective bug tracker has the concept of related and blocking bugs, along with priorities, etc. Anyone can see how progress is happening in trackers. Occasional meetings between ICs or PMs can identify where things are falling behind or getting blocked, and either work to reprioritise or re-resource as appropriate. I my experience that has never been significant impedance between ICs and managerial types communicating directly. This feeds into ICs being able to decide what to work on - if another IC comes to you needing help or needing some particular bug fixed earlier than expected you can always in crease the priority or provide short term work around, etc - or talk to other ICs in your team to see if someone else has capacity to get it fixed earlier. To me this all seems like the sensible way to get software done at large scale. As I’ve said elsewhere maybe it’s different at small or young companies, but the share interminable “process” of scrum, “agile”, etc seems asinine.
  - nprateem 4y ago
    Thanks

The article mentions Plan->Iterate->Ship a lot. How is this essentially different from Scrum sprints?

by macco 4y ago

The article mentions Plan->Iterate->Ship a lot. How is this essentially different from Scrum sprints?

Plan -> iterate -> Ship is different than scrum. One big difference is that its not usually time boxed into sprints. Another is that there may be multiple independent projects being worked on on one team. So you might have a team with project A being in the final touches, while an engineer leads on the plan phase for project B, as another person might be leading C in Iterate.

lostdog 4y ago

1. Scrum sprints have all sorts of goofy restrictions, that you don't need to waste time on with a true-agile process. You don't need to plan out exactly two weeks. You don't need to worry about having too much or too little work in the sprint. 2. Scrum requires you to break things down pointlessly, when really most teams can execute on higher level goals. 3. Teams do not need to meet for a standup every day. 4. Effort estimates can be extremely approximate and wrong, but scrum tries to force you to spend way too much time on them. The "plan" in a non-scrum environment is much better at focusing on what matters, rather than ticking all the scrum boxes.

treis 4y ago
You can do anything badly. Like point one, no you don't need to plan out exactly two weeks. You estimate what you want to get done in two weeks and then at the end you see how close you got. It's supposed to be a reality check to see how well estimates are matching up to actual effort. Which I don't really see why you shouldn't do something like that.
- dubswithus 4y ago
  Our pointing sessions sometimes last 1.5 hours and involve the whole team regardless of expertise. Just imagine how much money we are wasting to determine: is this story a 1 point or 2 point story.
  - treis 4y ago
    Goes back to the original point. If you do something badly then it's no surprise the results are suboptimal.
    - dubswithus 4y ago
      Yeah but if we do it well I still have to sit through a 1.5 hour retro. My therapy sessions are shorter.
      - nprateem 4y ago
        I'd say 95% of sprint ceremonies I'm in are a complete waste of time. Still, amen for WFH.
      - treis 4y ago
        Again, goes back to the point of you can do anything poorly. Ours are 30-60 minutes and usually have good conversations about issues the team sees. More often than not meaningful change comes out of it.
        dubswithus 4y ago
        You're having 60 minutes of issues every few weeks? And you think something isn't done poorly? That's way too long.
        icedchai 4y ago
        The only meaningful change I ever saw come out of a "retro" was making daily standups async twice a week (done over Slack.) Then the manager didn't like that, so it was rolled back. Most of the retros I'd just roll my eyes at. "What can we do differently?" cancel the retros...
        dubswithus 4y ago
        Haha. Tell them we can't do anything differently because that would mess up the meticulous Jira/Agile flow we've setup in other meetings and have affirmed in retros.

heisenbit 4y ago

There is no Scrum Master but Tech Leads. The former in their degenerated but sadly all too common enterprise form know primarily process, shy away from deeper knowledge and focus on enforcing the former. Shipping becomes the side effect of process. It is safer that way as process can always be controlled the challenges of shipping a deliverable not - at least for the scrum master.

nprateem 4y ago

Can't even find a blogpost where this is explained. Anyone got any links please? * What form does planning take? * Does someone from the business side approve the UX before it's implemented, etc.? * Is progress not tracked at all or only informally? * Are people actually treated like adults to ask for help to unblock things instead of needing 8 people on a call so one person can say they're having an issue and need one other person's help?

olliej 4y ago
Planning is what makes sense for the project scope, and can easily be recursive through orgs and teams. Each layer works out the core components needed, then which teams would be needed for those components. Those teams then work out what sub components are most effectively done by which teams, and repeat recursively. Teams may find overlap for components and assign subsets from multiple teams to work together to plan for those overlapping areas. This would seem like the obvious way to plan for anything. Why would business side have significant input into UX - that’s the whole reason you have hired UI and HI teams? An effective bug tracker has the concept of related and blocking bugs, along with priorities, etc. Anyone can see how progress is happening in trackers. Occasional meetings between ICs or PMs can identify where things are falling behind or getting blocked, and either work to reprioritise or re-resource as appropriate. I my experience that has never been significant impedance between ICs and managerial types communicating directly. This feeds into ICs being able to decide what to work on - if another IC comes to you needing help or needing some particular bug fixed earlier than expected you can always in crease the priority or provide short term work around, etc - or talk to other ICs in your team to see if someone else has capacity to get it fixed earlier. To me this all seems like the sensible way to get software done at large scale. As I’ve said elsewhere maybe it’s different at small or young companies, but the share interminable “process” of scrum, “agile”, etc seems asinine.
- nprateem 4y ago
  Thanks