it.is.pi

Presentation Powertool

2009-11-24T09:22:00.003-05:00

Last week at the Microsoft PDC it was clear that all presentors were not only well trained for the job but also that they were leveraging tools to make their "Customer's Experience" great.

How many times have you presented using a projector and that people have been complaining on the font size or the overall readibility of the material presented on the screen?

This does not have to be. I am culprit of this lack of concern for my participants, well... not anymore.

I downloaded ZoomIt. Try it, your assistance will thank you for that!

When the design IS user centered...

2009-11-04T08:15:00.004-05:00

Been silent for a while although I have a pile of topics to cover here, not all directly related to process improvement... although... user centered design is non arguably a process improvement in the context of product creation activities... This is what this post is about.

Last year I offered myself an Ipod touch. Loved it at first sight as everyone. However I was quickly disenchanted when I noticed how the Music playing application was lacking advanced features. After all, beside selecting music and playing it you couldn't do much (it is still this way today) and to make it worse some functionality are implemented reverse. One notable example is how Apple offers us to manage play lists, rather than being song centric it is play list centric. Tell me who sits with its Ipod to create playlist? Unless I am so weird, it is when a song plays that I am thinking about which play list I want this song into. Anyway, I digress...

Apple did surprise me though with the way the implemented the concept of requesting a song via the Remote application. This is a piece of beauty from a user centered design stand point.

For the Remote application neophyte, Remote allows someone in a wifi zone where an Itune is found, to control it. This privileges can be granted to guest at your place.

Before the digital era we were stacking records to order the play list. Well, this is more or less what the Remote application and the ITune DJ allows to do with the "Request a Song" feature. This becomes very interesting in a party when many people have IPhones or IPods, it allows people to browse and search your library and request and vote for songs. Making the music experience of your gathering tied to your guests preferences.

What makes this feature useful is the fact that it is user centered, that it directly relates to a human behavior.

The point here is that as software consumers we should not tolerate anything but user centered designed products. It is obvious when you see such products, you can always relate the software flow to the related human behaviors and in all cases this makes the software much simpler and nicer to use.

This is the endeavor the company I work at has embarked on more than 3 years ago now. Since we cannot resolve the peace and war problem, let's make the world a better place to live through user centered designed software!

For an in depth presentation of Itune DJ and Remote you can consult this post.

Read the other side of the coin

When the design is not user centerred...

2009-07-14T12:43:00.004-04:00

I have to admit, I generally love Google's products. I am however often not impressed by their way of handling customer requests or the whole customer experience thing for that matter.

The last deception for me is this feature that now allows to do an undo after sending an email. I can relate to this feature because I have requested the ability for my sent email to sit in my outbox for some time (like you can do in Outlook for example).

From the point of view of listening to their customers they do well, it is easy to submit feature request or bugs.

But when I enabled this Labs feature I was up for a major deception. It was clear that they got it all wrong. In this case, the code mechanic and feature works:

I can effectively undo a send email
I can personalize (minimally: 5 or 30 seconds) the time is stays in my outbox.

Where it fails miserably is how the user interaction is done. It is so poor that the working feature is more or less useless.

When sending, I have to click on the "undo" link at the top of the screen but this is only there until I do another action. Since after hitting send I always do something else (I am not waiting 30 seconds staring at my screen to maybe think that I should not have hit send), the message disappear thus rendering the working feature useless.

What as gone wrong? Or, what could have happened to prevent this? (note that I am assuming that this is the implementation they choose to do to fulfill my feature request)

It is simple: Get someone involved on the development side at Google to validate the approach they were to take with the customer.

Doing so would have allowed them to:

Understand my goal

I need the ability to cancel sending an email.

Understand my motivation

I sometime use the wrong tone in an email, I get excited, I need time to cool down before I realize I may have said something the wrong way.

Understand my workflow
I need the period to be longer than 5 or 30 seconds, I need 10 minutes.
This above implies that I cannot rely on the last action "undo" link there is for everything else.
This is so simple that it is pathetic that they do not do it. This is something that is important and a lesson that we made a loooooong time ago at Macadamian: validate your understanding with your customers/users so you reduce the risk of mistake at the soonest possible time.

Now if someone at Google can read this an start interacting with their customers it would make my day.

Kanban collaboration nirvana?

2009-07-02T16:36:00.004-04:00

I've been educating myself more and more lately on this Kanban buzz. For the neophytes, this is more or less the Toyota model applied to software development.

One thing that struck me is how it enforces collaboration. The cool thing is that I can relate to some of the inherent benefits when thinking of a project that I worked on a few years ago.

