Instead I put together the Build, Design and Architectural Standards group, a.k.a. BDAS, which quickly became known simply as "badass". I would have included Process, which is also in scope, but then the acronym would have been BDAPS, and I couldn't have that.
Over time I will add more posts about my experiences in BDAS. Today I'll offer some advice on running a core developer meeting.
Developers can't have a frank discussion with a cop in the room
It was important for the group to be made entirely of developers. There is nothing sadder to watch than a competent engineer attempting to discover what the boss wants to hear. I needed a group that could call it as they saw it and felt they were in a room where it was okay to do so.
Have the right people
Team leads, senior developers, movers and shakers. The group is going to define standards, make recommendations and guidelines and, in the case of some, manage their own teams in implementation. It's important to have representation from all stakeholders who are involved in the actual building and maintaining of source code. That means all development teams, pretty much any group that will be committing to your SCR.
Process, process, process
If you're going to take ten people's time, an hour every week, to get them into a room and try to get opinions and decisions out of them, first bring timbits. Then make sure that everyone knows what the gig is about, their role in it and how it's going to go down. Have a standard agenda format, track items that can be closed, produce minutes in a central place and do all of it yourself. Link all meetings, resulting tickets, wiki pages, documents, code.
Today BDAS consists of a landing page, links to meetings as wiki pages simply titled "BDAS Meeting 1..n" and a JIRA project to track items. Each week, preferably well in advance, start a wiki page with the next sequential meeting number. Add a link to the previous meeting, list agenda items as links to your issue tracker, and add a Minutes header. Then as the meeting goes on update the page to fill in the minutes. A BDAS meeting page looks roughly like the following:
BDAS Meeting 20
- Review minutes of BDAS Meeting 19
- Agenda
- BDAS-1: Standardizing on autowiring and component scanning
- BDAS-3: Establish acceptable mockup formats
- BDAS-29: Review domain model support API
- Open discussion
- Minutes
- whatever comes up, link to proposal doc we created, etc
From this page link to anything else that's relevant. If you control that content then link back to it. Link to issues, source code (e.g., FishEye, SVN), vendors, whatever. A hugely important aspect of BDAS is transparency and discoverability.
If you're done, close the meeting
Nothing you do as a tech lead will get you more brownie points than ending a meeting early. If you've worked the agenda, done a round table and have nothing left in the plan then you're done for the day.
If you're not done, leave it for next meeting
Never run over. More specifically, don't be the cause of it. If you just can't stop others from making the meeting go longer than scheduled then make sure you keep trying to end it, suggest offline discussion, offer to put it on the table for next week or schedule a meeting of interested parties if it's so important, but get bodies out of the room.
