Being a consultant is great, being a consultant working exclusively with Ruby is awesome, being a Ruby consultant using Agile methods on great projects with cool clients is just super-awesome. The English language doesn’t seem to have a word/expression defining this feeling without using the “f-word” (at least, there’s nothing I can think of right now)
I have to say that I owe a lot to the Ruby community and especially the Rails core team. Without you/them, I wouldn’t be able to do what I do and I would certainly not have so much fun.

Enough blahblah, a retrospective wouldn’t be a retrospective if I wouldn’t look at ways to improve the process.

Looking at back on 2007, I’ll look at what I did good and where I could have done better.

communication wise, I think things worked out quite well.

Daily stand up

The daily stand up/scrum proved to be very efficient on all projects. it usually takes a short adaptation time on the clients side, but once everybody is on the same page, meetings are short and efficient.

Iterations

Clients adapted more or less well to the whole Iteration process. On some occasions, I ended up being in charge of managing iterations, confirming my suggestions with the client during our iteration planning. I wish I was able to get all my clients to fully understand and enjoy the process, but oh well, the reality is that some clients just want the work done and don’t care too much how you do it.
In general iteration planning sessions went quite well, they really helped us defining priorities and manage the budget. However, I feel the need to bring more structure into these meetings.

Weekly Retrospectives

Retrospectives/demos could really be improved. I have to admit that I was not able to organize a single great retrospective with my clients. That’s one major draw back of working remotely and being a contractor.
Since I would deploy few times a week, the weekly demo didn’t always made sense. I therefore decided to use Jing and create a weekly screencast of the iteration changes. This way my clients know exactly what was done and can test whenever they want. We still have our demos from time to time especially when major new features are implemented.
In 2008, I really want to improve clients’ retrospective.

Tools

While lighthouse helped me keeping track of my iteration user stories, unfortunately, I noticed that clients got confused when using the same tool to report bugs and to manage iterations. I’ll still be using lighthouse for bug reports but or I will have to finish my agile project manager or I’ll use Josh Knowles’ of he finally releases his software

Bdd/Rspec was a big winner in ’07. People might argue about the real benefit of RSpec vs test unit. Well, I can only talk about my own experience, after using RSpec for a year, the way I write my applications totally changed. TDD certainly became a reality. Even my relationship with my clients changed. I now get my clients to write my tests, well, not exactly but almost. I get them to define the expected behaviors using the usual it..should..do syntax. I then just need to transpose my clients expectations in contextualized specs. once the iteration is over, I output a spec report that i give to my client. I never had so much fun writing tests!

One thing I need to focus on in 08: ajax & js tests!

Talking about JavaScript, I finally found a way to write Js and have fun. Lowpro totally changed my view of Js and I can’t wait to push things further.(my December talk on Unobtrusive Javascript should be online sometimes soon)

Talking about pushing things further, I need to see if I can totally dish svn and only use git + gitosis. if you didn’t check Git yet, go check on the awesome peepcode put together by topfunky.

Misc things that didn’t work that well:

• unreliable subcontractors
• hard to find designers
• having to say no to so many cool projects (always a good problem to have though)

Various things that I enjoyed:

• Joyent accelerators
• twitter
• sd.rb
• autotest
• iPhone
  (and probably a lot other stuff that I can’t remember right now)

Major changes planned for 08:

• pairing with another local developer complementing my skills.
• better weekly retrospectives
• tech lunch at least once a month
• learn Erlang or another programming language

I’ve been a freelancer/consultant/contractor/mercenary for many years now. However, until now, I used to do that on the side. Few months ago, after thinking a lot about it, I finally decided that freelancing was what I wanted to do. I left my job and started my own adventure.

The first reason for this switch was a desire to be more involved with my clients’ projects and accept bigger projects. Then there was the obvious flexibility brought by this new position (I can now work wherever I want, usually on my deck). Finally I have to admit that financially things are better now.

This post won’t be about helping you deciding if you should freelance or not. I’m just curious to know how you work, how do you deal with your clients, deadlines, payments etc…
So instead of simply asking, I’ll explain how I do it and I hope that you will share your ways of doing it.

How do I do it?

Choose a client

Clients are the heart of your business. At first, you might be worried not to find enough work and you will take any project. WRONG! this is the worst thing you could do. You would not take any job just because they are willing to give you a salary, would you?

I. find a match

Personally, I believe in Agile methodologies, regular code release, iteration planning, daily stand-ups, test driven development, continuous integration… This is what I call my ‘work values’.
If I see that a potential client’s ‘work values’ are opposite to mine. For instance, he might like the waterfall approach, writing a lot of documentation before we start coding, doesn’t see the essential need for a good test suite, then I know we would not be a good match.

It doesn’t mean that I’m right and she/he’s wrong. It simply means we don’t work the same way and that a work experience together might be frustrating for both of us.

