[thelist] setting team standards and guidelines
mwarden at gmail.com
Tue Apr 24 17:20:30 CDT 2012
On Tue, Apr 24, 2012 at 10:21 AM, Jeremy Weiss <eccentric.one at gmail.com> wrote:
> If everything goes as expected, in the near future I will be taking
> over as lead for a dev team that has grown organiclly for a number of
> years. I've been told my first order of business will be to institute
> procedures and standardize things. Now, I know how companies I've
> worked for have done things but I'm sure there are other/better ways
> to do things as well. So, I'm looking for educational resources
> (websites, books, lectures, articles, etc.) that discuss the various
> ways of standardizing these things. Anyone have any recommendations?
You've gotten good advice already on this, so I won't add to that.
What I will add, though, is just an item about adoption. If you've not
done this sort of thing, you will quickly find out that having "the
best" procedures isn't enough justification to get anyone to follow
them. The dev team members aren't all doing their own thing just to
annoy management. They have their reasons, and frankly it doesn't
matter if they're wrong. Getting adoption by convincing everyone
they're wrong is tough.
* If exec mgmt is bringing you in to establish procedures, there needs
to be some kind of clear communication of that to the team. You're a
nobody to this team, and they need to know you have authority from
upstairs and this wasn't just your idea and isn't just you trying to
make a name for yourself. (That said, in my opinion it is best to let
this establish authority as a foundation and then try to catch the
flies with honey)
* Why are you asking us in the first place? I'm not on your team and
I'm not going to have to deal with my silly recommendations, like
having the team sing Bohemian Rhapsody before every check-in. Yes, do
research and have ideas on how the processes should work, but then
have this conversation with the team, have everyone collaborate, and
your role would be to guide them in the right direction. Outline the
objectives (i.e., Martin's list) to structure the conversation.
* You don't have to get it 100% right the first time. This means you
can make mistakes in picking the right procedures. It also means that
if you aren't getting agreement on something you think should be done,
you can consider letting the team make its own mistakes (depending on
what we're talking about, of course).
The point isn't: be a softie. The point is that if no one follows your
totally awesome processes, you failed.
This email proudly and graciously contributes to entropy.
More information about the thelist