One thing Kanban ask you is to be lean. To be lean implies to have control over your queues. At Toyota it meant that the door maker guy would only start making new doors when the door installer guy would have only X left in his pile. How does that translate to software you ask?

Well it is simple. The number of stories accepted on the board are limited, the WIP (work in progress) is kept to a low number, similarly all the queues of your SDLC are kept to a small number too. There goes for the queues optimization theory, you can read more here.

However, these limitations on the queues size have an interesting side effect, and it is that it will promote collaboration over everything else. In a Kanban system a team member for example, is encouraged and might have to offer help to the QA team in order for them to free some room in their own queue, which will allow the dev to promote the new completed story to the QA stage. Similarly, a developer could also assist in the UCD (user centered design) activities if the bottleneck was found to be there.

Isn't this beautiful? I think so. This is something I recall doing at a small scale when I was project leader, I would find myself occasionally helping my QA team to reduce their queues.

At the time I did not know that much about Toyota nor Kanban, but it feels good today to see that I had such behaviors without really knowing much about some of their benefits.

Another side effect of this is the growing requirement for highly agile team members, team made of people that can do just about anything for the benefit of project... and the team!

Why team collaboration and communication is so painful?

2009-06-16T13:27:00.005-04:00

A recent twit from Gerry Kirk that I follow on Twitter, is providing me with an answer to this question.

His recent link to Working Agreements is putting emphasis on it, not directly but indirectly.

When I read this, one thing struck me: there is a lot expected from everyone - not too much - but a lot. Failures at communicating these expectations will undermine your team. Not only at the Agile/Scrum level as explained by Nicolas but at all levels of your organisation.

People have to understand the purpose of the expected communication and collaboration activities. They have to value them as a practice and they have to buy into the technology that enables these activities to happen.

Again, the people, process and tool triangle...

Will you join the Google wave?

2009-06-14T10:24:00.005-04:00

I am quite late with this Google news but I am just done watching the developer preview at Google IO on May 28th.

It's quite long but quite worth it as an overview.

This is very exciting in my opinion as it revolutionize further the way we communicate. Google already created a mini revolution with Gmail, but Wave integrates all communicateion tools we use daily (email, IM, SMS, blog, content collaboration, etc...) in one. That's lovely. The more I think about it, it's not a communication revolution but a collaboration one.

We have all replaced the words "search this" in favor of "google this"... I would like to predict that we will soon replace email and threads by Waves! IMNSHO, this is the end of email the way we use it today.

Will you join the Wave?

Click Here for Poll Online Survey
| Website Polls
| Email Marketing

| Crowdsourcing
View MicroPoll

More stuff about Google

2009-05-29T15:11:00.002-04:00

Following up on my twitter post...

on the other hand is the fact that Google will keep creating weird features in Gmail - last example is this inbox feature for slow connection...

How many Google savvy users are still on 3200 bauds modem? Admitedly the value of this feature is of limited reach...

There are a bunch of productivity related features that are in their funnel I am sure, I for one keep pushing features their way.

Last one was something inspired from the Syndeo Project Server we created back in the days... It's the ability to put email threads on a stack or on a symbolic push pin board that you can later pick and add as attachments to other emails.

I do not know about you but I keep having to do this, digging out threads and then forwarding them arround. Of course I can send them individually but in many cases it makes sense to keep them together to keep the context in one bundle.

Been waiting for this and other similar productivity enhancement to gmail... Maybe I am alone with this need who knows?

You can contribute feature list to Google at

http://mail.google.com/support/bin/static.py?page=suggestions.cs

Google Tasks

2009-05-20T08:25:00.002-04:00

This is something that I have been waiting for a long time now...

Last week Google released an update that shows your tasks in your calendar. Kind of mandatory if you want to get them done! (granted that you at least look at your calendar once a day...)

OSEF - Software as a Service

2009-05-01T14:25:00.003-04:00

Yesterday was the event on SaaS, we had a very information savvy group and our panelists, as usual, have helped demystifying SaaS for the rest of us.

A couple highlights for me from the discussion:

SaaS is raising the bar with respect to the quality of the development process.

I was not expecting that one. But when you think about it, delivering software (read: value) frequently puts pressure on the need for the development team to create quality software at all time not relying as much on an intense and lengthy verification process. In this context, successful SaaS product teams have better software development processes. We did not dive into the details of it, but risk mitigation and quality assurance strategies such as: user centered design, code review, agile methodologies, automated unit tests are certainly part of the mix.

Lesson: When building software in the SaaS model, ensuring you have a great software development process should increase your odds of getting the most returns out of your SaaS initiatives.

