28 ms·

The teams I've been on that just 'jive' usually start with some process framework but then evolve to just work well together. There are strong philosophies in

by matt_s 8y ago

The teams I've been on that just 'jive' usually start with some process framework but then evolve to just work well together. There are strong philosophies in Scrum and Agile that should be kept as guidelines. The key is being agile (lower case 'a') so you can adapt to changing priorities. Continuous Integration/Continuous Delivery go a long way towards empowering developers. Two ways to tackle technical debt in projects: 1. Tech debt sprint. If scrum master and product owner can't get onboard then they need to realize somewhere in the near future, a feature they want will either break things or take forever. 2. Break up tech debt into small efforts someone can do in short time boxes. Even do feature flags or something to make slower progress towards a goal rather than tech debt sitting in a backlog for months. An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating. Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps.

matthewmacleod 8y ago
I would say that estimation isn't so much about predicting completion as understanding hidden assumptions in the team. We sometimes find that engineers have entirely different concepts of how a particular feature or change needs to be implemented. Estimation – planning poker in particular – is a great way to reveal that and start exploring what the reasons are.
- matt_s 8y ago
  It is a good facilitator of that conversation but you don't need to do estimating to have that conversation about implementation details. Once a team arrives at common patterns of implementing things then those conversations really only need to happen for new implementations or integrations with other systems.
- zelos 8y ago
  "At least we're not doing planning poker" was a running joke response to any kind of crazy process stuff we were forced to do on my last team. Maybe it works better for small projects/teams, but in my experience it's a massive waste of time.
lmm 8y ago
> Two ways to tackle technical debt in projects: Disagree with tackling it as a separate activity at all - that's a way to get useless churn as you move towards an architecture you think is better rather than one that meets your actual needs. Do continuous improvement instead: improve the part of the codebase you're working on in a way that also contributes to your immediate, customer-facing task. "Make change easy, then make the easy change". > An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating. You need to give enough of an estimate to let the business prioritise, and to realise when a task is too big for a single ticket. You shouldn't spend a lot of time on estimation (frankly I struggle to imagine how your planning poker ended up taking long enough to matter) except when developers radically disagree, as that's a warning flag for a story that isn't clearly scoped. > Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps. You don't want to rely on one person getting it right. Developers, like most workers, understand their own job better than anyone else; they're the people who should be giving their estimates.
- nradov 8y ago
  We have minor refactoring baked into our definition of done, so when agile team members run across existing code that doesn't meet current standards then they're supposed to just go ahead and refactor it on the fly. Since it's part of the definition of done, it's not "extra" work and is accounted for in the user story points estimate. Larger refactorings that impact multiple modules have to be treated as separate user stories and prioritized based on business value just like everything else.

by matt_s 8y ago

matthewmacleod 8y ago

I would say that estimation isn't so much about predicting completion as understanding hidden assumptions in the team. We sometimes find that engineers have entirely different concepts of how a particular feature or change needs to be implemented. Estimation – planning poker in particular – is a great way to reveal that and start exploring what the reasons are.

matt_s 8y ago
It is a good facilitator of that conversation but you don't need to do estimating to have that conversation about implementation details. Once a team arrives at common patterns of implementing things then those conversations really only need to happen for new implementations or integrations with other systems.
zelos 8y ago
"At least we're not doing planning poker" was a running joke response to any kind of crazy process stuff we were forced to do on my last team. Maybe it works better for small projects/teams, but in my experience it's a massive waste of time.

lmm 8y ago

> Two ways to tackle technical debt in projects: Disagree with tackling it as a separate activity at all - that's a way to get useless churn as you move towards an architecture you think is better rather than one that meets your actual needs. Do continuous improvement instead: improve the part of the codebase you're working on in a way that also contributes to your immediate, customer-facing task. "Make change easy, then make the easy change". > An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating. You need to give enough of an estimate to let the business prioritise, and to realise when a task is too big for a single ticket. You shouldn't spend a lot of time on estimation (frankly I struggle to imagine how your planning poker ended up taking long enough to matter) except when developers radically disagree, as that's a warning flag for a story that isn't clearly scoped. > Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps. You don't want to rely on one person getting it right. Developers, like most workers, understand their own job better than anyone else; they're the people who should be giving their estimates.

nradov 8y ago
We have minor refactoring baked into our definition of done, so when agile team members run across existing code that doesn't meet current standards then they're supposed to just go ahead and refactor it on the fly. Since it's part of the definition of done, it's not "extra" work and is accounted for in the user story points estimate. Larger refactorings that impact multiple modules have to be treated as separate user stories and prioritized based on business value just like everything else.