Skip to content

Comment on Enabling choice for Agile delivery Scrum teams

Comments

Too much chaos and choice and you slow down because everyone has done the same things in slightly different ways.

There's a fine balance between allowing choice and setting standards. There's productivity gains as well from having some standards -- you can built tools which leverage standards, so long as they aren't too restrictive.

e.x. In the world of microservices, you end up needing a lot of telemetry to keep things running smoothly and figure out what goes wrong when your call is four levels deep. Doing so is hard without having a standard to which your services must adhere to. It's easiest if you have a base application which takes care of that for you. That, however, becomes hard if you have the combinatorial explosion of [languages] x [frameworks].

That doesn't mean you shouldn't entertain new choices, (hey, team X wants to use Go.) but there should be some discipline. It boggles my mind when individual engineers prefer to speed up their development for the short-term vs. the overall organization.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.