Your development team are on the operation team.

We had an extensive discussion on the shift that SaaS causes on the involvement of the development team. This is a no brainer when you think about it. When releasing software on a monthly basis (or even faster) to your customers, you must have your development team available at all time, otherwise who's going to take care of the unexpected failure occurring on a Sunday night? This is a clear distinction over the more traditional delivery model of shrink wrapped software.

Lesson: Ensure you are engaging your development team for more than "simply" building the software. They must be available to handle software failures at all time.

Hope to see you at the next OSEF, the last of this season (for real this time!)

If you are not member, please request membership through http://www.meetup.com/ottawasef/

Cheers!

The power of your team

2009-04-20T10:49:00.001-04:00

I posted earlier this week on The Macadamian Files blog.

Beside the technical lesson in there, this post if omitting - by design - a gem that jumped right in my face the minute I got my answer.

The hidden gem is a practice that consists of leveraging your entire team experience. This is how I got the answer to my question. Powerful collaboration.

Here is the practice definition:

Description

Offer a mechanism to reach out to the experts in your organization.

When to Apply?

Knowledge exists in the org but it is not maximized and software errors or delays are caused due to that.
You have a distributed team.

What needs to be done?

Define communication channels, it could be mailing lists, IRC channels, forums, etc...
Ask your experts to participate and offer to everyone else to volunteer.

We did not set up that system from day 1 at Macadamian, it's only when we started to be distributed and somewhat larger that it became clearer that we needed channels to our collecctive brains.

At Macadamian, we created 3 specialized mailing lists: engineering, usability and quality assurance.

This is the mechanism that allowed me to get the answer to the problem I was blogging about on The Macadamian Files. These mailing lists are now part of our problem solving process.

While you dig on the web you also email the group, you are likely to be surprised by the volume of knowledge of your organization.

Macadamian win OCRI's - Service Company of the year!

2009-04-09T15:36:00.001-04:00

Another beautiful day! Presented to Macadamian , whose approach helps software product development managers attain the mix of skill, speed, quality and cost they need to be successful. To Macadamian, success means working hard to raise the odds of other companies' products succeeding in the marketplace. http://www.ottawasun.com/Money/2009/04/09/9065971.html

OSEF - Delivering Software Faster

2009-03-27T07:53:00.003-04:00

Yesterday was the 6th event of the year. We had a great pannel!