A lot of clients don’t know how to approach software development and they might not have strong ‘values’ yet. In this case, I explain how I work and I try to read their reaction. Sometimes, you can agree on a ‘trial period’. Being freelance, you are more than likely free to quite whenever you want. However, you’ll find out that is not a good experience for neither of you.

II. Check on the project

My first rule when it comes to choosing a project: if it doesn’t interest me, I don’t take it.

It’s very simple: to do a good job, I need to be passionate. If the project is boring or simply doesn’t attract me, I know I won’t be able to serve my client the best I could.

Second rule: Code review

Often, you might be contacted by people who already started a project but for some reason need you to take the project over. That happens often when a client tries to save money by taking the cheapest guys around (often overseas) and realize it doesn’t work for them. Or maybe, your client’s main developer had to leave and they need your help. Finally you have the case of a project growing and they simply need more people to work on it.

I always ask for a code review before I accept a job. Why? Simply because a CEO can tell how much he believes in Agile software development, that he has a portrait of David Heinemeier Hansson above his bed and that he knows getting real by heart, a quick look at the code will reveal the truth. It will also tell you a lot about the other guys who worked on the project.

• testing suite: do they have any? Rspec? Unit test? Selenium? What’s the test coverage? Do the tests pass?
• test readability: Did the developers try to be clever and the code is very obscure?
• best practices: Did the team follow most of the best practices? Why not?
• reinventing the wheel: Did they make a proper usage of plugins/gems.
• living on the Edge: Are they running on Rails Edge? Would it help?

I usually don’t worry much about how they deploy, since that can be changed easily.

Looking at your code review I try to evaluate few things:

• what’s the team’s tech level?
• what kind of pressure the administrative people put on the tech team?
• what do the teach value?
• do I need to rewrite a lot of code?
• do I seriously need to improve the test coverage?
• is it a real mess and I’d better give up before starting?

A few months ago, Jade Meskill recommended I read “the dip” from Seth Godin. If you haven’t read it yet, get a copy. It’s a very simple and obvious book but it explains very well why and when you should give up and when you keep on struggling. And that’s exactly what we are trying to do. We want to evaluate the effort needed to succeed (if it’s doable).

III. Build a relationship

Business is all about relationship. Both your client and you have needs. By creating a relationship you will try to fulfill most of your needs. Let’s look at an evaluation of my professional needs:

• I need to be challenged
• I need communication
• I need guidance
• I need deadlines
• I need results
• I need to be valued

And here is what I cam up with when I tried to estimate my client needs:

• he needs business value
• he needs to feel special
• he needs to be reassured
• he needs to keep control over the finance
• he needs to make sure he doesn’t waste money/time with me
• he needs to plan the future

There we go, we have the base of our relationship. As long as most of our needs are fulfilled, the relationship should be strong.

As you can see by looking at the list above, the client needs to be convinced that I am the perfect fit they were looking for. On my side, I want them to realize that we are lucky to work together and I want them to value me.

Money makes the world go round, especially in a business relationship and especially in the Western world.
Your rates are a simple way to say, this is what I’m worth. If you are willing to pay my rates, you are valuing me. Obviously rates can be negotiated but be careful, somehow they will always represent your value.

So how do I build this relationship?

• be frank, open and transparent.

I don’t want my clients to feel that I’m hiding things from them. For instance, I’m always running two projects at the same time and I make that really clear at the beginning before I start working on a contract. My client A knows that I will work 17-20 hours a week on his project and 17-20 hours on a different project. If I have to miss one of our stand-up, I usually explain why.

Trust is very important when you are an outsider and even more when you work remotely.

• Provide visible business value on a weekly basis.

At least once a week, I have a quick demo with my clients and if possible their co-workers. This demo is really important for a client since he can then visualize the business value added to his product. He will feel in control, reassured and will be able to evaluate the situation and plan the future of the product. Usually clients who worked with other developers/methodologies also feel special since they would usually only see business value at the end of the project. By the way, the demo is usually done on the production application so we are talking about real business value.

• Make the client the center of the decision making process

In my usual process, we have a special meeting every monday. During this meeting, we plan the work for the coming week/iteration. I simply help the client breaking down his tasks in small chunks that we could handle in a week. During this meeting we also agree on this iteration priorities. In general we already created a queue/backlogs of tasks that need to be executed. I simply let the client make his choice to what is really important. In general a client wants everything done right away exactly how he has it mind. Well… the reality is really different. A client doesn’t have to understand the concept of polymorphic association to make decisions. Actually, he doesn’t care how you do it as long as it’s well done. However, your client should know how to prioritize things, he probably already does that all day long.
Converting the technical details into simple concepts that make sense to both you and the client will seriously help the project. I don’t have to worry about delays, I don’t make these decisions, my client does that for me and he likes having control over budget/time line.

To sum-up, I believe that by choosing a client that matches my view of software development, a project that sounds interesting to me and building a strong relationship, we will have a good end result and a win-win situation.

What about you? How do you manage your projects, clients? Do you agree with me, or do you think I’m idealist and in the real world things don’t happen like that?