Human Driven Development

IT manager role consists, among other things, to improve team productivity, product quality and to help the teams to get things done. That should sound basic, but for me, the only way to reach that goal is to focus on the human side. There’s no rocket science here, but behind each line of code, there are human beings in a specific mood, working in a particular condition.

We are using Scrum and some of the XP practices, which means that the business value and the agility are already in our principles. However, here I’ll go through some measure I took with my teams during the last few years to improve their working conditions and put the human in the top priorities on top of existing agile methodologies.

Flexible working hours

In Europe, flexible working hours, 24/7 office or telecommuting are not (yet) standard practices. Culturally, we are more used to see traditional 8 to 5 working hours, and we are not an exception.

The majority of my team lives in France near the Luxembourgish border in within 40 km. They are crossing the border every day to come to work, spending on average 30-60+ mins in the traffic jam. You could imagine the stress level and the mood you are in when you start the day by that adventure. Requiring all of them to be in the office at 08 a.m. on the dot is like to ask them to waste another additional hour in their car.

I know that they decided to stay in France, but giving them the flexibility to modulate their day by few hours make their travel a bit easier. They decide when it’s the best moment to leave home to optimize their journey. Even with this shift, they remain available for the rest of the company most of the day. Since it does not impact our organization and does not cost us a penny, this is a 100% winning solution.

The side effect (or by-product) of this is that we have increased our hours of operation from the usual 9 hours to 12. Now I always have someone in the office in case of emergency between 7 a.m. to 7 p.m.

Keep the team fresh

Part of the traditional working hours, we still have this assumption that working more than 8 hours a day shows your commitment to the company and gives you the hard worker “title.”

After some analysis of previous sprints, I can confirm teams which accumulate overtime hours are not as fresh as usual. Basic tasks take longer to achieve, bugs on new features increase as the time spent to understand the “yesterday evening code.” On the long run, burning the midnight oil is anything than productive for the company.

Since we agreed that we use overtime only for exceptional events (none in 2012), the time spent on maintenance decreased significantly, and the on-call interventions due to bugs are getting closed to null. Moreover, the side effect of that is that the team is in a way better mood and it reflects in the ambiance.

Good hardware and furniture.

“Hardware is Cheap, Programmers are Expensive”, that’s why is better to invest in good hardware and often renew than having developers waiting while their program compiles. It’s essential for our brain to prevent interruptions, and this kind of break kills our thoughts flow.

Another critical point is the comfort of our employees; we spend at least 8 hours in front of our desk, good chairs, tables, and screens are necessary to preserve our bodies from long-term pains.

We chose Dual screen setup to spend less time switching between apps, for example having the editor side by side with the browser. Concerning the screen size with opted for a minimum 24” full HD to maximize the context visualization while coding by seeing more lines and being able to open 2 editor panes side by side.

Here’s some facts about our configs:

Dev on Linux: 24” Dual screens + desktop
Dev on Mac: iMac 27” + 24” external screen
Scum masters: Macbook pro 15” + 24” external screen
Everybody: 12-16go of ram, 500go disk
Machines renewed every 4 years

Environment freedom

Operating System, IDE, editors, keyboard layouts…? Excuse my French, but we don’t give a S**t! A developer should be free to make his own platform choices if they are compatible with the company’s goals. I’m not saying here let them try and wast company time learning the Dvorak keyboard on a blank mechanical keyboard, but let them use what they are familiar with and let them get things done.

My teammates are under UNIX based systems, 80% macs 20% Linux, and that’s their choice, not company’s. Why should I bother them and myself with another layer of rules when I consider that each developer should be free to use the toolset he’s the more efficient and that makes him productive. Aren’t they supposed to be power users? They are professionals of the field, supposed to know what they’re doing and capable of justifying choices if required.

I know that some corporations need have homogenous workstations to ease the system administration of hundreds or thousands workstations, but startups and SMB have no excuses and should let developers be the administrator of their machine. Why can’t we trust a developer on his workstation, when we give them access to production machines and databases systems or let them commit to the core business system?

We should not notice any distinctions between the code written on a different machine since we have common formatting and encoding rules and peer reviews every line of code before merging. That’s the only thing which matters!

Courtesy

I never start a day without walking around our team to greet them and to see how people are doing. It gives me an early notice if something is bothering them, for then having a quick chat about it.

It sounds a bit cliché, but I always try to take the time to thank people personally. I’m always making this sarcastic joke to my guys “Thank you for doing the job you’re paid for!” but I was disappointed to see that’s the way some people think. This behavior affects the team’s motivation directly when it’s shared and repeated.

I’m not saying that the relationship should become aristocratic, but you would be surprised by the effect on the team building and the collaboration a simple “hello” and “thank you” could bring.

Quiet working condition

The quite working environment is for me a top priority impediment. Knowing the cost of interruptions on your brain when you are focused on a task, this is for me the biggest issue that limits and slows down productivity. I should confess that this is still the hardest to get installed when you are working with 100 people in an open space.

Comings and goings in an Open Space lead to a lot of low priority interruptions. My teammates and I tried several technics like wearing a headset while doing a Pomodoro, but it always matters of how the requester considers his question or remark pertinent.

Sometimes, the noise is coming from an improvised meeting near the coffee machine, laughs from your neighbor department or simply loud phone calls from a colleague, for this, there’s no other solution than asking people to make proof of common sense and respect against there co-workers.

One of our scrum masters pointed me out that there are several kinds of “noises” from his point of view: there’s noise, and there’s signal. Signal, coming from teammates talking about business-related activities, and the noise which is not familiar to him directly (sales on phone, trade of preparation meeting, …). I could get this, but we should try to keep targeting the “Library rules” as described by Jason Fried.

Decent Salary

Decent salary, that’s a vague term. Decent salary, in my vision, is not the fact that you have more money than the average wage, but overall of your working conditions and the value of each. If for a higher salary or advantages, you have to do things like :

be connected 24/7 on your smartphone
work late, nights to finish
never take rest from work
barely see your family

… then your hourly rate and conditions are far from being optimal, and it’s all about life balance.

Developers already came to me to tell me frankly that they received higher offers elsewhere but the flexible working conditions are something valuable in their package.

However, we try to keep salaries aligned with the market to keep our team attractive and retain our existing team. I’m happy to see that the current team have in average 4 years of seniority (between 3 and 6 years). The global package makes them loyal to the company.

Conclusion

Developers are part of this few percentages who choose their job by passion, and love what they do and feel committed to providing a better product unless you apply with them micromanagement. With this kind of profile, it breaks their creativity completely by showing them only the top of the iceberg when they need to see the big picture. Give them more flexibility, you will notice the benefits shortly.

By the way, if what I’m describing is interesting you, we are hiring, so feel free to send me your application ;)