Adrian Cho, Development Manager, Rational Team Concert at IBM
(see his work at http://www.jazzproces...)

Jason Mawdsley, Director of Project Management and Certified Scrum Master at Macadamian
(see his blog http://ontherighttrac...)

John Fait, Lead Software Developer, Enterprise and Developer Business Unit at Adobe

We looked at ways that you can use in your oganization to "Deliver Software Faster". Interrestingly enough, the discussion kept being steered towards Agile methods, Scrum in particular - probably a sign of our time!

In the end Scrum has not - as is - been identified as the silver bullet though, but instead, an custom version that fits your organization might very well be YOUR silver bullet.

An interresting shift that happenned early in the discussion consisted of focusing not on "Delivering Software Faster" but more "Delivering Value Faster".

With no surprise, this consists of putting the user of the product as a key component in the product evolution, a couple methodologies were discussed:

Last but not least, people. It's only with a great team that you will accomplish great things. Make sure that:

your hiring process allows you to get the best out there,
your people are doing things they like,
they are well trained.

But first and foremost, have inspiring leaders that will help them to be self motivated at achieving theirs and your organization goals.

Micro Deliverables

2009-03-16T13:24:00.004-04:00

The Tech Republic had an interresting post earlier this month: Monitor Project Progress by using micro-deliverables.

This is a lesson we made almost two years ago. Being mostly software centric, we refer to this as the "patch a day principle". We even push it further than the author of the post by targetting deliverables on a "almost daily basis".

Amongst developers, the code is an awesome communiation tools.
You cannot catch an error much sooner than the next day it is commited.
In distributed contexts, the time zones often plays in your advantages and review happens over nights.

As you can see by the name of the "principle" this is something very software engineering centric. There is no reason to not apply this accross all roles involved in a project though: Documentation, QA and UX.

This is about predictability and this is a requirement common to all activities on a project. Make your project lead and your customer happy through a predictable team using frequent micro-deliverables!

MS Live Workspace

2009-02-11T16:35:00.003-05:00

A few of us at Macadamian have been experimenting with the Microsoft Live Workspace thingy... Sort of Google Docs for MS Office users.

This is still very beta and several key collaboration features existing in Google Docs are missing. To name a few:

Folders: this was the first annoyance, when you collaborate on a project you want to keep things clean otherwise it gets... messy... one need a way to organize files.
Email Collaborators: This is a low hanging fruit, when you collaborate you need to email your collaborator, why isn't this there yet? Beats me.
Notifications seems flaky: I just started to get them (took time to work) but they have no content, just a link, only partially useful.
History: Well, I have yet to find a way to see the "diff" between the versions. I do not think it's there although I am sure I read somewhere something about this.

All in all this is an acceptable stab at it from MS, in my opinion mainly for two reasons:

It promotes document sharing in a rather nice and working (most of the time) way. Can we be done with sending each others documents as attachments once for all?
It leverages Words and other Office tools - although most of the time overrated and overpowered for most uses - they have been adopted in organizations, keeping them around while working in the cloud makes it comfortable for most of us and it does not create the same resistance to change effect than Google Docs does.

This being said, the current Live Workspace offering is far from the power that we need for efficient distributed collaboration. Google seems to have a serious lead there but people wants to use Word... What can you do?

I still thinks this is far superior - event with the occasional glitches - than the staus quo of keeping sending each others documents as attachments.

With this at least you will stop asking yourself: "Am I looking at the latest version?"

Delay on send...

2009-02-04T10:31:00.002-05:00

With the integration of Gears and the related addition of the Outbox in Google Mail, it seems that Google is ready to implement a feature "I" ;-) have requested a long time ago... "Delay on send".

This is a feature in Outlook that has allowed me in the past to fix already sent emails before they get onto their journey in the interweb...

Click Here for Poll Survey Software
| Website Polls
| Email Marketing

| Innovation Management
View MicroPoll

Ultimate feedback loop for bloggers...

2009-01-26T08:41:00.003-05:00

Following up on my last blog post... I started wondering last week if process savvy people in the work place were the same at home. I was thinking about this when doing the recycling duties, i.e. avoiding to put garbage in the recycling bin and vice versa...

There is a corrolation for me. Then I thougth wouldn't it be nice to ask arround? Then I found this little free instant survey tool... What do you say?

Click Here for Poll Survey Software
| Website Polls
| Email Marketing

| Innovation Management
View MicroPoll

Feedback loop for bloggers...

2009-01-15T08:14:00.004-05:00

Jason's recent posts made me found out about this new feedback thingy "Reaction" that Blogger is offering. Combined with Google Analytics this is probably the ultimate feedback loop tool for bloggers that I have seen so far.

I just turned it on on my blog. Of course, comments are interesting an very welcome but they may be intimidating to some readers. Ticking a check box is not as engaging but does provide valuable feedback to the blogger.

To turn the "reactions" feature on, simply go to your template and edit the layout of your post item. When you read a post with this, send feedback to the author, I am sure they will appreciate.

Code Review - How to miss the point...

2008-12-23T11:30:00.007-05:00

Sometimes your arguments just don't weitght enough in the balance...

I had the opportunity to "attempt" to contribute to Esther Schindler's article on Code Review. She reached out on LinkedIn and I offerred help. Now that I am reading her article I have many dissapointments. Mostly related to not being able to make my contributions useful.

Right from the get go I warned her about "meeting driven" code reviews. These code review sessions where people each bring a tree's worth of paper and then beat the s**t out of the code worked on for a month. They generally also spend a day reading a massive and scary amount of code before the meeting, a very costly process needless to say with limited output in general (at least from my experiences 10 yrs ago at Bell Northern Research and later at Nortel).

I could see from the other contributions she was provided with that this was the route she was about to embark when talking about code reviews. Her article is filled with reference to "weekly review meeting"... or "meeting driven" code reviews.

A couple good take aways are:

Jason Cohen from Smart Bear who is talking about a code review style that makes more sense, closer to what we believe in at Macadamian.
Someone from Google who's is suggesting to do design review before you even consider doing code review.

If I had to write that article I would put emphasis on what has helped us here to improve quality:

Small and frequent code review. Get code reviewed on a daily basis. This ensure you catch errors as soon as possible.
Do design patch review - Just In Time Design - JITD (expression first heard from the mouth of Francis Baudet's sometime in the summer of 2008... ;-) ) This process, not only ensure that the first line of code will be a valid one, but also ensure that the deveopper starting the work took a step back and thought about the code to be written before to start writting it.
Tools stack. Do not neglect the use of proper tools to do the job, emailing a patch to each other works, but now a day there are very good tools out there.

Last but not least, for code review to be effective you need:

this process to be part of your culture,
to foster an egoless programing environment, ensure understanding of the "what's in it for me" for your developpers,
to not only rely on this process to ensure quality.

First and foremost, you need to not do code review once a weeek but have this process part of your complete breakfast.

Innovation through UX

2008-12-18T08:43:00.003-05:00

This blog post by Jen has attracted my attention... I will probably state the obvious the same way Matt is good at doing (so he claims)... ;-)

Jen's post makes it obvious to me that the UX phase in a project might very well be the "easy" way to innovate in a project. By comparison to a project without UX. Here is why.

First, software engineering people are mostly concerned about construction of the software. Their focus is delivering the code.

Second, software engineering people are... software people., this is their expertise. Many of these guys will be concerned by usability or innovation but this is not their primary focus. They are first and foremost experts at software technology, tools, languages, software design patterns, mostly software creation centric stuff... (I believe for most of them at least)

Our UX team is by contrast much more in touch with the research world, it seems to be a natural aspect of their role to be aware of what is out there so they can integrate these academic projects into a real projects.

In the example brought up by Jen it is clear that a software engineer could have thought of the multi-vibration thing but probably without awareness of the research project done in a particular university. It would probably be a "wouldn't it be cool" kind of enlightment.

As valid as this "wouldn't it be cool" idea might be it would lack the link to the academic research and would probably be much harder to sell if at all possible.

Tasks in Gmail!

2008-12-11T11:43:00.003-05:00

Finally! This is a premature post because since I have not played with it very much yet but in case you did not notice that it was added recently, now you know!

The one sad thing is I have not found a way to import from RTM... That's going to be annoying... Hang on... Google API... Mmm nothing there yet...

This is to my knowledge one of the key feature that was missing to the "Google way" to email...

ProjectTools part of the InfoWorld 2008 Top 100 IT Innovative Products

2008-11-18T07:45:00.006-05:00

What a nice way to start the day! Yesterday Macadamian was awarded one of the top 100 company that have made use of technology to enhance their business.

Somewhere back in 2004 we started to be concerned by the effort that was required to be effective at project startup, monitoring and status reporting.

We envisionned that it would be a real challenge to provision all our projects with the apprioriate knowledge management technologies and to monitor them with consistency.

With now more than 100 projects starting and ending every year we can say thanks to this early vision. Needless to say that the pressure at being efficient and predictable was high and this is still an important concern at Macadamian.

"Let's automate all that". Our concern for efficiency and predictability gave birth to what we called Project Tools. What is Project Tools?

Project Tool is a software product that aims at:

Automating the innitiation of our project's knowledge management infrastructure (KMI). All tools needed for our projects are ready to go in no time (issue tracking, wiki, source control, mailing list, news groups, SFTP, continuous integration, IRC, etc...)
Managing access control towards all system of the KMI
Collecting projects progression metrics.
Reporting objective information on progression.

It is outside the scope of this blog post to go deeper about what it is, how it works and so on.

Today I want to say kuddos to everyone who contributed to this project.

Thanks to you Francois, Pierre, Benoit, Sebastien, Jake, Jimmy, Richard, Rafy, Karen & Irina. It would not have been possible to achieve this without you.

Last but not least, this award would not exists without Teresa who submitted ProjectTools to InfoWorld. Thanks to you!

Predictability and objective historical information

2008-08-27T16:56:00.004-04:00

Over the last two weeks I have been involved at the process of interviewing project managers for an coming project.

A few positive things are striking me:

Eloquence. All the guys I have talked to seems to have a facility at talking. This is not a skill you can filter from their résumés. You expect this from a PM but I was expecting some to be weaker on this front.
Deep understanding of what they did. Although their experiences were high level project management (not technical) they would all be able to describe in a fair amount of details the projects they worked on. That's good.

However, a few not as positive things are striking me too:

Predictability. Let's face it, software projects are slipping for many reasons. However as a project manager you want to reach a point at which you will know with a rather high level of certainty when you will be completed. Periodically pushing back the delivery date is a bad thing both internaly and externaly. None of the guys have brought this up. It feel like this is even not a word they know about. It's like if this is external to them, don't shoot the messenger kind of attitude. I think this is wrong.
Historical Information. When talking about estimation, re-forecasting and schedule slippage one would hope that historical information is valued as a way to improve predictability. Apparently not.
Subjective info is king. Last but not least, it would seem that very few metrics are being used by the people I have talked to. This surprises me, they all had some form of PM certifications. What if the people that brings you back the info are bad at estimating? This one beats me.

Obviously, maybe the questions I have asked were misinterpreted, but I am telling you I did all I could to get them to tell me about predictability, historical and objective information.

The lesson here to me is that we will have to train this new project manager to consider looking at the past to improve predictability.

After all, this is rather simple thing to do. Take your velocity/productivity/burnrate (call it however you want) and apply this to the remaining work to do. Chances are that the estimation mistake you made so far are existing in the up coming work too.

With this approach, at least, you have an objective basis for the project change (feature, time, $$) you will have, like it or not, to ask for.

This is so 1990

2008-08-25T10:32:00.004-04:00

Sometimes I just can believe how people are getting stuck in their comfort zone. In this case, using folders as THE way of organizing email. I was 100% sure that this debate was over now, that folders (and trees of these) were bad, one of these evil creation of software people.

Coincidentally, I have a draft blog post which is totally the opposite of this guy's perspective. There is no way I could have been more effective at dealing with my Inbox content when I came back from vacation than through the Gmail client. (note that I have not tried Yahoo recently - last news was that this was simply another Outlook on the web)

His discussion on the whole unmanageable Inbox made me laugh too! Effective handling of incomming emails can be imroved through the use a powerful email client but most importantly I believe it is process thing. Looks like he did not buy into the Zero inbox concept I am referring to here.

I need to publish this "Back From Vacation" blog post...

GPS for software team

2008-08-16T09:54:00.002-04:00

I referred to my vacation in one of my recent post. We left NYC on a Monday at around 19h. That was fun. Thanks to my GPS.

It reminded me my father who, 20 years ago, got lost while attempting to leave NYC. He ended up in the Bronx (or was it Harlem?). He luckily got assistance from a police man, who told him something like "follow me I will escort you out of here, do not stop if you do not want to loose all you have with you". He was driving a shiny mini van full of bells and whistles. A quite scary moment for a unilingual Quebecois.

This made me realize that we have several tools at Macadamian that serves the same purpose to a team than a GPS to a driver.

The most important is probably what we refer to as the "Remaining Effort" graph.

With the assumption that:

All substantial tasks are recorded in the tasks system
Tasks life cycle is followed
Time spent on the project is recorded in the time sheet system

This graph shows a quite accurate representation of the remaining effort and the remaining time budget for a project.

In the case of the project above, the team has been beating the estimates throughout the project. The remaining effort - red line - was always below the budgeted effort - green line.

When this happens, we are in for a nice and smooth ride. Obviously, we also have cases where our estimates are wrong. It is then, that we - and our customers - get the most value out of our project progression monitoring technology.

Obviously, this graph is not telling which direction to take but it is at least telling you that you are on the wrong track and this, sooner than later.

Estimation

2008-08-15T09:50:00.002-04:00

I am receiving the news letter from the TechRepublic. Most of the time I am only reading the titles and move on. Yesterday an article attracted my attention.

Use a pilot project to confirm estimates and lessen risks.

That is interesting in the context they describe where they have a project involving the execution of a task many times. If you made a substantial mistake at estimating the repeated task, sure you will slip big time.

In my humble opinion what is important with estimates is that:

You estimate everything you do.
You get everyone involved in the estimation process, especially the ones doing the work. This way your whole organization improves on this front.

Last but not least: you give exposure to your estimate and make it clear that they serve a purpose: being predictable.

your process -> my process

2008-07-29T13:13:00.004-04:00

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.

It's got to hurt....

2008-07-11T10:08:00.004-04:00

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

2008-07-11T09:59:00.004-04:00

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. ;-)

