
Enabling choice for Agile delivery Scrum teams - dwiamo
http://tonymaley.com/choices/
======
heisenbit
Creating software is about making the right decisions at the right point in
time. Any decision by nature restricts choice. It is precisely the job of CTOs
and architects to make decisions about partners, platforms, tooling and
frameworks and to refrain from making these decisions at other times.

Should you empower teams to make their stack choices? I've seen chaos breaking
out for a year in a major development organization with 500 devs when most
teams suddenly were allowed to make some choices that better should have been
made centrally. Yes, they were faster but they were faster going nowhere. And
then there are all these aspects that go beyond the development phase - long
term maintenance, behavior of software in the field / training field engineers
and moving people across teams.

Good technical leaders know where choice is called for and where not. Managing
these trade-offs requires a perspective that goes beyond the agile team.

~~~
ChemicalWarfare
I would add that one way to gently enforce the stack when the system is
getting built from scratch is having a solid end-to-end
"POC"/"skeleton"/whatever you want to call it built by a senior architect
before the rest of the team is brought in.

Sure this requires an "architect who codes" type person to be involved (which
can get expensive), as opposed to some ivory tower powerpoint architect but is
typically worth it.

------
Xorlev
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.

------
cookiecaper
Everyone should know about Conway's Law [0], especially in the age of
microservices.

I currently work in an environment where there is virtually no central
technical management. There are groups of 2-4 developers who roam around their
department's problem space, making whatever choices they want.

If someone doesn't like the interface on one microservice, they fork the code
and make a new one. This leads to 5 microservices that accomplish the same
thing, and 5x the maintenance burden whenever something changes. I've
derisively called these "nanoservices", but I need a more offensive term.

People intentionally choose techs that no one else in the company has used,
trying to cement their position and hedge up potential competition or
unwelcome cooperation. They also select technology for the best PR effect,
being able to say "We're being like Google today". The result is a whole mess
of different stuff running throughout production, each needing _its own_
backup system, etc., which, to be honest, does not always get installed.

It's a disaster.

The author's contention is that giving more choice to teams is better because
it makes them feel more ownership in their product. That's fine, but do
recognize that this is a psychological solution to a management problem. The
job of the manager is to actively control the psychology of employees and the
structure of the organization such that employees are happy to do things that
lead to cooperation, not to allow employees to always get their way.

Without a central coordinating force and everyone's acknowledgement that some
compromise and sacrifice is necessary, everything falls apart quickly.

[0]
[https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)

~~~
dkhenry
Conway's Law in your environment should probably be interpreted that you have
a team that can't talk or work together at all. It has nothing to do with what
technical choices they are making, even if you imposed a rigid technical
structure you would still have divergent nanoservices because your team can't
communicate.

~~~
cookiecaper
No, it's not that they're incapable of working together. It's that they have
no incentive to do so. They can do whatever they want now and improve their
own positions by so doing, so why shouldn't they?

Normally, people don't do this a) because they don't want to be required to
deal with the cruft or b) because they believe someone will observe their bad
behavior and stop it. They don't really have to deal with the cruft, and it's
clear now that no one in this organization will hold them accountable, so why
should they waste time and energy trying to build a consistent platform?

re: Conway's Law, the organization's communication mechanisms are loose and
ad-hoc; there is no central coordination. Consequently, the software is
coordinated on a loose, ad-hoc basis between small teams. The same featureset
will be implemented 4 times by 4 different teams, not because they _can 't_
talk (there is an office where most people hang out together all day, and
people do generally keep an awareness of what the other group is working on),
but because they'd rather just do it the way they want to do it.

It's not that no one ever ends up sharing anything. It's just that instead of
having a discussion and making consistent decisions about the platform, they
just do what they want, because they can.

~~~
dkhenry
Even if you imposed a singular stack, I could just do it my way at whatever
level you started to let me make decisions. All you end up doing is adding
overhead to your basic problem which is your teams are not communicating, fix
that problem and your tech stack becomes irreverent. People will start to talk
and start to organize into best practices simply because its easier ( why
reinvent the wheel if Jim in accounting already did it and I can just use his
stuff )

~~~
cookiecaper
Yeah, but again, the people aren't necessarily mean-spirited or hostile.
They'd cooperate more if the structure to affect that existed.

