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. -- Matt Warden http://mattwarden.com This email proudly and graciously contributes to entropy.