The AgileJournal

2008-07-09T17:10:00.003-04:00

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

FIXME and TODO

2008-06-07T13:05:00.004-04:00

Part of our development process is the need to show your code - by the mean of patch/diff files - on a daily (aka frequent) basis. Doing so, you are more often than not showcasing work in progress.

There are several benefits in enquiring frequent feedback on your implementation:

optimizes design quality
reduces potential waste caused by misunderstanding sooner than later
promotes top-down software development

However, the team need to pay attention to the various TODOs and FIXMEs that are creeping into the code base. Unmanaged TODOs and FIXMEs will come and bite you at one point in the project if you are not managing them - this is stating the obvious - they can be evil to your project.

If you do not want to create tasks and estimates for each of these you have to keep them visible to all team members at all time. Some IDEs offer the meachanism to create warning in the build log when they encounters certain keywords, this does the trick nicely.

When this is not possible a simple: cat logfile | grep 'TODO' part of your build process will do the trick.

It also appears to be a good idea to ask your developpers to put their name beside their TODOs this way you will know who to talk to in two months when you will be wondering how to get rid of the TODOs.

Checklists in the real world...

2008-05-25T15:27:00.007-04:00

This afternoon I understood the real reasons why checklists are important.

I flew a small Cessna-172 Golf Bravo Golf Zulu. Although I have been a believer in checklists - even though their use is challenging in the software world - I realized how critical using them can be and how useful they ought to be when comes time to inspect a plane before to take off.