You're acting like they don't talk. They do talk, they just don't care. They
know that guy x is making thing y, but they don't want to do it in the
language/platform/framework/whatever he's using, so they make their own thing
y. Structure needs to be in place to make cooperation happen.

~~~
dkhenry
No it doesn't. If thing Y was remotely complicated and if the teams had a good
working relationship why would they choose to duplicate their work. Even if it
was in a completely different tech stack you would still try to leverage
someone else's work and there are plenty of ways to do that in almost any
situation across most technologies. Also even if a rigid structure existed I
can still not use your thing Y most likely because I don't respect your work
and I would implement thing Y differently ( and in my opinion better ). Then
you get thing Y and thing Y+1. The problem isn't people chose different tech
stacks its they don't want to work together. If they did they would choose
tech stacks and work practices that foster collaboration.

~~~
cookiecaper
>If thing Y was remotely complicated and if the teams had a good working
relationship why would they choose to duplicate their work.

So many reasons, but they usually boil down to simple self-importance.

Also, remember that it's harder to read code than to write it. Any non-trivial
library or service is going to have a learning curve.

>Also even if a rigid structure existed I can still not use your thing Y most
likely because I don't respect your work and I would implement thing Y
differently ( and in my opinion better ).

Everyone has their own opinion.

In a rigid structure, this perspective wouldn't work because your paycheck
would be imperilled by it.

>The problem isn't people chose different tech stacks its they don't want to
work together.

Sure, I agree. In a correctly organized structure, their incentives would
change, and their behaviors would be more cooperative.

>If they did they would choose tech stacks and work practices that foster
collaboration.

No, that's like saying if people wanted unity, they'd make choices everyone
would agree on. Everyone wants unity. They just everyone to unite to _their_
idea of what's important/right.

Management is all about crafting an environment and structure that causes
people to work in a productive way. That _could_ happen in this company, but
it hasn't.

------
diminoten
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 _straight up wrong choice_ when
given the opportunity, and a lot of that time the "choice" will be to homebrew
a solution that already exists elsewhere, because it's perceived as simpler
than taking the time to understand an existing technology.

The reasons that get hand waved away in this article are _exactly_ the reasons
you can't ignore consistency across teams. There _is_ value in having just one
library that multiple teams use to communicate via HTTP to various services,
there _is_ 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's work you've paid for
twice, or more.

