Enabling choice for Agile delivery Scrum teams
As a person who this article is saying should be empowered to have more choice, choice is a dog whistle for Not Invented Here.  The people you employ to build your software will often make the <i>straight up wrong choice</i> when given the opportunity, and a lot of that time the &quot;choice&quot; will be to homebrew a solution that already exists elsewhere, because it&#x27;s perceived as simpler than taking the time to understand an existing technology.<p>The reasons that get hand waved away in this article are <i>exactly</i> the reasons you can&#x27;t ignore consistency across teams.  There <i>is</i> value in having just one library that multiple teams use to communicate via HTTP to various services, there <i>is</i> value in members of different teams being able to work across projects due to the similarities in infrastructure.  If each team has their own client library for communicating with a service, that&#x27;s work you&#x27;ve paid for twice, or more.<p>I clicked on this article thinking it would be about choice within the prioritized stack on what to build and when, because <i>that</i> is valuable.  Letting the folks building the stuff decide which things to build first is <i>much</i> more valuable than letting them pick between Postgres and MySQL, or memcache vs. redis, etc. (just examples, don&#x27;t get too wrapped up in them).<p>Sure, we can sit here and come up with exceptions to choice, and yeah I do like being able to choose my IDE, the OS I develop on, etc., but those choices are totally different than which relational database I use, or which web framework I develop with.  There, I don&#x27;t think choice is good, at least not for everyone.  Maybe this is written for my boss&#x27;s boss, I dunno.  But as for me, the dev writing the code, I don&#x27;t really want me (or my colleagues) to have all that much choice.