Introduction
This presentation rocked. This is only my personal advice and is completely subjective. Anyway, I’ll repeat it: this presentation rocked.
Everything was there: good slideware, an interesting and well-structured content and, last but not least, a smiling and entertaining presenter.
Sven Peter (@svenpet) presents himself as an Atlassian Ambassador.
Let’s go and see what this guy had to say.
About programmers, employers and change
The programmer heaven can shortly be described as working in a kick-ass team to develop a kick-ass product.
What big companies are doing in hiring great people and paying them bonus of all kind… to finally put them in jail and force them to follow strict rules.
So what can we do?
Starting a revolution… and being at high stakes of losing our job?
Complaining. Not very effective.
So the idea is to “be the change you want”.
But don’t be a fool. The changes have to be profitable for everyone. The developer. The company. And don’t forget your customer. So for every change you want to implement, be sure to measure the change impact and to use time boxes when appropriate. You want to be seen as the guy who brought smart changes. Not as a cowboy. But even then, be prepared to fail. As that is inherent to great ideas. Some of them works. And then there are the others.
Tips to improve your team
Following are 7 things that we can do to improve our team spirit and productivity. These have been tested at Atlassian. Remember that this doesn’t mean they will work for you or that there aren’t other (even better) ideas to try.
Flow time
Let’s define flow time as an uninterrupted time period you get to do your work. No urgent email, no phone call and noone to disturb you. This is the time when we programmer are the most productive.
The ideal is that we can work alone in a closed-door office. But right now, companies are building large open-space landscape working place. But then there is still hope.
- You can define a “Do Not Disturb” time
- You can elect someone in the team as the single point of contact so that other teammate are not disturb
Both of these require some degree of collaboration and maybe some visuals to clearly state who to contact and when not to bother the team.
Score: 4 out of 5 feasibility points and 2 out of 5 awesomeness points.
Feed your brain
A developer’s brain is always hungry. So you’ve got to feed it. Here are some ways.
- Attend conferences. Some take multiple days (Devoxx), some are scheduled after work (BeJUG, BruJUG or any other user group you’re interested in).
- You can organize coding sessions or dojo’s in the evening too. Even if it’s true that people often have other occupations then.
- You can organize brown bag sessions during lunch time. These take no spare time and no business time. Except of course the time needed to prepare it.
- And if you cannot even afford the time to prepare a lunchback, you can organize video watching (http://parleys.com for example) during that same lunch time.
Score: 5 out of 5 feasibility points and 2 out of 5 awesomeness points.
Say “Well done!”
Appreciation, even of small things, is important for happiness. And to carry even more effectiveness, it should be made easy to say thank you publicly to everyone without censorship.
Score: 2 out of 5 feasibility points and 3 out of 5 awesomeness points.
Report robot
We should record and report over everything possible. We can make reports about time, features, code reviews, velecity, sales, web traffic, support cases, interviews, …
Those facts can be recorded easily in databases and reports generated automatically. Those automatic reports can then be displayed on information radiators (i.e. large screen in the hallway).
Score: 2 out of 5 feasibility points and 4 out of 5 awesomeness points.
Eat your own dog food
Everytime it’s possible (come on, there’s always a way to do it) we should use the product we are developping by ourselves. Meaning developers team should be its own alpha tester.
Acting as your customer make you more akin to understand her.
Even if using your own tools will often prove to be painful, this is the shortest way to get feedback. This will allow you to use less QA and to use it better.
Score: 2 out of 5 feasibility points and 5 out of 5 awesomeness points.
Do a special day
Over time, we tend to accumulate a backlog of unpleasant things. So it’s sometimes useful to forget about the current sprint for a day and have a special day to empty this backlog.
Exemple of special days are:
- 1-day doc sprint Developers spend one day to write as much docunentation as possible with the help of technical writers.
- 3-hour blitz-test Developers get 3 hours to test as many things as they can. Their sole aim should be to find as many bugs as they can.
- clean up day Developers get one day to clean up everything about the application.
The purpose of those special days are to put stuff out of the door and keep the focus on the sprint the other days.
Score: 5 out of 5 feasibility points and 3 out of 5 awesomeness points.
Experimentation time
At Atlassian, experimentation time is declined in multiple ways.
Ship It days
Ship it days are some kind of hackathon.
2 to 3 weeks before the Ship It day, a brown bag session is organized to gather ideas and federate teams around them.
2 days before, a mini sprint planning meeting is held to organize the work on that day.
On the Ship It day, teams are working non-stop during 24 hours to deliver something. At the end of those 24 hours, each team is given the opportunity to present what they’ve done during a lightning presentation and a winner is voted for.
These days are a cool way to foster the innovation and make your nerdy developers happy.
20\% time
Each team member is given 20 % of his work time to explore. This time is reserved for innovation. This time is independent altough it must have something to do with the company business.
This kind of policy can create conflicts. People may be needed by others while on their 20% time. The workload may be too high so that people themselves cut it out. The sprint goals may be put at risk because of it.
So sometimes it is more manageable to turn those 20% time into an innovation week.
The score of both Ship It days and 20% time: 4 out of 5 feasibility points and 5 out of 5 awesomeness points.
Conclusion
Here are some interesting ideas to try. So let’s try to put at least some of them in practice. But remember that they can fail too. So take precautions. Measure the impact. And make it one step at a time.
The presentation slides are available at http://svenpet.com/slides.
frroland 