Tuesday 29 July 2008

your process -> my process

Picture this. I am back form Cape May with my family, we went to a restaurant altogether once. 18 of us, 10 adults, 8 kids from 5 families.

When we showed up they opened a new room for us. We sat down at three tables, one kids only, one adults only, one mixed. As you can imagine, a waitress nightmare.

When we started ordering we learned that they could not make 5 invoices, they could not simulate that we were using 5 tables, we would not have eaten at the same time (I did not get that one).

Seeing this I decided that I would take the bill and split it myself.

This is clearly a case where one's process has created a mess on another one's process. The ordering process had to win over the paying process.

It took me a few minutes to categorize the orders by family and and split the bill appropriately. Not a big deal but a clear annoyance when you are the one paying.

Could the waitress have avoided me this? I still think so. But what has happen? It is simple: a lack of consciousness that a failure at one process causes negative consequences onto another process down the stream.

This is something we are careful with at Macadamian. One critical area where this could dramatically slow down a development team is with the patch creation and code review processes. The former flows into the later. A failure at creating a high quality patch will add delays and waste in the code review process. We teach our joining team members about this in our Dev-101 training session.

Thou shalt create a high quality patch for the code review to go smoothly.

This sound like a no brainer. That said, it's easier to convinced someone of something when "there's something in it for me". In this case, a good quality patch will reduce your chance of rejection and speed up the code review process. Which is clearly in your advantage.

What was in it for the waitress? Simple, a more satisfied customer will leave a bigger gratuity.

Friday 11 July 2008

It's got to hurt....

Yesterday a citizen from Gatineau was publishing an comment in LeDroit newspaper about innovation.

He was talking about the how messy and broken our roads are by referring to their numerous holes they have (nid de poule in French). He was somewhat pissed at seeing how the blue collar can mow lawn and do all sorts of tasks with efficiency by using various smart tools and comparing this to how poor they do the job at fixing the roads.

He was, in other words, asking them to innovate and fix this problem once for all.

That made me realize that it's got to hurt for one to innovate. The cities by sending a team of 5 with one rake and one shovel to fix these holes are not creating a context that will trigger innovation.

Similarly, I got a urge to improve (and maybe innovate) this week following a rare but terribly bad project customer survey. That whipped me to ensure we put in place the measures to avoid these problems in the future - even if they are not common. This is my role after all.

When I look at the feeling I got this week related to that, it seems more and more obvious to me that to improve "it's got to hurt", and believe me it hurt.

Innovation does not imply improvement, nor does improvement impliles innovation. It seems however, that adding some pain in the mix you might get one or the other, and if you have the good people in place, you may get both.

T&M: Time and Money

I just discovered this Video broadcasting platform - MyDeo. This is like a private YouTube. The problem is I got a problem with their account creation process.

After emailing their customer support team, I immediately got a reply. Obviously I created a "Corporate Account" this probably raises the importance of the incoming requests. However, they nonetheless reacted within minutes and even called me to resolve the problem.

I did not even had the time to consider trying another such service provider. It is taking me longer to write this post than it tool them to help me. That is good customer service. You might want to check them out if you need to share videos in a private manner.

So maybe as Jason is right when he says that T&M should mean Time for Money but I believe that T&M can also mean Time and Money... With the little time it took them to help me, they are getting closer to get my money. ;-)

Wednesday 9 July 2008

The AgileJournal

The AgileJournal is publishing an interesting series of article about distributed software development in this week's issue. Have a look.