I clicked on this article thinking it would be about choice within the
prioritized stack on what to build and when, because _that_ is valuable.
Letting the folks building the stuff decide which things to build first is
_much_ more valuable than letting them pick between Postgres and MySQL, or
memcache vs. redis, etc. (just examples, don't get too wrapped up in them).

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't think choice is good, at least not
for everyone. Maybe this is written for my boss's boss, I dunno. But as for
me, the dev writing the code, I don't really want me (or my colleagues) to
have all that much choice.

~~~
dkhenry
Its interesting trying to figure out from your comment what kind of people you
intend on working with. On one hand you conclude that given the opportunity
your employees will wake the wrong choice. So if you can't trust them to make
good decisions what do you trust them with? If they can't make tooling choices
can they make algorithmic choices, if they can't make algorithmic choices can
they really decide what kind of language constructs to use.

If I can't trust you to make a good choice on which technology to use why do I
think I can trust you to make good choices in other aspects of your job. If
you don't feel confident to make a technical choice then what you are telling
me is you don't understand, and don't want to learn. Not really a desirable
quality.

~~~
diminoten
I don't have the information to make the "right" choice, because I don't
attend the meetings you do, I don't generally care what happens when a new
hire gets here, I don't care how the company spends money on writing 3
different client libraries, etc. Those aren't decisions that are tied to my
compensation, my quarterly goals, and leadership doesn't come for my head when
they find out about the bill they're paying for.

My expertise is in designing and building software, not in organizing teams
for optimal productivity. The tools and tech that make the most sense for my
project will get me to 100% optimization, but if I pay down a 5% optimization
cost to bring all teams in my organization 80% to 90%, a _manager_ should be
the one making that choice, not me.

Pretending like everyone has the visibility into the org like you do _will_
get you into trouble, and giving that visibility to everyone _will_ harm their
ability to focus on their jobs. I'm not a manager for a reason, I don't want
to make those choices, but I _need_ someone to.

Also, not everyone gets to work at Google. Advice like this needs to have
value at Medium Sized Company, Inc., because those are the people who are most
out in the cold. An Apple product manager has every tool on the planet
available to him/her to figure out how best to help his/her team, but the
guy/gal managing a dev shop in Carson City might not.

~~~
dkhenry
The choices a manager makes are very different from the choices a technologist
should be making, and its not about what tools or tech stack you are working
with. It is about things like how do I enable my team to deliver, because one
thing people love to do is see how they can make excuses for failure to
deliver. At the tech level its about how leadership and management makes poor
choices, at the leadership level its about how your workers are lazy and
unable to perform under such and such a condition. In reality its both parties
trying to insulate themselves from failure by having a scapegoat.

Empower your tech teams to do great work, it doesn't require you to be a
google or apple, or podunk startup. I have seen empowered teams at 10 man
contact shops and 100,000 fortune 100 companies. If you run into a company
that tries to tell you something else run away, you will find politics and
infighting alongside terrible technology and an inability to deliver

~~~
diminoten
If you let your teams individually choose their tech, they will be empowered
to duplicate work, and they won't be able to cross pollinate or provide
expertise/support to any team that's picked a tech stack different from
theirs.

Doesn't this just encourage silos?

~~~
dkhenry
If the teams are working on similar problems, and if the teams actually work
together they will stabilize on a singular stack. There will be cases where
work will be duplicated, and there will be cases where tech components need to
be refactored because the stack has changed, but you will end up with a very
well known and understood set of tech primitives that your services are built
out of.

There are lots of reasons why you may never hit that state of everyone self
selecting the same or a very similar stack, but they are never technical and
they always indicate a team structure problem that is going to cost you way
more if you don't deal with it then the amount of duplicated work you might
encounter

------
quantumhobbit
Wow the comments here certainly seem to be against allowing developers any
input in the tools they use. I guess you all are part of the reason I have to
use Java 7 and outdated versions of Angular in my day job no matter their
applicability to the problem domain and have no input in those decisions.

I agree that total anarchy is bad in the workplace, but don't you think that
the people using the tools should have some input in choosing the tools?

~~~
yawz
I, for one, want to see something beyond the shiny-toy syndrome when I talk to
a team member about why we need to use the tool/technology/framework/library
in question. I'm all for personal improvement, and every technology,
regardless how different it is, that we learn/become familiar with makes us
better professionals. But sandbox to production is a long way. Keeping things
simple has its merits.

------
dkhenry
In my experience the team should be free to make whatever technical choice
they want. The only reason you get dictation from on high about what choices
should be made is because your technical leadership lacks the technical depth
to advocate for a common stack that is actual useful. Every time I have seen
an origination talk about standardizing on some language or framework and its
hasn't grown out of the engineering community at that company its been because
leadership didn't have a strong technical background and they were making
choices based on marketing material, sales reps, or consultants.

The best standardization I have seen grew out of a team who was empowered to
make decisions, made good decisions, showed how their decisions were good for
the entire origination and helped everyone migrate to one solution which
turned out to be pretty good at solving everyone's problems.

If you as a leader find yourself pushing a standard tool set to a team who is
hesitant to adopt it the problem is most likely you.

~~~
cookiecaper
You assume that everyone in the company is acting rationally, and that
everyone has the same goals and values. This is usually not the case.

The truth is that for most types of applications, there are several technology
stacks that would be perfectly adequate. You get into the tradeoffs, and
unless the benefit posed by a specific thing is immediately obvious, these are
a matter of subjective judgment. Great technical minds will have differing
subjective judgment; no one's judgment is exactly same as another's.

People also usually do not understand their own motives. This is the origin of
fads. Everyone suddenly agrees that THING_Y is the best, and then, the next
year, everyone suddenly believes it's THING_Z now. If someone can present a
dense, semi-passable argument in favor of it, the rest of the uptake comes
down to marketing. This is true _no matter how smart you think you are_.

If you have a technician who prides themselves on always knowing about new
technologies, and that's their reputation, it's likely their primary
motivating factor will be continuing to propagate that self-image. They might
not even realize it.

They will come and say "There is a new tech called TECH_X and it allows us to
do these amazing new things!" As long as TECH_X has _some_ value proposition
and isn't a blatant or obvious bad fit (meaning obvious and blatant to
_everyone_ ), their argument is plausible enough and they'll run with that.