No, my pilot was not holding a piece of paper and a pen, checking things off a list. He did not even know the exact number of items on the list. He just did the inspection required by this process with our possible death as a consequence of a checklist failure. This was enough for him to do it diligently. Thanks Marc!

We have many occasions to use checklists when creating software products, there are indeed plenty review processes at all phases of the job:

Specification
Estimation
Architecture and Design
Code
QA
etc...

I am observing that we sometime fail with checklists. Although we do it correctly most of the time, sometimes we still fail.

After today's experience, I believe that the answer to checklist success lies in a couple factors:

Professionalism

Understand your role when reviewing and the impact you can have on the overall quality and risk mitigation.

Agility

Assuming professionalism, you do not need to tick things off a list to claim that you have applied a check list. In doubt, go back to it when needed, revisit the checklist to confirm your understanding of the checklist.

Next time you are provided with a checklist, do not necessarily think that you have to print it or tick things off of it to use it, be smart and agile enough so you can perform the review process with diligence.

To help with applying checklist, imagine that you are reviewing a component of a plane that you will fly, I can assure you that you will likely do the right thing!

To get a feel of my flight load this into Google Earth, select it and hit play.

Your customer (or your boss) is using a newer MS Office than you...

2008-05-20T12:22:00.004-04:00

Install this Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats

Although the converter is crashing on me more often than not it seems that it converts file properly...

Remember the Milk for the BlackBerry

2008-05-16T14:28:00.003-04:00

Motivated by Fred's post this morning, I decided to have a look if the BlackBerry interface to RememberTheMilk was ready. Well, guess what? 2 days ago was released V1.0.6 for BB OS 4.2.

This is not what I was expecting. This is simply a sync between the RTM and the BB tasks application. Although this makes sense in theory, it is very limiting compared to the awesome Web2.0 RTM plugin for Gmail, and I was hoping for a BB app along these lines...

In any case, for now, this is much better than nothing although once the 15 days trial is over I will need to register to RTM Pro edition.

All in all, considering that RTM allows me to be in control of my action items buying the Pro version is just a no brainer to me.

Measuring Project Success

2008-05-16T07:43:00.004-04:00

We probably have in general more than 50 projects going on simultaneously. This is a lot of projects. They start, they end, we move on.

How do we know that we have succeeded?

It ultimately comes down to one or two factors, these two questions are asked in our customer satisfaction survey sent out at the end of every projects:

Would you do business with us again?
Would you recommend us?

Getting yeses on these two is THE indicator that you have succeeded. Obviously the fact that our customers believe that we have met or even surpassed their expectations does not mean we have built the right product - which is something we greatly care about - but at least we have built what they were asking for.

When our customer are telling us that they would do business with us again and/or that they would recommend us we are happy.

I was reading this article about Measuring the success of a project and although the suggested metrics make sense, they neglected to consider the fundamental questions above and focused on secondary aspects (schedule, scope, budget, market acceptance, customer sat in terms of # of complaints).

In a service company, getting repeat business is what makes you successful even though you could not respect the schedule at 100% or meet the budgetary expectations.

Getting repeat business especially after though times implies trust and this is a warm feeling.

Powerful team collaboration using wikis

2008-05-13T07:48:00.005-04:00

We have been using wikis for several years at Macadamian. After looking at a few options we decided to go with Atlassian's Confluence and are quite happy with it. It is not uncommon for customer's to tell us that they are more informed about what is happening within their Macadamian team that they are about their internal team.

What we do and how we do it with Confluence is partly responsible for this.

A recent verison upgrade has brought to my attention two plugins that are key in getting the most out of such a collaboration tools. Here what they are. Maybe your wiki provides similar functionality, if not let me know I can help. Macadamian is an Atlassian's partner.

Most visited page.
{popular:timespan=30d|events=create,view,update|
max=10|space=msp|types=page}

This provides you with the most frequently visited pages. In the context where your project assets are stored in your wiki. These pages are likely hot topics in your project.

Search
{livesearch:spaceKey=MSP}

Unless you are stuck in the 90' chances are that you are not browsing the web but searching it. This simple macro does this nicely for you, allowing to narrow the search to a particular space/project.

Last but not least, a wiki that offers the ability to create RSS feeds is very powerful. If your people do not like to go to your project home page to digg out recent changes, promote the usage of RSS feed.

The idea is that people will converge on your collaboration platform if there is something in it for them. If used properly, any project team member should find important project resources in the project wiki.

Oh, and finaly, do not neglect to train your people!

When an image is worth 1000 words...

2008-05-04T07:27:00.001-04:00

Earlier this week Francois (from Cluj - Romania) and I (in Gatineau - Canada) could not use email to solve a situation, it was simply not the right tool.

We quickly got connected on VoIP and still managed to fail at understanding each other.

This is when I remembered http://www.twiddla.com/. Thanks to their guest trial thing, no accounts to create nothing, nada, niets. We were up and running on their online white board in no time.

We managed to resolve the situation in about 5 minutes, this wouldn't have been possible otherwise. When email and voice is not enough, an image might very well be what you need.

Realistically, this image above is not worth more than a couple dozen words to you but it was worth one thousand to us. ;-)

