HN user

ProfMeowsworth

26 karma
Posts0
Comments15
View on HN
No posts found.

electrified, so that your daily commute is efficient and environmentally friendly.

Moving an off-road vehicle of over two tons to transport (usually) one person to work seems neither efficient nor environmentally friendly. The vehicle being electric doesn’t change that, as the electricity has to be generated somewhere.

I’d say that it depends on who you ask when it comes to what’s „common sense“ and what’s „a way that works“. What I have seen working is:

- Have somebody who is responsible for understanding the customer from a business perspective and be able to explain that to developers in the form of prioritized development items.

- Try to build something that works to confirm your assumptions and manage risk, ideally on a short-ish cycle of a few weeks. Always keep a working product. In some projects this is not (immediately) possible - in that case, it’s probably better to run a traditional waterfall-project, with the tradeoffs that come with it.

- Get together regularly to talk about less immediate topics and improve the work process.

- Plan and make forecasts using actual data from the past, not wishful thinking.

And that is basically Scrum. For me this is common sense, I wouldn’t know why you would do it in another way.

How it’s implemented in practice differs and it seems a lot of places don’t implement it very well. So far I haven’t heard many good suggestions from the developers suffering under these implementations on how to make it better though, hence my question.

The whole point of Scrum, in my opinion, is to create a working increment in the sprint. That’s the mechanism for managing risk. Finishing tickets for writing specs don’t achieve that. Unfortunately, it’s a common practice though.

To be fair to “Clean Code”, although it’s stance is clearly towards less (superfluous) comments, it recommends using doc strings to document intent.

What it recommends to just delete are comments like

  var speed # the speed

The purpose of the Daily Scrum is not for the developers to report what they did yesterday and what they will do today. Manager, Scrum Master and Product Owner are all not participants of the Daily Scrum. Velocity is not a metric for reporting but for the team to plan their work.

What is your Scrum Master doing?