They think they're doing this because they learn all the new things and it
gives them a competitive edge. In reality, it's because they view themselves
as cutting edge, they want everyone else to view them as cutting edge, and
need to feed themselves and everyone else some proof validating that desirable
conception.

The difference between "political schemers" and your average employee
generally comes down to their naivety around the universality and importance
of these functions. Which is another danger -- the less-naive employees in the
ranks will be actively working their own angles here to attempt to manipulate
the psychology of the people around them. This can and does invade technical
choices. You can make the best arguments in the world for your stack, but if
you have a political competitor, they will work to undermine you, often in
non-obvious ways. If they feel now is the time to strike and they can
embarrass you, they'll do so; if not, they'll agree and subtly work to
sabotage your plan.

There's another type of employee here; the type who wants to keep his day job
on cruise control, and will oppose anything new because it would make his
short-term daily existence more difficult (and perhaps long-term if the
improvement could reduce inefficiencies so much that he becomes redundant),
regardless of organizational benefit.

There are many arguments to be made in favor of keeping the status quo, so he
will look OK; if your new stack is a wild success, he will be able to say "Oh,
I just needed some time to come around" and if your new stack is an abject
failure (which happens much more often than people wish to admit, and even
more often, it's made to _appear_ an abject failure by political competitors
regardless), he will be able to say "I told you so".

People are naturally self-interested and will behave that way all that time.
Management must look outside of the individual goals of the employee or team
and consider what is in the long-term interest of the organization.

tl;dr This is naive; a purely democratic approach doesn't work because
people's goals and values don't necessarily align.

~~~
dkhenry
What you have just described is the political reasons for not giving your
employees agency in making their own decisions. Technically, while each stack
might provide similar value proposition, familiarity and experience with a
given stack are an organizational value that even given two equals would cause
any rational person to pick the known and understood stack. Essentially you
nailed the facts with your first line. If everyone is rational and had the
same goals these things sort themselves out. Problems arise when people are
not acting with the same goals or values, and on occasion they are not acting
rationally ( it has been my experience that differing goals and values are so
frequently the cause that assuming irrationality is just noise you can ignore
)

So given people with differing goals and values they come to different
conclusions about how to pursue those goals. Unless you hire sociopaths most
of your employees will want the firm to do well and work with functional tech
stacks that accomplish the stated goal of the company. However people in tech
leadership don't always share that goal. They make decisions based much more
on personal utility then the average worker. They might sign that sweetheart
deal with a vendor because they see it as an avenue for a career change in the
near future, or they might want to make sure no one below them starts to
outshine them so they keep the stack something they understand ( knowing full
well that someone not in leadership has much more time to persue learning ),
or they know if they force an outdated but well known stack they can hire
cheap.

In general none of those conditions are good for people actually doing the
work and they know it which is why they push back. It gets propagated up the
stack as naivete or fad chasing, but in general its leadership insulating
their position ahead of the company or their co-workers. Those leaders fail
and those companies fail. When decisions like this are pushed down from on
high look out, its generally a sign of bad culture and a bad company

~~~
cookiecaper
>Technically, while each stack might provide similar value proposition,
familiarity and experience with a given stack are an organizational value that
even given two equals would cause any rational person to pick the known and
understood stack.

This is not at all the case. There are many rational arguments to be made for
abandoning an outmoded-but-already-in-place practice or stack, regardless of
the knowledge base that already exists in the company. Many people could and
would suggest a conversion to a new platform in good faith. Sometimes this
would be the right decision, and sometimes it wouldn't; it really depends on
the particulars of the organization.

> If everyone is rational and had the same goals these things sort themselves
> out.

People are not always going to have the same goals. You can't limit your
organization to a subset of people who are all ideologically aligned.

Also, people frequently don't understand their motives for something; that is,
they ascribe some rational-sounding reason to behaviors they are biologically
driven to perform. They may fully believe their goals are aligned, but come to
find out, they're not.

