Viking laws for tech teams, part 5: agree on important points

This post is part of the "Viking laws for tech teams" series.

"Agree on important points": this sounds like a no-brainer, right? Obviously, a team won't get much done if members keep arguing and disagreeing over the same issues over and over again. Nothing to write about, then.

Really? Quick exercise: ask each team member to describe the team's operation in 5 bullet points. How many different items do you get? 5 total or 5 times the number of team members? Do the items look like the Agile Manifesto or like a checklist for code reviews? By the way, when was the last time the team actually discussed what these items should be? 

So item #0 should always be: "Talk to each other, goddammit!". No, the code is not the documentation. No, it's not enough to send e-mails (it's actually the last thing you should do). No, it's not enough to assign tickets. You guys need to talk face to face (that's IRL to you Gen Z). And debate. And argue, if needed. Whatever it takes to come to a clear and shared agreement on WTF the subject was.

Short, frequent discussions are the way to go. You don't HAVE to do a formal Scrum daily meeting, but starting the day with a quick exchange of information goes a long way. If nothing else, it creates an culture of sharing ideas, raising issues, asking for help, etc. If your only opportunity to do any of this is during that dreadful 3-hour long "Weekly Project Review" (you know what I'm talking about), then doom on you.

Okay, now that we've established that you need to talk to each other, what should you agree on? Well, that's probably the first thing you guys should talk about :) Here are a few pointers:

1. what is the role of the team in the company?
2. who are its customers?
3. what do they expect from the team? Ask them!
4. external input required by the team: what? how? how often? from whom?
5. team deliverables: what? how? how often? to whom?

'lo and behold! 5 items :)

That IS enough. If you know who you are and what's expected from you, all other decisions will follow. Tools, methodology, resources, roles, etc.

"We're the lead drakkar of our clan. Our mission is to raid the Eastern coast of Scotland for food, livestock and slaves. Loot quotas are set every semester by the King himself and he expects no less than one delivery per month. We're free to choose our own targets: a list is agreed on by the clan before setting off to sea, the actual target is picked by the crew at the last minute depending of weather and tide conditions".

Sure beats your crappy corporate mission statement, huh?

Please share your comments or anecdotes. See you next time.

Viking laws for tech teams, part 4: keep your weapons in good condition

This post is part of the "Viking laws for tech teams" series.

As much as I regret it, software engineering doesn't actually involve two-handed swords and battle axes... although managing teams sometimes does :) Still, every trade had its tools and no matter if you're chopping heads off or squashing bugs, proper tools are a key element in achieving high productivity.

First things first: the workstation. Yes, you need to give your team nice machines to work on. It's quite likely that your guys have fancy hardware at home and they won't settle for a 5-year old setup in the office. If nothing else, see this as a (de)motivation factor. Truth be told, modern software development environments *are* resource hogs and a slow workstation is a silent productivity killer (build time, freezes, inability to debug properly, etc).  Dual screens are super useful too. Throw in a fancy keyboard or mouse, too. Whatever keeps your guys working on their code is a good investment. And no, it's not going to cost a lot of money: slow teams & delayed projects do.

What about team tools? Version control system, continuous integration, unit test framework, ticketing system, wiki, etc: absolutely mandatory from day 1. Yes, even if you're a one-man team. If hosted solutions are your thing, then Sourceforge or Github are just a few clicks away. One way or the other, there's just no excuse for not setting things up properly. 'nuff said.

Next, get the best debugging / profiling tools possible and spend some time learning them (yes, you need to go beyond debugging HelloWorld). Make sure that everybody in the team is proficient BEFORE a real emergency arises. The last thing you want is having to read tutorials and installation documentation while your production systems are on fire, with management asking for progress reports every 30 minutes... You should also consider 3rd-party tools, whether Open Source or commercial: your IDE debugger will only take you so far, especially if you work on complex, dynamic systems (web servers, databases, etc).

Remember that the strongest castle will easily fall if no sentries man its perimeter. Real-time monitoring is your first line of defense, so you'd better set up the right probes in your code and make sure alerts are actually sent when something goes wrong. If you think error logs or e-mails are enough, you'll sure get plenty of opportunity to read them when the SHTF: whether you'll find the actual problem or not is a different story. You should invest a lot of time watching your systems and understanding their dynamics. It's particularly important to study how they fail (silently vs loudly, progressively vs abruptly, early symptoms, etc). You should definitely consider breaking them in a controlled way to confirm your observations and then write short documentation on how to detect and repair the most common issues.

A couple more things:

1. tools are not enough, you need the right organization and the right tactics. This will be covered in a further post :)
2. I hear some of you saying: "it's all good and true, but in my company, workstations are renewed every 5 years at best, we have 14-inch CRT screens, it's company policy to use CVS and management won't ever spend a dime on 3rd-party tools". My answer is: "these guys have zero respect for your work. Get the fuck out & find new battle comrades". Yes, it's THAT simple. Do it or stop whining.

Bottom line: one day or the other, barbarians WILL show up at the gates, preferably when you least expect it. If you have neither beefed up the armory nor trained hard enough, you will be overrun and Odin's crows will feast over your carcass. If you've done both, THEIR heads will decorate your walls and warn the next assaillants that your team is not to be fucked with.

Your choice.

Please share your comments or anecdotes. See you next time.