Trying to build an effective software development team ? Here are some key elements that might help you.

The JavaDoc has a @author tag that can be used to assign a programmer at the overview, package and class level.
As a software engineer working in a team I never liked this tag.
As I became a development manager, my unlikeness increased even more.
This feeling is fed by negative impacts on both the “Collective Ownership” and the “Bus factor”.

I have been recently promoted to manage a division in software development department of my company.
Till then I was used to managing one team at a once, not exceeding 10 people in size.
Now I find myself with 8 teams to manage having each a size ranging from 4 to 7 people.

In my previous role I was comfortable with adopting the SCRUM agile framework and quite used to play the role of the scrum master and to participate actively to the product owner role.
Some of the new teams were already trying to follow the agile practices, some were still working with rather a traditional waterfall approach. So naturally I found myself driving the teams to adopt the SCRUM framework. I made sure to share with them my return on experience and to point out the pitfalls and the small details that can make a difference.

Fortunately for me the resistance to change was less than expected.
All the teams were eager to try the new framework and to improve their agile practices.
This is when things start to get a bit more complicated.

Just one full week in my new job, that’s what it took me to experience a new kind of sport, the “Meeting Run”.
And as a good friend of mine would say, like everything there are always two sides.
In what I experienced I encountered a good one and a bad one (and no there’s no ugly one, at least not yet).

I enjoyed reading the book Driving Technical Change: Why People on Your Team Don’t Act on Good Ideas, and How to Convince Them They Should by Adobe software evangelist Terrence Ryan.
It made me recall of a lot of situations I encounter in my daily job. I also discovered new approaches that could come in handy in the future.
I recommend it to any person having a role to play in a software development division.

Here’s my takeaways cheat sheet.

As a distributed agile team working from Paris and Beirut, remote retrospectives are part of our rituals.
To conduct these remote retrospectives, we have settled on using Trello.
My colleague BOURGAU Philippe has blogged on what we tried and how we ended up by opting for Trello.
Since then we have made some improvements on speeding up the meeting preparation, and I think it’s time to share them.

A couple of years ago I bought the Motorola Xoom 2 for my personal usage.
It was my first Android tablet and I mainly planned to use it to make Skype calls, browse the Internet and read some e-books. We also used it to play nursery rhyme videos to our last-born.
As he grew, he was convinced that it was “his” tablet and started to play games on it.
It didn’t take him long to figure out how to look for YouTube videos or to install new games, this is when troubles started.

I recently acquired an Amazon Fire HD 6 tablet.
I had high hopes that it would be the perfect tablet to read books, use Skype and check mails.
I found its price attractive with respect to its characteristics, and being an old customer of Amazon I was confident that the tablet will meet my expectations.

A year ago, while participating to an off-site workshop, a colleague wanted to show a new mobile application prototype.

For this purpose he needed a phone to reach both the internet and a laptop hooked to the local network.
Since wireless connection was not available the demo was at risk.

I’ve recently tried using Meteor to build a web application.
I used Iron.Router to configure the different routes of the web application. Everything worked fine out of the box until I started using links with fragment identifiers.