>Unless you hire sociopaths most of your employees will want the firm to do
well and work with functional tech stacks that accomplish the stated goal of
the company.

Sure, and since there are many tech stacks that would do well, this doesn't
mean anything. People can disagree. When they disagree, the subjective
judgment on the tradeoff must be passed up to a central authority.

>However people in tech leadership don't always share that goal. They make
decisions based much more on personal utility then the average worker.

You're grossly overestimating the "average worker". The average tech workers
wants to keep his job simple and easy so he can browse reddit all day at work.

You also assume that these things don't factor into the decisions of average
workers. They do. Some workers aspire to be leaders, and, less naive about
human nature, are willing to employ some showmanship and artifice to get
there.

>In general none of those conditions are good for people actually doing the
work and they know it which is why they push back.

None of the conditions you listed are good, but mature technical leadership,
including standardization on a reliable stack (and, of course, a willingness
to make rare-but-justified exceptions) is a boon to all.

>It gets propagated up the stack as naivete or fad chasing, but in general its
leadership insulating their position ahead of the company or their co-workers.

There is a great deal of naivete and fad chasing everywhere, inside and
outside of leadership. The ability to recognize it is valuable.

>Those leaders fail

Quite the contrary. Leaders do these things because, as long as one maintains
plausible deniability, they are rewarded richly.

>and those companies fail. When decisions like this are pushed down from on
high look out, its generally a sign of bad culture and a bad company

Companies that understand human psychology, both in the public and in their
employee base, are extremely successful, because ultimately power comes down
to the consent and resources of others. They are also usually the companies
people most want to work for.

------
rb808
Too many technologies is a problem so teams shouldn't be able to choose
anything. My wider team is 50 people made up of ~8 smaller teams. We have some
flexibility to choose technology with the result of our new product: * Core
system JVM * Python wrapper for web service API * C# scraping calling the web
service * JS/node webserver calling the C# layer

As a result its slow, messy and difficult to maintain. Would be nice if
managers prevented small teams from choosing any technical choice they felt
like.

~~~
yawz
_> Would be nice if managers prevented small teams from choosing any technical
choice they felt like._

That requires knowledge, experience, and good technical & business judgement.
Unfortunately not everyone has these qualities. Refusing something simply for
keeping things as they are is not a sustainable strategy in technology.
Decisions have to be made smart, and they have to contribute to the
incremental improvements.

------
MaulingMonkey
I don't have a choice: I _must_ use a broad array of tools and languages.

The gamedev stuff I've helped tackle fundamanetlaly required mostly C++... and
a little C, and some x86/ARM/PPC for debugging, HLSL 3-5/GLSL ES/PSSL/<custom
shader DSLs> for porting graphics, at least two shell scripting languages for
CI servers (Bash, and Powershell or (ew!) Batch), Python (for various modeling
tools)... Java, Objective C, and C++/CX for platform specific APIs... MSBuild,
Makefiles, Gradle, Ant... and that's just the languages! The tooling front is
no better.

A handful more language choices that theoretically could've been avoided (e.g.
C# for tools and server stuff, ActionScript for UI) is really not that big a
deal in this context. You can add pointless layers of cruft, but I've only
seen it once - a Python script used to hack up the result of a C++ program.
Even then they had a reason: some of the C++ didn't get checked in, so we
couldn't even build the C++ program. (A happy ending: With a little reverse
engineering of the resulting binary output, I was able to re-implement the
missing C++ bits, implement the Python-script 'fixes' more cleanly in the
original C++, and add my own necessary changes on top of that.)

------
karka91
I work for a shop with more than 200 devs. Over the years we had multiple
efforts to standardize the libraries, platforms we use only to very limited
success. While things like CI software and IDE got pretty much standard
without any intervention to this day there is no consensus for library x to do
y. The overall sentiment resonates with me and what I've seen at my workplace

------
nradov
He seems to be ignoring long-term maintenance costs. If you're building a
$0.99 app then sure let the team pick whatever they want. But if you're
building a huge SaaS web application with an expected 20 year lifecycle then
that cuts the range of sensible choices way down.

------
Zigurd
Choices break naturally on time and platform boundaries. New projects should
review stack choices, and enforcing cross-platform stacks is usually too
brittle.

------
gm-conspiracy
Creativity leads to anarchy.