Test Driven Development

2008-04-03T09:09:00.004-04:00

One of my esteemed college has been talking this week about the importance to train people on the Top 10 Bug Patterns. I thought this was a very interesting idea that we should pursue.

After all it is not that complicated to inject these common defects in a dummy application and let people chase them.

However, this led me to think about what can we do to avoid these bugs in the first place, and then looking at them one at a time, it became clearer that most of them (if not all) can be prevented using Test Driven Development.

I believe that having strong debugging skills in a team is a must but I too believe strongly that there is no better debugging strategy than one that requires from you that you do not let them get into the code base in the first place.

Obviously, TDD does not apply when you are provided a broken application to work with but this is not the normal case, we generally start from scratch.

I would not sacrifice our XUnit testing training in favor of a debugging training... Thanks Didier for the seed!

Bar Camp

2008-04-01T08:47:00.002-04:00

We had a lot of fun yesterday playing with Google Android. We have not created the killer app yet but this BarCamp process is very powerful as it consists of bringing together a bunch of passionate people around a subject and let them run with it.

Looking for innovation form your people? Give them the opportunity to make it happen and who knows maybe you are on the road to create the next killer app.

This is one thing I like at Macadamian, we all have the freedom to make these events happen, the company is behind such initiatives big time.

Killing inefficiencies one at a time... (Part-1)

2008-03-31T08:52:00.001-04:00

This theme is based on Gille's famous "Twelves Weird Links of Christmas", he has been posting funny links on our Intranet, I am proposing a similar series on common inefficiencies in the work place.

This could be ugly, I am a sarcastic person (yep this played against me in the past), hopefully it will be more funny to you than anything else, however, if the hat fits you, I will propose alternatives to these inefficiencies so you can act on right now.

Jason Womac is earning a living telling people how to use Outlook. More recently (not that recent anymore) Merlin Man from Google posted his famous Inbox Zero

These guys got it right, there is a serious problem with email (we all know it) but it is pathetic to see how few people seem to be acting on this problem, the sad things is that there are solutions and they do not require a huge investment.

Somehow inefficiencies in managing email seems taboo, you can offer help as much as you want people will generally ignore you. Even when they are in a crying need for help.

To me, my email handling inefficiencies started to fade away with Womac's talk, I then reached more recently paramount when I got rid of Outlook in favor of Gmail. (more on my tool box later)

In the mean time, if you are recognizing yourself in the quotes below chances are that you are in need of help.

- I am often looking for that email but I can't find it anymore.
- My inbox has more emails in it that the screen can show.
- I am frequently wandering in Outlook folders, scrolling like a mad man, for this email.
- What should I be doing now, I know I have a few tasks hidden in my inbox.

(to be continued...)

Another Epheblog?

2008-03-19T22:46:00.002-04:00

EPHEBLOG: noun, (gr. blog that is of short duration) 1.Is said of a blog that last for a short period of time. Said to be pure when for a specific short punctual event.

I am making this up.

This got to be my twentieth blogs since 2001. Most have been pure
epheblogs. A couple with more depth... But a readership of zero has always made me wonder about the value of the exercise...

In anycase, for posterity, you can expect to find here some thoughts on Process Improvement.

Btw, it.is.pi comes from the title of a slide I created one day working on my objectives related to Information Technology, Information Systems and... Process Improvement.

A lot of what makes life interesting in the work place is often due to the smartness we see in our peers. Working on a project where everyone knows where they are going (and seeing they are effectively going there) is a chance.

This certainly means one thing to me, although a lot of the challenges are external and we have no power at them, we can certainly have an effect on what's internal to each one of us... getting better at doing this, using this tool for that, eliminating waste when possible, etc...

This is what process improvement is all about, this is what I want this blog to be.