3 ms·

>I actually like vanilla Scrum Scrum has some really serious flaws: 1) It creates a massive disincentive against refactoring technical debt (refactoring stori

>I actually like vanilla Scrum Scrum has some really serious flaws: 1) It creates a massive disincentive against refactoring technical debt (refactoring stories essentially have to be 'sold' to the product owner). 2) You end up spending more time than is necessary in too-long meetings. Planning should really be done continuously rather than in biweekly meetings. 3) The idea that you should deliver working software every two weeks is outmoded. You should be aiming to deliver potentially shippable increments continuously.

ljf 9y ago
1 the po is the representative of the customer and cares about the long life of the product. Sounds like a role that should care about the future state of the code/product though will obvs want to understand the cost/value of anything that isn't helping the immediate needs 2 planning can be continuous, just every two weeks you look at what you should focus on next, you can still bring stuff into the sprint along the way if everyone agrees 3 you plan to deliver a bundle of value every two weeks (so you can bite off enough to get stuck into, but not so much that you can head in the wrong direction for long) but you can release as soon as the code is ready, no need to wait until the end of sprint.
- crdoconnor 9y ago
  >the po is the representative of the customer and cares about the long life of the product. That does not make them qualified to rank and/or write refactoring stories. IMHO, they should tell the developers how long to spend on refactoring/tooling (e.g. 30% of their time) and developers should figure out themselves how to spend that time. That isn't scrum, though. >planning can be continuous, just every two weeks you look at what you should focus on next That's saying on the one hand that planning both is and is not continuous. >you plan to deliver a bundle of value every two weeks I call this mini waterfall. It's a good thing to shoot for if you were y previously doing releases every 3 months. It's not a good thing to shoot for if you were previously doing daily releases.
  - ljf 9y ago
    Sorry, wasn't clear with the value piece, you deliver (to live/the user) each piece/story when it is ready, but have a grouping of items that you want to improve across he sprint. I.e. This sprint we will improve login with this 8 stories And fully agree the po won't write the refactoring stories, but anyone can write stories. I'm not that technical but I've never worked somewhere where the team wasn't able to talk about the value of tech debt etc and help me understand the value of bringing them in.
    - crdoconnor 9y ago
      >I'm not that technical but I've never worked somewhere where the team wasn't able to talk about the value of tech debt etc They can talk about it, but under scrum it has to be sold to the PO to get it prioritized. I've worked with plenty of dev teams that could talk but couldn't sell. And it's the hardest kind of thing to sell, because the benefits are diffuse, abstract and usually long term, whereas feature stories are the exact opposite. I've seen this whole sales pitch/pushback process fail in lots of places. Techie explains problem to PO in techie terms -> PO's eyes glaze over while they nod their head and agree that this stuff is important -> story keeps getting pushed down the backlog in favor of stories that have a concrete dollar value attached. -> quality suffers as a result.
      - fpig 9y ago
        True, however I'd say this is a problem with having an incompetent person in charge, not a problem with the process. I've had the experience you describe but also the opposite experience where people understood the need to rework things and what the business impact of not doing it will be. What makes a difference are 2 things: 1. The person making a decision like "should we do refactoring" should not be incompetent. They should be technically great and also in tune with the company's business needs. I know some smaller companies have non-technical people in all non-dev roles, so it's either the devs who do the work deciding or a non-technical person deciding, but that is just stupidity, at the very least the guy who is the boss of the development team should be a development guy. I seriously doubt that at for example Microsoft or Google, a non-technical person makes this type of decision. 2. The incentive system should not be messed up. Especially at companies with multiple levels of traditional managers, you have problems like people treating their job almost like a game, where they try to make their numbers good at the end of the year or avoid ever telling their bosses something their bosses don't want to hear... They completely lose alignment with the company's interests and treat their job like a game of looking good to their boss, so even if they understand the need for something they might say no to avoid missing a deadline they told their boss they would hit etc... This doesn't really happen at SD companies because most of them are new and never developed this type of culture but it happens at companies that are in another field and just have a SD department I also don't think the solution of "30% of time" is good. Sometimes you need more, sometimes less, sometimes it's more important, sometimes less, sometimes more urgent, sometimes less. I still think you should "sell" refactoring to your boss, but the "boss" at a level where "should we refactor" decisions are being made should be an extremely technical guy who also knows how it will affect the business side of the project.

