While going through Crucial Confrontation to finish up my mindmap, I came across an interesting definition of the word ‘nice’. It seems that many people describe their organization’s culture as ‘Nice’. So the authors came up with a new definition of the word:
Nice
adj. A pleasant, nonconfrontational attitude that eventually kills you.
Does that sound like your organization? If so it might be time to change your corporate culture.
I saw this quote on 37signals’ blog and I thought it fit well with my latest post on failures.
“It’s important that nobody gets mad at you for screwing up. We know screwups are an essential part of making something good. That’s why our goal is to screw up as fast as possible.”
- Lee Unkrich, director of Toy Story 3, Wired magazine
If the goal is to screw up as fast as possible, you need an environment that allows you to do it safely.
Failure is often a dreaded word. It need not be. Programming is an art where it’s very easy to fail and you can usually fail fast. Use it to your advantage. Learn to fail with style.
Give yourself the option to fail deliberately and safely. Many tools can help you:
.
Code is cheap and fast to write… once you know the way. A few failures early on will help you get a success when it counts.
Thoughtworks published another version of their technology radar. I think it gives good insight on the state of the computer industry. I recommend reading it but to tease you, I’ll give you a few highlights:
Read their analysis to know more. It talks about NoSql, Restfulie, C#, Internet Explorer, HTML5… There’s something for everyone and you might learn about a few technologies that will be big in the near future.
My teammates are not afraid to ask help whenever they are stuck. We trust each others. We believe in each other. Disagreements are common but it makes us stronger. We work in an open space so it’s easy to get information to everyone.
That sucks. We talk too much. We get distracted from our own problem to help someone else. We ask questions aloud because we know someone will answer, then an argument follows and every one pitches in. Being passionate has drawbacks.
And then we discovered the Pomodoro Technique.
The Pomodoro Technique aims to provide increased productivity by splitting time into small increments of work without interruptions. To explain it in one sentence : work for 25 minutes, take a 5 minutes break. If you want to know more about the Pomodoro Technique, check their web site. I’m far from being an expert on the subject. My goal is to share my experience and what we gained by using this technique.
A few teammates talked about the Pomodoro Technique during an Open Space a month ago. As with many good ideas in open spaces, this one went dormant for a while. An afternoon two weeks ago though, something changed. The sprint was in peril. We all felt the urgency to change though we weren’t sure what. After a brief explanation of the technique, we decided to try one big team Pomodoro.
There was something magical about our first Pomodoro. Silence. Concentration. No interruptions. After 25 minutes we took a break and regrouped. We needed to synchronize. I remember discussing the API between two parts of the application. A quick review – were we willing to try another Pomodoro? Unanimous answer: YES!
We did four Pomodoros for our first day then held a quick retro. We didn’t have concrete numbers but we all felt increased concentration and productivity. We decided to continue for one more day and see how it goes.
We’ve been using the Pomodoro Technique for two weeks now. Not all our work is done during a Pomodoro. We do about four Pomodoros in the morning and another four in the afternoon. I’m pretty sure it improved our productivity though I have no hard numbers to prove it. We have a rhythm of very intense work followed by an explosion of discussions to synchronize everyone. Every Pomodoro, we commit to work on one thing. During the 5 minute break, questions are asked, new pairs are formed, help is offered and given, tasks are switched. The work done in a Pomodoro is diverse. It could be pairing, writing documentation, sending an important email, a design session… The important thing is to work on whatever you commited to.
We do look like weirdos. There is a whiteboard with a big tomato (Pomodoro means tomato in Italian) indicating to everyone else in the company that we are currently in a Pomodoro – do not bother us. We’ve been told that the pace a Pomodoro dictates is very hard to follow. The team doesn’t feel that way at all though. Colleagues outside the team need to get used to us sending them back to their desk if we’re in the middle of a Pomodoro, but a few started to come in and watch our clock before interrupting. One thing is sure : lots of people started to talk about us.
The Pomodoro Techniques works. Even when we are not officially in a Pomodoro I find interruptions to be less frequent. We salvaged a sprint and the current one is one the way to success in part due this technique. The fact that the entire team decided to try it at the same time helped a lot to see the effectiveness right away. I tried a few other productivity techniques and so far this one had the most impact. You have to try to see for yourself.
Photo by Darren Hester
http://www.flickr.com/photos/darrenhester/
We’ve had enough. We want demos that are fluid. We want demos that are fun. We want demos that work.
So my team tried something which we called ‘Demo Driven Development’ during our last sprint.
In every one of our stories, we included a task called ‘prepare the demo’. This task was only scheduled to take an hour. We just wanted to make sure the story could be demonstrated. The team also named a demo champion (me) for the iteration with some reserved time to prepare the demo. All these tasks were included in our sprint backlog.
The results were pretty good. The demo went smoothly for the most part. I did a small blunder that broke the flow a bit (sorry team) but feedback was positive during the retrospective. The team decided to keep doing the same thing for another sprint, just to see where we’d go.
To me though, the biggest change was not the demo itself but the awareness demo driven development brought. Every time I worked on a user story, I was thinking about how I could show it. The end result was that the feature was just a tad more configurable. One particular story didn’t have a UI so I made logging more readable and complete because I needed people to be able to understand what was happening.
The code was more or less the same. But the feature was better.
Some of you probably think that every story should be coded to be demo’ed anyway. You’re right, it should. But we wanted to improve in this area and it worked for us. Maybe Demo Driven Development is for you as well.
I once received a wall clock with these words : “Shipping is a feature”
I don’t remember what happened to the clock. Maybe I should have kept it around.
Sometimes remembering that you need to ship your code is enough to give you a well-needed push. Good UI, architecture, testability are all necessary… but it’s easy to push too far. Sometimes you have to go with ‘good enough’ and ship.
I had a weird bug UI bug. I couldn’t fix it, I couldn’t get around it… everything I did seemed to make the bug worse.
So I spend some time looking at funny pictures of cats, and that’s when I remembered that I had all the power of git to help me… and I heard the cat whispering: “Git bisect to save the day!”
Funny cat? You can't be serious...
Yeah, looking at cat pictures makes me go crazy. Go figure…
Coming back to git, I read the doc and bit and away I went:
git bisect start
git bisect good last_good_release
git bisect bad master
git now sent me to a revision between those two… last_good_release can pretty much any commit identifier (a tag, the sha1 identifier…)
I compiled, ran my test… all good. The bug wasn’t in this version.
git bisect good
Git selected another commit. Compile, test… hmmm… the bug appears it this version
git bisect bad
Git bisect helps you do a binary search over your commits. It checks out something in the middle between ‘good’ and ‘bad’. You check to see if the bug is there. If it is, ‘git bisect bad’, if not ‘git bisect good’. And you continue until you find the guilty commit.
Eventually I found the culprit… It was nowhere near where I thought the problem appeared to be. I had lost a lot of time… but I found it, thanks to git!
Git bisect saved my day.
I’ve been been using the web differently lately.
I discovered a nice application that allows me to wrap my web experience in a nice bundle.
It’s called Quix. And it allows me to use the web on steroids.
Quix is an extensible bookmarklet. It allows you to quickly access your favorite web sites – do an google search, look for a book on Amazon, bookmark a page on delicious… I don’t have to touch the mouse! It’s like a command line tool for the web.
But the real power comes from the extensibility. By default Amazon searches are done on Amazon.com. Since I live in Canada, I find it a bit annoying. So I start to write my own Quix file. You can find it on http://mathieuberube.net/quix/quix.txt.
So far I added these commands to my Quix file:
Quix has a page to configure custom bookmarklets. I then configured Chrome with the Shortcut Manager extension. Now I just press Ctrl-Q and I’m all set to enter any of the commands above.
Give it a try, you won’t regret it.
Quix in Chrome
A colleague recently wrote a post about 360 evaluations, asking if it really helps to become a better employee.
A traditional 360 evaluation often works as follow: you (the good employee) ask a few colleagues to fill out some questionnaire rating different skills from 1-5. Let’s get real: everyone loves you and you get all 4 and 5, which make it very hard to find your strengths and weaknesses. The questionnaire can also has a few random questions about whether you are a generic good employee. You then have the pleasure of reading generic comments about your good behaviour as a corporate drone.
My colleague is right. That’s garbage.
However there is another way.
For the past six months, I asked colleagues to give me feedback in a face-to-face meeting. There was an enormous difference.
I feel that they were trying harder to come up with strengths and weaknesses. But most importantly, it’s a conversation – I could ask for clarification and specific examples. I could also ask questions, specific points that have been bothering me.
And let’s face it – I’m not going to improve much if all I hear is that I’m the best. I exposed some of my perceived weaknesses to see if others have the same perception. And sometimes, they didn’t.
It takes humility to handle the feedback. But in my case, there was no big surprise – I already knew (or guessed) about most of the feedbacks I received. I really appreciated that the aspects the feedback covered was very different from written 360 evaluation and I felt more compelled to act after a conversation than I did after reading impersonal comments on paper.
I believe that face-to-face feedback will make me a better person so I’ll continue to bug colleagues from time to time.
PS: another colleague tried a group therapy 360 evaluation. I hope he’ll post about his experience (Luc, take the hint )