ljf 9y ago

1 the po is the representative of the customer and cares about the long life of the product. Sounds like a role that should care about the future state of the code/product though will obvs want to understand the cost/value of anything that isn't helping the immediate needs 2 planning can be continuous, just every two weeks you look at what you should focus on next, you can still bring stuff into the sprint along the way if everyone agrees 3 you plan to deliver a bundle of value every two weeks (so you can bite off enough to get stuck into, but not so much that you can head in the wrong direction for long) but you can release as soon as the code is ready, no need to wait until the end of sprint.

crdoconnor 9y ago
>the po is the representative of the customer and cares about the long life of the product. That does not make them qualified to rank and/or write refactoring stories. IMHO, they should tell the developers how long to spend on refactoring/tooling (e.g. 30% of their time) and developers should figure out themselves how to spend that time. That isn't scrum, though. >planning can be continuous, just every two weeks you look at what you should focus on next That's saying on the one hand that planning both is and is not continuous. >you plan to deliver a bundle of value every two weeks I call this mini waterfall. It's a good thing to shoot for if you were y previously doing releases every 3 months. It's not a good thing to shoot for if you were previously doing daily releases.
- ljf 9y ago
  Sorry, wasn't clear with the value piece, you deliver (to live/the user) each piece/story when it is ready, but have a grouping of items that you want to improve across he sprint. I.e. This sprint we will improve login with this 8 stories And fully agree the po won't write the refactoring stories, but anyone can write stories. I'm not that technical but I've never worked somewhere where the team wasn't able to talk about the value of tech debt etc and help me understand the value of bringing them in.
  - crdoconnor 9y ago
    >I'm not that technical but I've never worked somewhere where the team wasn't able to talk about the value of tech debt etc They can talk about it, but under scrum it has to be sold to the PO to get it prioritized. I've worked with plenty of dev teams that could talk but couldn't sell. And it's the hardest kind of thing to sell, because the benefits are diffuse, abstract and usually long term, whereas feature stories are the exact opposite. I've seen this whole sales pitch/pushback process fail in lots of places. Techie explains problem to PO in techie terms -> PO's eyes glaze over while they nod their head and agree that this stuff is important -> story keeps getting pushed down the backlog in favor of stories that have a concrete dollar value attached. -> quality suffers as a result.
    - fpig 9y ago
      True, however I'd say this is a problem with having an incompetent person in charge, not a problem with the process. I've had the experience you describe but also the opposite experience where people understood the need to rework things and what the business impact of not doing it will be. What makes a difference are 2 things: 1. The person making a decision like "should we do refactoring" should not be incompetent. They should be technically great and also in tune with the company's business needs. I know some smaller companies have non-technical people in all non-dev roles, so it's either the devs who do the work deciding or a non-technical person deciding, but that is just stupidity, at the very least the guy who is the boss of the development team should be a development guy. I seriously doubt that at for example Microsoft or Google, a non-technical person makes this type of decision. 2. The incentive system should not be messed up. Especially at companies with multiple levels of traditional managers, you have problems like people treating their job almost like a game, where they try to make their numbers good at the end of the year or avoid ever telling their bosses something their bosses don't want to hear... They completely lose alignment with the company's interests and treat their job like a game of looking good to their boss, so even if they understand the need for something they might say no to avoid missing a deadline they told their boss they would hit etc... This doesn't really happen at SD companies because most of them are new and never developed this type of culture but it happens at companies that are in another field and just have a SD department I also don't think the solution of "30% of time" is good. Sometimes you need more, sometimes less, sometimes it's more important, sometimes less, sometimes more urgent, sometimes less. I still think you should "sell" refactoring to your boss, but the "boss" at a level where "should we refactor" decisions are being made should be an extremely technical guy who also knows how it will affect the business side of the project.