Happy Holidays

Wishing everyone a safe and happy holiday season. See you in 2009.

Style over Usability: A recipe for annoyance

Clearly the person who designed this website is an artist. Too bad. Sure it's stylistic, urbane, chic, or whatever the kids are saying these days, but it is hard to use.

I did an informal round of user testing, no one could find the information for the schedule without prompting. Though many (tech guys) went "oh neat" when they realized the trick. This is beautify visuals, but poor design. Ohhh shiny is not a replacement for usability.

I dare you to try and find the show listings.

Unite with Skype?

Over the last few days I have considering moving my IM over to Skype. It just seems to make sense to use one tool for both calls, video, and IM. I know other people have made this transition.

I of course, see some issues with this:

• I have over 230 contacts on MSN, everything from friends to customers to co-workers to family
• I don't want to teach my mother how to use Skype. MSN is hard enough for her
• I have lots of history saved with MSN

Has anyone managed to cut MSN out of their daily use by using just Skype? How was the transition? Any tips or tricks? Or just keep running redundant applications just in case?

It's too bad that the MSN, Yahoo, Skype and all the rest can't get their act together and get some real interoperability.

Carriers are more then happy to let people roam on their networks, or send text messages between people with different carriers. Of course the key difference between carriers and IM providers is that carriers charge fees for text messaging and usually have extra charges for roaming whereas IM is perfectly free.

Would you pay extra for an IM client/service that offered interoperability between the various IM networks?

Addition by Subtraction

Quick, some math teasers for you:

• 5 + 3 + 2 + 4 = ?
• 5 + 2 + -2 + 4 = ?

What is the answer to the first question? 14.
What is the answer to the second question? 9.

Let's put some names by some numbers:

• Alfie is a +5.
• Arthur is a +3
• Ben is a -2
• Bert is a +4

Assuming these numbers map towards their actual productivity, what is the actual productivity of this Sodor based development team?

Alfie + Arthur + Ben + Bert = 10 productivity points. So assume you can accomplish 10 "productivity points" worth of effort any given day.

Now the rest of the team isn't too fond of Ben professionally, Ben tends to introduce many bugs into the code, takes longer to finish tasks, and generally asks a lot of questions that wouldn't normally be expected of someone with his seniority.

Dennis the project manager knows that Ben is struggling, he has been working with Ben to improve his technical skills and get him more productive on the team. But so far there hasn't been much improvement.

Now Dennis is in a bit of bind.

The Sodor team has a big release coming up in the next few weeks, and Dennis needs to ensure he gets all the requested content in by this time. The team was building a new version of their flagship application, and thousands of dollars were spent on pre-release advertising. The deadline simply cannot be missed. Dennis is looking at the schedule and doesn't think he can get all the work done, he wonders if he should get another developer on the team, but he is wary of the rampup and training time. Not to mention the increased management overhead.

What would you do?

Instead, Dennis decides to do something a little more radical, he removes Ben from the team. It was a hard decision, Dennis carpools with Ben almost everyday to work. And no one likes making someone feel bad, but Dennis decided to do this anyway.

The productivity equation now looks like this:

• Alfie + Arthur + Bert = 12 productivity points

An instant case of addition by subtraction. Without Ben slowing everyone down with simple questions and build breakages, the team is now able to go faster and get more done. All with less actual time on the project.

Dennis meets the timelines and budget. A good day all around.

Macadamian has written about this way back in 2003, and the principle still holds true today. Negative team members drag your team down. It is the manager's job to identify the negative team members and work with them to improve their productivity, if their productivity isn't improving then you must remove them from the team, and perhaps with due course the company.

Sometimes drastic change is required for the success of the project. Drastic change is hard to undertake, but sometimes it has to be done.

What if software reviews were like this?

Can your copy of Windows Vista assault the beach with the Royal Marines? Or would it just sink the landing craft?

I am also pretty sure that a license of Photoshop couldn't rip around any mall fleeing any baddies baddies :)

Reading between the lines: A Bird's Tale

My son is four years old, and he attends a French language school. We live an a bilingual house, French is often spoken at home. Did I mention I am an anglophone with only a two year old's grasp of French?

Funny but true story, my wife was out and it was just the boys and I at home. The kids are bathed, I have read my son his bedtime story (in French!), and I am about to turn of his light when he says

"I want some 'oiseau'"

I think hmmm, that's an interesting duality of French and English but I understand. He wants a bird. I look around, and I grab his purple bird "toutou" and give it to him. Yes, it's as ugly as you are imagining. My son raises his voice and says

"I want some 'oiseau'"

Son I say, it's right here. Here is your "oiseau". "Oiseau" is bird right? My son starts crying. I look around, sifting through all the "toutous" looking for another "oiseau toutou", I can't find one. My son is getting frantic, he is kicking his feet and starting to go into 4 year old tantrum overdrive.

"I want some 'oiseau'"
"I want some 'oiseau'"
"I want some 'oiseau'"

Son I say, it's right here. Here you go, I pick up the ugly purple 'toutou' and and start flying it around making bird sounds. My son cries louder and now goes into 4 year old tantrum overdrive. I head downstairs and call my wife's cell phone number, maybe she knows what he means. I call, the phone rings on the dining room table.

&^#*($#*!

I head back upstairs, son I say it's right here handing him the ugly purple 'toutou' , my son says

"I want some 'oiseau'"
"I want some 'oiseau'"

Ah-ha, I get a bright idea, son I say, let's go looking for it. Is the 'oiseau' brown? Is the 'oiseau' downstairs? Is the 'oiseau' in the toy box? My son stands on top of the stairs looking confused and crying. Not knowing what to do, and the time ticking by, I give up, I tuck him in bed and let him cry himself to sleep feeling every bit a horrible father.

My wife get's home a few hours later, and I ask, what does he mean when he says "I want some 'oiseau'". My wife replies, oh, it's a song we sing.

$%#&*^@!

What is the moral of this long and only slightly humourous story?

Communication is key, and understanding what the customer is saying doesn't mean you understand what the customer wants. Understanding what the customer really wants is what separates the experts from the chaff. Knowing what the customer really means allows us to be world-class in our choices of technology, and innovative in our design and approach. Understanding is key.

PS:
In case you were wondering what song my son wanted me to sing, it was "Si Dieu existe" by Claude Dubois. A famous Quebecois folk singer. "oiseau" is in the chorus.

(Chorus starts around 1:34)

Innovation Story: Learning From Pixar

Last Thursday I was researching innovation to prepare for an upcoming OSEF event being hosted at Rove Mobile I came across a really interesting article about creating a culture of innovation at Pixar. Continuing in the theme of the last few posts I thought it would be interesting to examine what Pixar thinks, and to see what, if anything I can apply here at Macadamian.

Brad Bird distills 10 simple rules for fostering innovation:

1. Herd Your Black Sheep
2. Perfect is the Enemy of Innovation
3. Look for Intensity
4. Innovation Doesn’t happen in a Vacuum
5. High Morale Makes Creativity Cheap
6. Don't Try To “Protect your success”
7. Steve Jobs Says ‘Interaction = Innovation’
8. Encourage Inter-disciplinary Learning
9. Get Rid of Weak Links
10. Making $$ Can’t Be Your Focus

All these points resonant with me, but, let's focus on only two.

Look for Intensity
When I am interviewing people to potentially hire at Macadamian I look for people that are smart and have that spark in their eyes, that spark that denotes a deep passion for technology, and for what they have done and what they will do. I am sure that everyone at Macadamian looks for these same qualities, but when I looked on Confluence for the "Type of People we are looking for" that attribute wasn't listed, so the wiki being a wiki, I changed it.

Intense people want to do a fantastic job, there is no laissez-faire I don't care attitude. These people are passionate about the products we are building, they aren't just working on a project, they are building an amazing product. These types of people will "own" the product, they will talk to the customer and suggest features, or other ways to improve it. They want to build the best, most innovative product they can. This is a great attitude, and one of the key differentiators between the average, and the above average.

High Morale Makes Creativity Cheap
Not only does high morale make it easier to be creative, high morale increases productivity by several orders of magnitude. Morale is directly related to the leadership of the immediate manager, and of the company as a whole.

A good leader managing the team can go along way to improving morale via their positive attitude and their fair dealings with the team. I could go on and on about leadership's impact on morale but I would run out of space. Suffice it to say that a good leader can go along way to making a good team.

Of course the organization also has a role to play, the organization needs to create a culture that rewards people that take informed risks, works hard to get the employees involved and feeling informed, that people have the right tools to get the job done, shows genuine concern for all their staff, and gives appropriate praise and recognition for the good work they do. After all, you want to reward the good behaviour, not just punish the bad.

These two points resonated with me, and these are two that I will focus on here at Macadamian, to reinforce and improve our way of doing things with respect to these. Of course the rest are good too.

Consistency versus Excellence

A quick question for you all, if you are delivering every single project consistently, with good consistent results, have you achieved excellence?

At one point in time I might have said yes, but after reading this article I will have to say no. Unless you are in a field where everyone else are a bunch of numskulls, being consistent merely means meeting your customers expectations.

Of course being consistent is good, it means you are delivering your product or service in the same manner, allowing you to look for ways to reduce errors and flaws by providing new and improved processes to catch and eliminate them. That being said however, you put too many processes in place your team will look and act like a bunch of dumb robots, carefully following well defined procedures fearing to stray outside of the bounds. Hardly sounds like a fun place to work eh?

Excellence on the other hand is about going above and beyond, about not just achieving customer expectations but blowing them away. This type of performance requires passionate and driven people, people that will own the product and be devoted to its success. When pursuing excellence processes are only a tool to achieve a goal, they are not the goal themselves. Processes will never be emotionally tied to the product's success, only people are.

People drive excellence, processes drive consistency. If you are looking for excellence then don't look to process, look for passionate, driven people to push hard to always try and achieve more.

How savvy organizations motivate and inspire

Earlier this week I have talked about how to create an atmosphere of innovation, and longer ago how it is important to never stop learning.

In that post I talked about creating an atmosphere where informed risk taking is encouraged, and employees are not punished for mistakes they make when taking informed risks. This article further strengthens my point.

Dr. Gary Latham of the Rotman School of Business at the University of Toronto encourages employees to make errors. "The research coming out of organizational psychology says that if you want risk-taking and you want people to be excited and energized about trying new things, such as embracing change, they've got to feel comfortable that they can make mistakes and learn from them." When it comes to motivation, Dr. Latham says people want just three things: "They want a sense of challenge, they want to grow, and they want to feel valued and appreciated."

Three key take-aways in that quote are:

1. Employees want a sense of challenge
2. They want the ability to grow their career
3. To be valued and appreciated.

Number 1 is a leadership challenge. Well, everything could be distilled into a leadership challenge, but for the sake of argument leadership will be confined to an employees immediate manager. With number 1, a manager or leader needs to assign projects and tasks that are challenging, both technically, and by business domain. Of course not every single project in the world is interesting and challenging, but trying to mix it up for your team can be very beneficial with regards to productivity and morale.

Number 2 is an organizational challenge, sure there are aspects of leadership in this, as in the leader needs to understand how the employee wishes to grow their career, and giving him the tasks or challenges to accomplish that. But, at the end of the day, no matter how much a leader may want to advance the employees career, where the advancement means moving up the org chart, this may not be possible in every company do to existing issues, or lack of growth in the company.

Number 3 is clearly a leadership issue, yes, pay and benefits have something to do with this but where the rubber meets the road it's all about leadership. Thanking your employee for their hard work, or them going out of the way to finish a task, or recommend an improvement. At Macadamian our employees are our IP. We make a conscious effort to ensure that our employees feel looked after, both at an organizational level and at the manager level. A simple "Thank you, we couldn't have done it without you" can be a powerful statement on how you value your employees. Of course, it has to be sincere.

Fostering Innovation

Tonight I am moderating an OSEF panel on innovation, more specifically, how do you foster innovation.

How do companies create an atmosphere of innovation? How do they encourage their people to innovate? Companies like IDEO have become famous for their culture of innovation. And of course everyone not currently under a rock or dead knows how Google innovates.

So how do other companies innovate in these lean times?

The CIO has a great posting about that, I encourage everyone to read it, I won't bother trying to summarize it here.

We will remember them

IN FLANDERS FIELDS the poppies blow
Between the crosses row on row,
That mark our place; and in the sky
The larks, still bravely singing, fly
Scarce heard amid the guns below.

We are the Dead. Short days ago
We lived, felt dawn, saw sunset glow,
Loved and were loved, and now we lie
In Flanders fields.

Take up our quarrel with the foe:
To you from failing hands we throw
The torch; be yours to hold it high.
If ye break faith with us who die
We shall not sleep, though poppies grow
In Flanders fields.

By: Lieutenant Colonel John McCrae, MD (1872-1918)
Canadian Army

Today marks the solemn day of remembrance in Canada, a day to reflect upon the thousands of Canadians who have lost their lives defending the Canadian way of life, and helping those in need. From the Great War to Second World War, from Korea through to Bosnia and all the way to Afghanistan the brave men and women of the Canadian Forces have sacrificed greatly for the freedoms we enjoy today. It behooves us to take some time today to reflect upon their sacrifice and their hardship, and to remember all that they have done.

We will remember them.

Performance Reviews

It’s that time of the year again, annual performance review time. The time of dread for employees across companies, all sectors, and all over the world, cue ominous music.

Yes I have talked about this before, but it is a very important topic.

Why is this? Why are reviews so stressful for the employee and even the reviewer? Does it have to be? Couldn't the entire process be much less stressful? Perhaps even enjoyable?

Without a doubt.

Communication between leaders and their employees is essential to the success of projects, the professional relationship, all individuals involved, and the companies themselves. Communication breakdowns affect everyone involved. Esprit-de-corps decreases, productivity decreases, and the all important employee satisfaction decreases. Leaders need to deliver timely, accurate, and effective feedback to employees all year, not just at performance review time, though performance reviews do play an important role in this continuous process.

So why are performance reviews so disliked?

Most people don’t like to receive constructive criticism, and most people don’t like to give it. The manager and the employee need to set aside at least an hour to discuss the good and the bad of the year. For the manager, especially the new manager, it can be one of their most daunting tasks. For the employee, they stress about their performance, and the salary/bonus numbers that may also come with it.

How do you make performance reviews less disliked?

You need to tackle the problems of performance reviews, and work hard to alleviate them.

Problem 1 - The surprise review

A common problem, and a huge cause of stress for employees. Basically, the manager doesn’t schedule the review in advance, leaving the employee to stress about it—in some cases the employee doesn’t even know a review is due. Then WHAM, one day when the manager has 20 minutes, the manager pulls the employee into a surprise review. Or, even if the review is scheduled, the employee doesn't know what to expect, and not sure of the feedback he will receive.

When this happens, the employee walks into a big, stressful unknown. But it’s an "easy" one to solve.

Managers need to get into the habit of keeping their employees informed all year long of progress towards their goals, and how well they are performing their jobs.

If they are doing a great job, tell them so! Throughout the year, you want to praise and reward good performance to reinforce it and encourage more of the same. And if the performance isn't so good, you need to let your employee know as soon you realize this. It’s only fair to the employee. And it’s good for you because it allows them to correct their behavior as soon as possible. It’s the manager's job to mentor them, ensuring they have the tools, training, and opportunity to succeed. It will also be easier on you, the manager, as you can work with the employee to improve the performance before it gets to the point where it is critical.

Another key benefit of keeping your employees informed of their performance throughout the year is that you can focus more on their goals and career planning during the review, after all, they already know how they did. It will be an opportunity to build relationships and discuss the future.

Problem 2 - The last 2 month review
Annual reviews are, well, annual. They need to encompass the whole year, or at least the time since the last review (if you do twice yearly reviews). It is often easy to focus on only the last few months since that’s what you remember best. But that’s unfair to your employees.

One trick I use is to keep notes on all the people I work with throughout the year. Not because I‘m keeping track of them, but because it lets me remember the significant and not so significant events throughout the year. This helps the manager or leader when it comes time to write the review and makes the review more honest and objective.

It’s easier to remember the bad than the good, and it is easy to focus on just the bad to the detriment of the good. Keeping notes will help alleviate this. It would not be fair to the employee who had a stellar year, but made a mistake in the last month of the review cycle to focus on just that mistake.

Another benefit of keeping notes throughout the year is to ensure "data integrity" as you won't be struggling to remember the facts. Of course when in doubt, double-check your facts.

Problem 3 - The unprepared manager
Nothing is worse for an employee to see the manager "wing it" during the review. Perhaps they are writing it front of the employee during the review, or are not prepared to discuss goals and career aspirations. Managers and leaders need to spend time ahead of time to write the reviews, and think about how they will conduct the review. So start the process early, and schedule lots of time for the actual review. Also, don't schedule them back to back, it’s hard to predict the end times and you don't want to cut it short just for the sake of your three o'clock.

Problem 4 - The one sided conversation
A review should be a two-way conversation. In fact, it should be a 80/20 conversation. (Isn't it great how often the 80/20 rule comes up?) where the employee speaks 80% of the time. After all, it is about them. Provide your feedback and let the employee do the talking. Most of the review should focus on employee reactions and takeaways from the discussion. Don't talk just to fill the awkward silence.

Problem 5 - The inaccurate performance review
It goes without saying to be honest and fair in the review, and not to play favourites. Everyone knows this. That being said, also don't wimp out! Don't gloss over the negatives in order to maintain relationships, or because it’s too hard. Addressing real problems, especially the ones about employees, is one of the hardest parts of a manager's job. It’s an important part of being a good leader.

Macadamian, a great place to work!

For the third year running, Macadamian has been awarded as one of the top ten places to work in the National Capital Region.

Employee satisfaction is a key element in retention of employees. Happy employees are productive, engaged, and motivated employees.

Good work to everyone involved!

World Usability Day

It seems like everyone has a world day now-a-days, so why should usability be any different? Usability is certainly important.

How many times have you seen a door that confused you? A fire exit that opened inwards? A set of switches that didn't relate to anything you have ever seen before? What about a computer application that confused airbrushed metal and rounded corners with actual ease of use?

Usability is everywhere, it impacts everything in our lives, so, next time you see a friendly neighborhood usability person walking around, stop and give them a hug! They could use it, they have a hard job actually getting people to understand the importance of usability.

Macadamian and OCRI are holding an event in honor of World Usability Day, I will be there, will you?

Happy Halloween!

Trick-or-treat,
Smell my feet,
Give me something good to eat,
Not too big, not too small,
Just the size of Montreal.

Safety Tips:

• Select highly visible costumes. Look for light, bright and reflective costumes that make trick-or-treaters easy to see. Add reflective tape to costumes and treat buckets and bags to increase visibility.
• Make sure costumes fit well. Have trick-or-treaters try on, walk and play in costumes and shoes in advance to check fit. Make sure nothing comes loose or might cause the child to trip. Check that wigs or other accessories do not obstruct the child’s view.
• Review safety precautions with children. Include traffic safety rules in the review, such as staying on the sidewalk, crossing the street at crosswalks, avoiding walking in front of, behind or between parked cars and stopping at driveways to make sure no vehicles are coming in and out.
• Plan trick-or-treating route and supervision in advance. Avoid areas with heavy vehicle traffic and look for well-lit streets with sidewalks. Make arrangements for an adult or a responsible teen to accompany younger trick-or-treaters.
• Get a flashlight with fresh batteries. A flashlight can help trick-or-treaters see and be seen, but it should never be directed at someone’s eyes including those of passing motorists.

Leaders never stop learning

It is said that leaders never stop learning, a true leader is always looking to expand his horizons and bring new knowledge and skills to the table. People are more willing to follow a leader that has demonstrable proficiency in the area that they are leading their people in.

Here at Macadamian, the leadership group is very committed to continuous learning, it fits in with one of our values of "Constant Improvement"

Our Director of IT and Process Improvement is always handing out new books to the leadership group to read. It is quite hard to keep up on all the interesting reading being passed out and my own personal reading and training.

Book learning is one way to learn, and it is a useful way, but it is only one of many ways. Most people learn best by learning through experience. You can learn from a mentor, from working on a project, from taking a chance, or from failing.

People don't like to learn from failing because people don't like failing. It is stressful, you feel bad, and a generally annoyed at yourself for making the mistakes you made.

But, failing is OK, you learn from it. Organizations must create an atmosphere and culture where failing doesn't result with a firing or other punishment as long as the failure wasn't caused by negligence or malice.

An atmosphere of informed risk taking can lead to absolutely amazing results, and advances in technology and product design. At Macadamian we learned this long ago, if people were fired for a project that goes red, or worse yet, infrared, many of us at Macadamian would no longer be at Macadamian, and Macadamian would be bereft of some amazing and talented individuals.

Of course not all mistakes made result in such drastic results, sometimes the mistakes are from choosing the wrong technology, or making an assumption that doesn't pan out. We at Macadamian try to encourage our team to take informed risks in order to deliver high quality projects as quickly as possible. You can't always wait to get every single fact before acting.

I have often said, that the success of leader is not in the mistakes they don't make, but how they learn from the mistakes they do make.

People are people, cash, hardware, and hog heads are resources

Props to Matt for sending this to me.

It was a brief consulting engagement. Version 3.0 was behind schedule. I was privy to this product planning meeting but still naive about corporate lingo. At first I thought "resources" meant money or time but it didn't compute.

Finally I realized that "resource" meant "human." Or, in this case, "software developer." Oh.

I hate it when managers and executives refer to the highly talented people on their teams as resources, it completely dehumanizes them. I have noticed managers making this mistake for years, and whenever I have heard it, it was like nails on a blackboard.

I remember way back back as a young(er?) officer of making the mistake of referring to members of my platoon staff as resources in a company meeting. The company commander laid a private smack down on me that I have never forgot.

It is really easy to switch into this PHB speak when talking about management and operations matters. But it is something all good leaders need to fight against. After all, many of these co-workers are also your friends, and you would never refer to your friends as resources would you?

Remember, despite deadlines, pressure to deliver, and customer demands, your team is comprised of people, people with friends, family, and commitments outside of work. Your computer can work 24/7 but not your team. Always thinking of your team as people will help you remember that they have a life outside of work. It is your job as their leader to promote a healthy work/life balance at all times.

At the end of the day, like Soylent Green, resources are people.

I, for one, welcome our Android overlords

Ok, sort of. The first Android based device has been released.

What makes Android great?

• Well Google is backing it, that will help
• The core of the operating system is based on Linux
• The platform itself is open source, using an Apache 2 license
• Any application can be extended, removed, or completely re-written
• It is open, in stark contrast to the iPhone
  

In theory competition is always good, but, currently there are 3 major smartphone categories:

• Apple's iPhone
• Microsoft's Windows Mobile offerings
• RIM's Blackberry

We should also count Nokia's Symbian class devices as well, but they are not much of a player in North America. Nokia has also taken Symbian open source, though one could argue that is a last gasp effort to stave off death.

Android will add a fourth (or fifth) credible smartphone class to the market, ISVs who create third party applications may yet another class of devices to support. This is expensive.

Also, what is the killer Android application? Other then the fact that Android is open source, and infinitly customizable, why should my mother care? What is the benefit to normal users? Sure, us techies are excited, but are we representative users? Not really. I cannot tell you which target user the Android is targeted to. This is a common issue when engineers get to run amok.

I am also not sure I trust Googles motive's here, first looks I would say it more suited to push Google's agenda then consumers or business users. The T-Mobile G1 (the first device) doesn't support Exchange, which is a real deal breaker for the business users. The email client itself looks to be a "rich HTML" client.

Based on what I have read to date I am not convinced this new smartphone is ready for primetime. Some of the major complaints I have read include:

• Google accounts are tightly integrated with the phone, trying to change an account necessitates a factory reset (!)
• There is no desktop syncing application, Google contacts and calendar are considered the masters
• No video playback or recording
• No multi-touch on the G1 (hardware issue)
  
• No headphone jack
• You must have an SD card for any kind of music or video (when it arrives) playback
• Downloading music tracks from Amazon's store (not sure about others) can only be accomplished with Wi-Fi. No 3G!
• Text entry only possible via the keyboard, their doesn't seem to be a SIP

The common solution to these concerns is that the developer community will take care of these missing features and applications. Yes, because that has worked so well for Linux on the desktop :)

Google seems to be relying on the developer community to fill in the gaps, this to me seems dangerous, it also indicates that Android was rushed a bit.

All in all the Android is cool, it is innovative, but is it ready for primetime? I think Android, like Chrome is more to push the existing smartphone makers (and browser makers) into the direction that Google needs to extend their empire to ever more devices.

What do you think?

It’s a small world after all

Sometimes it’s just amazing how interconnected we all are.

The other day I was talking about tools and methodologies with one of our new customers. This customer is using Scrum for their methodology, and as we were discussing how to integrate our team with their team the concept of how to virtualize the post-its and index cards that are so welcomed by the Agile community came up.

Luckily, the customer is already using Jira, and to add the index card virtualization they are using a tool called GreenHopper. To read more about GreenHopper click here, and here.

So I looked at the tool I could see a possible fit in our methodologies here at Macadamian, see its potential I talked to our Director of IT and Process Improvement about possibly trialing the software.

At this point I found out he met the company who makes the tool at a job fair in Sherbrooke earlier this week and talked about some of the Jira plug-in they make.

Its always amazing to see how interconnected everyone is.

35% of Users Would Choose Blackberry over their Spouse - Today's Professionals Connected to Work 24/7 - Even in the Bedroom

Today's Professionals Connected to Work 24/7 - Even in the Bedroom
To coincide with Global Out of Office Day, Sheraton today announced the findings of a Work-Life study it commissioned to gauge the work habits of today's professionals. New technology continues to transform the way we live and work with 85% of U.S. professionals surveyed said that because of new technology, they feel compelled to be connected to work 24/7 and 81% say they work harder than they did five years ago. So just how addicted are we as a society to staying connected? Well, the vast majority of people (84%) say they check their PDA's just before going to bed and as soon as they wake up, 85% say they sneak a peak at their PDA in the middle of the night, and 80% say they check their e mail before morning coffee. A whopping 87% of professionals bring their PDA into the bedroom, and in what may or may not be a related finding, more than one-third of folks surveyed (35%) say if forced to choose, they'd pick their PDA over their spouse!

Video report here.

I do realize that the Blackberry is a sleek little number, but this is taking it to the extreme. People need to turn ignore their Blackberries when they are on their personal time.

Recently, the department of Citizenship and Immigration Canada has banned the use of Blackberries from 7pm to 7am to help combat this problem. The department will also be implementing a few other improvements to help improve the work life balance. They ask employees to ensure meetings end on time, and are not scheduled over the lunch hour.

Personally, I am not in favour of work meetings over the lunch hour. The lunch is hour is my personal time, and I will choose to do what I want in the hour. If it is to sit at my desk and work so I can head out early, or chill out and school some people in foozball it will be my choice.

It is important for everyone to have the ability to unwind and relax during the day, it will help them remain more productive, and better motivated.

Form Square! Let your values protect you

In historical context, an infantry square was formed to protect the infantry against the highly mobile, fast moving threat of Calvary. The defense against this was for the infantry to "form square".

When you think about it, the "threats", the work, and the competition for your attention in today's fast paced high-tech environment require an all around defense to protect you.

I have found that the best way to protect myself was to rely on the value system here at Macadamian.

You can counter any "threat" or emergency requiring your attention by living and breathing these values. All 5 of the values the comprise of T.R.A.C.C will help guide you in making the tough decisions that are required of today's leaders.

When the need for UX expertise is all too clear

When I saw this I felt a great disturbance in the UX Force, as if millions of voices cried out in terror and were suddenly clawed out their eyeballs. With apologies to Star Wars.

I was using a new piece of software the other day for my other "job", and when I launched a particular feature this lovely pop-up above came up much to my amusement and eventual annoyance.

There are so many things wrong with this dialog to really discuss in depth, but suffice it to say this dialog is launched every single time this feature is launched. Every. Single. Time. And the the question never changes.

In the workflow this pop-up is followed by another pop-up that intones an important message.

It is so important that they always show it. Every. Single. Time. In fact it is so important they even truncate the message so that it doesn't all show on the message box. So you don't even get to read the entire message! That's just how important it is. After all, you can't handle the truth.

With thousands of people being mandated by regulations to use this application I guess you don't need a good user experience. I mean, who likes their users to enjoy working anyway? End sarcasm.

For those of you who are dying to ask what happens when you hit "5", I did. And this was the result.

I kid you not. Seriously, I am not making this up. I am not allowed to make this up. And the admin dialog you get after this message box is still in English. And that admin dialog is still the same admin dialog you get if you answer correctly.

I am not sure what this is supposed to imply. :)

Google Chrome

The rumoured Google browser has finally arrived. To be honest I am not sure whether I should rejoice or cry. Their innovations are great in typical Google fashion, but I can't help but think this will seriously hurt Firefox. Oh, and yet another browser for web developers to support can't be fun either.

I can see the limitations list in my proposals growing :)

It is important to connect the dots

Recently I had the misfortune of overseeing a project that seemed it would be a big success-- but failed at the last minute. We had two talented developers, we accomplished all of our work just in the nick of time, and the work that was done looked very good.

Seems like a successful project no? The issue was that we didn't get paid for all the work we did. This made it unsuccessful from at least that point.

The root cause of the issue was my failure to "connect the dots". I told the customer we were adding another developer to the project in-order to get the work done in their time lines. I had warned them about that before hand as well. Since this was a Time & Material project this notification seemed sufficient to me. To me it was obvious, the customer disagreed.

When I used to write code, I always preferred to be explicit. That is, not rely on implicit casts or other operations. In this case, the increased cost was merely implicit in this case. Yes, they should have known, but I didn't mention it explicitly.

The lesson to learn out of all of this is that it is important to be explicit, and to connect the dots. This will leave no room for interpretation or mis-communication.

Agile Noir

For those of you familiar with Agile methodologies, you may find these humorous.

Agile Noir, a film adaptation, and their comic serial.

Agile Anti-Patterns - Part I

In this first of what I hope will be a series of posts about agile anti-patterns that I have either observed at Macadamian, or learned about when I attended the Agile 2008 conference during the first week of August. I am going to talk about the "Hierarchical Anti-Pattern". This is one of the most common anti-patterns I have seen, I have just never though about it before. This is something that I touched on briefly in my last post but am expanding here.

In the "Hierarchical Anti-Pattern" the lead in your team at your global centre does all the talking. In this anti-pattern the person with the most rank or seniority does the talking, not necessarily the person with the most knowledge. This is something that is very common cultures that are very hierarchical, and it is even more prevalent if you are using third party contractors as your offshore development or testing team.

The situation is worse with third party contractor teams as they are your customer! And you have a customer. That is a lot of levels of indirection! Since it is common that people don't want to pass bad news on (not us at Macadamian though right?!) they will be less forthcoming when their is bad news.

Of course we all know that we want the bad news as soon as possible so that we can react and hopefully address the issue.

You cannot allow this situation to develop on your distributed team, the lead in your offshore centre cannot cover for or protect someone on their teams. It will only breed resentment and hostility, and could obscure the true status of the project.

So what can you do?

1. Everyone dials in from their desks
2. Everyone stands up during the call (you know, a stand up meeting)
3. Everyone speaks for themselves
4. Empower your team
5. Ask probing questions
6. Video conferences
   

One of the easiest ways to help prevent this anti-pattern by ensuring that everyone dials in from their desks for their daily scrums. This will help avoid the side conversations that are necessary for this particular anti-pattern.

You can also (and this one is hard and sort of goofy) have everyone stand at their desks while on the daily scrum call. This one is hard to enforce without web cameras but can also help prevent the side conversations via IM that are required for this anti-pattern. It also has a nice side benefit of preventing the team members from multi-tasking, or even reading /.!

During the actual scrum, you should be sure that everyone speaks for themselves, and that the person you ask the question of answers that question. Ask the question to who should be the subject matter expert, be polite but firm. This can also help expose team members that are coasting or not pulling their weight.

You should also work diligently to create the collaborative atmosphere where team members regardless of rank or seniority feel empowered to speak their minds, and voice their concerns. You can help foster this by asking the team what their thoughts are? What are their suggestions? What can they do to help? Don't isolate all the decision making power on shore.

It is very important to ask probing questions to get to the bottom of the status. Ask questions about the state of development, testing, how much effort is left, what if anything is blocking, how it will be implemented etc. This is related to your delegation technique, and is also extremely important when dealing with with anyone on your team regardless of where they work. Also keep in mind their seniority when validating their answers, sometimes juniors haven't thought their entire way through the problem, they can rely on their lead in these cases to help guide and mentor them.

Video conferences are good to help pick up the quiet guy sitting in the corner of the room. It will also help you see any confusion that might not be prevalent on just a voice call, and allows you to more easily build trust with them as you can see each other. Just don't let technology get in the way of the communication. Don't spend 20 minutes setting up for a 10 minute call. That is not efficient.

There are just a few easy ways to help prevent and correct this anti-pattern, does anyone else have other ideas?

"OK" is not "OK"

We all know one of the most common causes of project failures in distributed development is poor communication. However, even with constant communication, wiki pages, Skype etc communication can still poor.

Actual language skills (word mastery and accent) and culture can still hamper smooth communication.

To help with the language skills, you can use a tool like Skype where you can talk and type. Sometimes accents and speed of talking can make it hard to understand, in this case you can fall back and use a combination of text and speech. Video conferencing or web cams can also help. Sometimes you see the confusion, but not hear it.

You should also avoid slang and pop culture references like the plague. This can be hard, after all it ingrained in our method of speech. I remember recently I used slang in a quick email I sent to someone with whom I have worked with for years. I said "she's down with that". Of course, I know it means she is happy to do that, he thought the opposite. :)

Culture is always the big elephant in the room. No one wants to address it for fear of being labeled a racist, bigot, or something. This is poppycock. It is vitally important to be aware of it so you know how to tailor your communications to help alleviate it.

For example, in English Canada when someone says OK it is often a short form for "yes I understand and will do it". This is not the same in India for example. Often, when someone on your team responds with "OK" from India it means that they heard it. They may not have understood it, and they may not have agreed to do it either.

You need to fall back on your delegation techniques. These techniques are useful for everyone regardless of where they live or work. After assigning a task or making a request, ensure the recipient understood by asking them questions about the task. You can ask them how long they think they will take, what strategy they will take to complete the task, confirm with them when it has to be done etc. The point of this is not to micro-manage, but to assess the level of understanding so you may act accordingly. Due to the timezone differences, misunderstandings can add a lot of time to your critical path.

Another common issue that is prevalent in some cultures is the deep seated hierarchy based on seniority. In agile teams, all the team members have to be empowered to take decisions, be able to ask questions to the team leader, the customer, or whomever. However, often what happens is that the senior person on the team fronts for the rest of the team. You can tell this is happening because you never hear from the rest of the team on conference calls.

You can help alleviate this by:

• having everyone dial in from their desks, this will help reduce the side conversations that are necessary in this arrangement;
  
• you must also emphasis that you want active feedback from the entire team, you will need to keep emphasizing this and working on it over the course of several months. You can help reinforce this by explicitly asking questions to the full team;
• video conferencing can also help for those group meetings, it will allow you to see the quiet ones and "pick" on them to contribute.

These are just some quick ideas I have thought of or used in the past. Does anyone else have other suggestions?

Agile 2008 - Part V

Today was the last day of the conference. The morning session I went to was titled "Beyond Agile! Product Innovation Debate: What and who drives innovation?"

It was an interesting and lively debate between the panelists and the audience. The attendance was low (likely due to it being Friday and people flying home) and this allowed a lot of audience participation.

I came up with many nuggets out of this session which will make an article itself, but I will mention the two key issues with innovation and agile that at least some of the panelists argued and I agreed with:

• Agile can produce products that are consistently mediocre
• Agile relies too much on participatory design

Agile 2008 - Part IV

Thursday was an interesting day. I attended seminars on Continuous Integration and some experience reports on the good and bad of offshore development.

The 100 days of CI was an experience report from a development manager at Microsoft in the Tools and Patterns division. Based on their experience, they learned that they had a 40% savings in time in fixing the broken builds over their old process.

The speaker also talked about the following best practices:

• Over spec your CI machine, nothing worse then having down time due to insufficient disk space or resources;
• Add additional daily or nightly build times. After all, what is the nightly build here is not the nightly build in India;
• Capture the data, your CI machine allows you to capture lots of metrics, so do it;
• Warnings are errors. Integrate your static analysis tools into the build. Treat their warnings as errors;
• Don't check in then go home, you may have broken the build;
• You break the build, you fix it.

The banquet was also quite nice, the keynote speaker was very engaging, and witty. Also, apparently a Republican :) The one really interesting point he made is that the benefit of TDD has been proven. If you don't adopt any other agile process, adopt TDD. I have given myself a task to research the research on TDD.

Agile 2008 - Part III

So today marks my third day at the conference, and I have been keep pretty busy meeting people and talking agile.

Today's discussions revolved around trouble shooting distributed agile, agile patterns, and success stories with distributed agile.

I also was able to discuss patterns with Keith Braithwaite the author of several papers on distributed XP. You can read the PDFs here and here.

The success stories about distributed agile was also pretty interesting. The first presentation was a joint presentation between a company and the co-inventor of scrum. They had some metrics up that showed how they were able to achieve the mythical "hyper-productive" team. A "hyper-productive" team is defined as a team that has achieved a state of ownership, collaboration, and commitment that allows them to be much more productive in creating value on a consistent basis.

Another interesting metric they had was their 0.5-1.0 defects per thousand lines of code! That is incredible. They defined defects as issues raised during acceptance. They were able to achieve this by creating an impressive suite of unit tests, and automated integration and acceptance tests while still keeping their velocity of over 15 function points per person per month.

One of the other presenters was a small company called Code71. They are a small boutique global IT solutions and services company. They are using a model that is very similar to ours. Their remote office is in Bangladesh.

It is interesting to realize that Macadamian was doing distributed agile way ahead of the curve. When we first started experimenting with this back in 2003, the prevailing school of thought was that this couldn't be done. It is a good thing we didn't realize this :)

Agile 2008 - Part II

Well, I have survived day 1 of the conference. It is a pretty long day here with the presentations starting at 08:30 hrs and ending at 17:30 hours. Of course we get some breaks :)

In the interesting facts column, there are over 1548 attendees from 42 different countries. 42. I wonder if there is some significance to that? :) Also, 22% of all the attendees are from outside of North America. I would say the US makes up the largest segment of attendees. I have run into more Americans then Canadians so far.

In the seminars I have been in, I would have to say that Macadamian is very advanced in our distributed agileness. So far the majority of people I have talked to do distributed agile on shore, that being that they have teams in different parts of the country. Some do do distributed agile across multiple global centres.

Also, many of the patterns that Macadamian holds dear about how to do distributed global agile are being validated by the people I meet and the seminars I attend.

The one universal shortcoming I have identified so far is our lack of travel. At Macadamian we follow the Ambassador pattern. See I learned the name for what do here :) This pattern is where someone from one of the labs travel to another one of the labs to work there for a few weeks. Where we fall short is the frequency of this travel.

Ideally we should have an ambassador travel to one of the labs (or to our HQ) for the start of every significant project. This isn't something we are doing current. In this model, the travel time could be one or two weeks instead of our standard three weeks.

Basically, the premise of this model is to either pay the cost of the face to face time now, or later in the project with lost productivity, rework etc. I think it would be interesting to examine the possibility of this approach on some of our longer/bigger projects. The impact of this of course is to price this ambassador model into the total cost of the projects.

Agile 2008 - Part I

I have flown into Toronto for the week. I am attending the Agile2008 conference. The conference looks pretty darn good. The main topics I am looking at attending are Distributed Agile and Leadership and Teams.

Shameless plug for Porter airlines, the flight was only an hour, but they served food and alcohol. Sweet!

The hotel seems good, but the rooms are quite small. As you can see from this photo, I practically had to stand in the hallway to get this shot.

Sometimes I feel like Bill Murray

What now seems like a very long time ago, Bill Murray starred in a little film called Groundhog Day. Sometimes I can really relate to that film, we keep doing things over and over.

At Macadamian, we take a lot of pride in "Constant Improvement", in fact its one of the Cs in this blog title. As part of this process, at the end of each project we do what we call a "Phoenix Session". Also known as a project post-mortem. One of the outputs of this process is what we call the "Lesson Learned". Usually, we learn at least one lesson, sometimes two.

The problem with this process is that the "Lesson Learned" gets documented in Confluence, and becomes "Yet another page no one ever seems to read". Many of these "Lesson Learned" are very insightful and useful, and while we send them now to the entire operations leadership, we fail to teach them to our project champions.

This is true for PL101 training in general. We are all so busy, we often rely on what many call OJT. Out of the most recent batch of "Lessons Learned" there was one re-learning what was actually documented in the "Client Deliverable" process. Documented on Confluence. Oh, and its actually the first page in our PL101 training.

I don't blame the champion for this, that person didn't have the knowledge or the skills. I blame us. We as an organization have to better support our champions, PLs, and new developers.

This will help them not feel isolated and left out to dry. We already have a mentoring program for new employees, now we need to extend this to new champions, PLs, and of course, PMs.

What makes a good team lead? Part Two

A week or so ago I had a post about what makes a good team lead. In this post I had a list of statements that I would look for in my team lead. Many of these statements can be derived down to base personality qualities such as being:

• Decisive - It is almost always better to take a decision with 80% of the information then it is to wait for the other 20%. Overall you will get more done faster.
  
• Enthusiastic - Enthusiasm is contagious, it will inspire your team
  
• Responsible - Do the Right Thing. It is also a mantra at Macadamian.
  
• Honest - Does this need explaining? Nothing destroys trust like not dealing with people in an honest and fair manner.
  
• Dependable - Make your commitments, be there when needed.
  
• Confident - People are more apt to follow you if you appear confident. Show confidence in your team.
  
• Courageous - This goes with "Do the Right Thing", also goes well with being "Transparent". It is hard to tell the customer that you are late, or to tell the employee that they are not meeting expectations. You should also be courageous enough to stick to your convictions, or try something new.
  
• Loyal - Always try and do the right thing for your team. Go the extra mile for them.
  
• Patient - This is one I have trouble with the odd time, but be patient to answer their questions, help them with a new technology, or to understand a new requirement.
  
• Determined - Get the job done.
  

To me, these are the 10 important qualities of a team lead. Does anybody have others to add?

Reviews should never be a surprise

Over the past few weeks I have been dealing with a yellow project of mine. The project is yellow because of the customers perceptions on the design, code quality, and general attention to detail demonstrated by the team over the 3 month project.

Now I had sought out feedback on how the team was doing several times throughout the project, but never received an answer. During the project debrief, the poor performance was brought to my attention. Unfortunately, at this point there was nothing I could do about the current project, and could only try to improve on the next project.

Like praise and recognition, being told you are not meeting expectations is very important. If you are not told otherwise, you may very well be thinking you are doing a great job.

I understand that sitting down with an under-performing team is hard, often the leader will be comfortable. It is hard to do this. However it is absolutely imperative that this be done.

If we don't take action on this right away then many bad things can happen:

• resentment builds within the rest of the team
• the leader starts to resent the under-performing team or individual
• features have to get dropped due to time constraints
• quality suffers
• etc

The top two are real team killers.

A meeting discussing the expectation gaps, and a plan to address these gaps will go along way to improving the under-performing team or individual. If they don't improve, then you have at least started the process that is required to remove them.

At the end of the day, it is a leader's responsibility to make sure all their team members always know how they are doing, whether it is good or bad. It's our job.

What makes a good team lead?

In a previous post, I talked about what I think makes a good team member, and in order to be a good leader you must be a good team member.

So as a leader, you should think about what makes a leader good from the eyes of their team. Is it their movie star good looks or their willingness to bring in donuts? I sure hope it is neither even if you like donuts.

Your team (and you) hopefully look for most of the following statements to be true when thinking about your team lead or manager:

• be an excellent communicator, and good at using the tools at their disposal to plan and organize the team's work load;
• be self-confident, and strong within their domain of knowledge;
• makes reasonable, objective, and consistent, decisions within their boundaries;
• be able to mentor and coach the team to achieve maximum performance;
• be able to inspire the members of the team;
• to understand and choose the correct style of leadership based on the situation;
• to demonstrate integrity at all times;
  
• to be trustworthy and honest;
• to be an excellent problem solver, both with anticipating and solving the problems;
• to be able to handle stressful situations
• to respect you.
  

So, can anyone think of anything else to add to the list?

T&Ms should really be called "Time for Money"

Macadamian has several engagement models, the two most common models are Fixed Bid and Time and Material (T&M). Both are relatively common. However, I have come to realize that T&M contracts don't exist. They are this mythical creature -- like the phoenix -- fabled to exist, but rarely seen in their true form.

Why are T&Ms rarely seen? Because I have rarely been able to bill any material to the customer. It is the cost of doing "business". This means that any material we need for the project comes out of project margin. On shorter projects, this can mean a significant percentage.

The only real solution to this is to make sure you have thought of this upfront, planned for it, and let the business development folks know upfront. That way they can ensure it is covered in their margins.

The other thing we can do is stop calling them T&Ms. Perhaps we should simply call these "Time for Money", "Team Extensions", "Expert Time", or something really clever that shows our expert kungfu.

Long weekends mean long work weeks

At the start of the summer, I planned to take a few Fridays off in-order to have some long weekends. After all, who doesn't want to have some long weekends in the summer?

There is just one problem with this, I ended up working quite a bit more then 40 hours in the week. I found that I would work almost a full day extra in the week I would take a long weekend.

The Thursday before and the Monday afterword were stressful as I tried to wrap up 40 hours of work in 32, and then catchup on Monday.

After a two weekends, I decided to stop. Instead, I resolved to take at least a week off from work when I take vacations. This way I can completely unwind and not stress about half finished jobs back in the office.

It is really important to unwind on your time off, and when I am off for a week, I don't worry at all about work.

9 Reasons Why Application Developers Think Their CIO Is Clueless

An interesting article describing some reasons why developers think CIOs are clueless. This can likely be extended to DPMs here at Macadamian and any management position. Luckily, at Macadamian all our DPMs are ex-technical or UX people. This means, at least we understand our respective domains :)

PR, part of your complete breakfast.

No, I don't mean "Public Relations", in this case, I mean "Praise and Recognition".

We all like to be told when we are doing a good job. And a kind thank you, or a pat on the back goes a long way in making us feel as if we are appreciated. This is an important principle of leadership. But, it is something that I have noticed is becoming less prevalent. This is a big mistake.

Companies are spending millions of dollars to increase productivity, implement flexible hours, and increase health benefits, yet they still have high turn over. Why is that?

These policies get taken for granted. A company increases their benefits, attracts new people, other companies follow suit to compete. Soon these heightened benefits become the norm, now to differentiate themselves, companies need to raise their benefit packages and policies again.

I think that PR is especially important in a company where we strive for constant improvement. A culture of constant improvement can result in a culture of constant criticism. I have thoughts on that too.

Most people like to be praised and recognized for the work they are doing, most people like it a lot. A leader must strive to make their team feel important, to create environments where people are rewarded for their hard work and successes.

This is the benefit of rewarding, it is one of several ways that a leader can rely on to influence behavior. With rewarding, it is based on a leader's ability (and perceived predisposition) to praise and reward their their teams for positive behavior.

Praising/rewarding people doesn't cost anything, makes the employees feel good, and reinforces positive behavior.

So remember to say thank you, and remember to tell your team when they do a good job. It is just as important as telling them when they didn't.

How to be a good team member

Leadership is often discussed in terms of how to motivate your team, the principles of leadership, and all the other skills and traits that make a good leader. But, one of the most important skills of a leader is actually how to be a good team member. In other words, how to be led. This is the first (key) step in becoming an effective leader.

A bad team member really affects the esprit-de-corps of the whole team. This can lead to:

• reduced productivity
• an unhealthy work environment
• high attrition rates
• negative cliques
• favoritism
• etc

People who are bad team members, will become awful leaders.

So how do you work towards becoming a good team member? Follow these simple guidelines:

• mind your manners, treat your fellow team members in a respectful manner
• admit your mistakes, and learn from them;
• do the right thing for the project;
• comply with the direction set by your team leader;
• be a positive influence on your team;
• accept constructive feedback;
• help your fellow team members;
• be transparent about your status;
• be honest about your abilities.

In reality, these could almost all be summed up by one, "Do not do unto others as you would expect they should do unto you."

Nothing in here mentions that you must mindlessly follow the directions of your project leader in an unthinking drone like manner. Just realize that there is a time and a place to question the direction of your team leader. In front of the customer, or on team call is not the time or place to do so.

Don't be a barking phone

Last night I was talking with one of the other DPMs (I shall call him Toby) here at Macadamian. We were talking about the perception the developers in our global R&D centres have of us.

Toby traveled to Romania and ended up spending nearly 2 weeks there. After he was there, peoples perceptions of him changed. The old perception was that he was an angry person, always mad at something. After Toby visited them in person, they realized hey, he is a pretty swell guy.

Why did they think he was an angry person? It was because most of their interactions with him were not very positive:

• emails that seemed blunt
• VoIP calls when they were not performing, or had made a mistake
• asking them to do something
  
• emails asking for status
• etc

All these interactions where either Toby was in charge, or performing corrective actions.

So what changed on the trip? Well, Toby did these sorts of things:

• talked to them socially
• had dinner with them
• played poker
• drank Romanian plum brandy with them
• etc

In short, they realized that hey, Toby is a person, and pretty swell too! It was not that Toby was trying to butter him up, it is just how he is in person.

You as a team leader need to be seen as a person, sure, you are in charge, and you are accountable for the delivery of the projects, but your team is comprised of people and no matter how many times you tell yourself, yes, you are only human.

So, if you are leading a global team, try to visit them in person, and when you can't visit them in person, make sure to follow these simple tips:

• Prefer voice calls over email
• When you need to send emails, try reading them aloud to see if they seem harsh or overly critical
• Don't talk just about business, try to have a water cooler chat every now and again
• Ask questions like, how has your day been? I heard you were sick yesterday, are you feeling better?
• Try and schedule the meetings in common hours, if you cannot, try to alternate the times they have to stay late versus you have to come in early

Remember, you don't have to be their friend, but it really helps for you not to be their enemy. And in your spare time, start working on the virtual foozball game for those ad-hoc games, err, I mean design sessions.

Congratulations Marc!

Last night our very own Marc Dufresne was honoured as one Ottawa’s Top 40 under 40. This is a pretty impressive achievement, great job Marc! It couldn’t have happened to a nicer guy.

In other nearly as impressive news, our table was named the best table to be stuck at a cottage for a week. Who has team spirit? We have team spirit!

Sales people get no respect

Let's be honest, operations (engineering, QC, IT etc) tend to have a very dim view of their company's sales force. On the totem pole, they are about 6 feet below the HTML/CSS/Javascript developers.

Why is that? Is it their cars, golf clubs, or expense accounts? Or is it just because they are misunderstood? No one really understands their role in an organization.

I was out with our excellent sales team on Friday, and really, they aren't so bad. I was at a sales seminar (no jokes about falling down the totem); the speaker was fantastic, really funny, really insightful, and not very PC. I was talking to one fellow at the seminar (sales guys call this networking) and he expressed amazement that Macadamian was as big, and as successful as we were with only 3 sales people. Kudos indeed.

If you are not in sales, you likely don't really understand. Sure, we developers put in our long hours sometimes to bring a project back to green, but the sales force is putting in those long hours to get that sale in the first place.

The sales people works odd hours, sometimes they work late afternoons, sometimes they are working nights and/or weekends. Sometimes they are flying out at 6am to go see a customer. The difference is they are not in a dimly lit cubicle pecking away at a keyboard surrounded by empty Coke cans and Oreo crumbs on their shirt.

Sure, they are in the box at the Scotia Bank place or the golf course, but they aren't there to watch the game or make a birdie or even a bogey. They are not even really there to sell per se. They are they there to build a relationship with their customer.

The speaker at the seminar had a few nuggets of advice, the one that really relates to what a good sales person does is "Make a sale, make a commission, build a relationship, earn a fortune."

When it boils right down to it, this is one of the things a good sales person is trying to do when they go golfing, or go to the game with their customers. It is with this relationship with the customer that we can get new business, fix old business (relationships) that has gone bad, and work towards becoming that trusted partner that we all want to be.

And most importantly, without our friendly neighborhood sales people, we wouldn’t get paid!

What is the T.R.A.C.C?

"What is the T.R.A.C.C?", one of my co-workers asked, and realized I haven't explicitly mentioned what the T.R.A.C.C was. Well, no time like the present to rectify this.

T.R.A.C.C is a catchy acronym for the values here at Macadamian. These are values we try to live by. Everyone from the President, to the lowliest cubicle dweller in the dustiest part of the office. Every single employee and new hire are taught these. We are graded against these on our year end reviews. Needless to say, we take it very importantly.

Simply put, T.R.A.C.C stands for:

• Transparency
• Responsiveness
• Agility
• Constant improvement
• Collaboration

I have talked about transparency already, and in the coming days and weeks I hope to provide real world examples of applying these values in practice, even when the project goes red. I feel that it is in these times, when the project is red, the customer is agitated, and the team is demoralized that staying true to these values, and providing strong leadership to the team that you will be able to turn that project from red, to green.

Toot toot!

Tooting my own horn, my article on "Global Development vs The Agile Manifesto" was published on the Agile Journal. Yay me!

What motivates you?

This weekend I was out on the year end trip with the cadet corps that I work/volunteer with. For the year end trip we went out into the Ottawa Valley to Wilderness Tours to do some adventure training. The unit did mountain biking, rock wall climbing, and whitewater rafting.

Saturday was a real scorcher, very hot, and very humid. At the end of the mountain biking and rock wall climbing, we decided to let the cadets go for a quick swim to cool off. Cool off being the operative word. As the Ottawa river is quite brisk at this time of the year.

One particular cadet, whom doesn't really like to expand his boundaries was the only one who didn't jump in. He wanted to, but couldn't bring himself to go. He would run up to the edge of the dock and stop at the last possible second. This went on for nearly an hour.

The other cadets tried to encourage him to go, offering to jump with him, or help him to the floating raft etc. I tried to encourage him to go as well. I coaxed, and prodded, and encouraged for about half an hour. Then I remembered something about him. I remembered, he loves chocolate. Well, any junk food really.

I offered to buy him a chocolate bar if he would just take the plunge. He didn't bite at the offer right away, but it opened the floodgates so to speak. Within a couple of minutes of that offer, he made the leap. I was pretty happy that he overcame his fear.

This little story underscores a key leadership principle; know your team member. In this case, I knew he loved chocolate.

You need to know the person on your team as a person. You need to take it past the simple and obvious things like know their name, or the ability to pick them out of a crowd. You should learn a bit about their:

• family;
• their hobbies;
• their likes or dislikes;
• their qualifications;
• their career aspirations;
  
• and leadership ability.

Knowing this information allows you to make informed decisions about how your team member is performing, or what will motivate them to succeed.

Knowing that your team member has an elderly and sick parent can go along way to explain why someone that was previously an excellent employee has suddenly become unmotivated, grumpy, or is out of the office at odd times.

Conversely, knowing that someone wants to be a Project Manager allows you to guide them in their career progression, you can tailor their goals and training to accomplish this. This might also explain why they work longer hours then your average employee.

To be clear, this doesn't mean that you have to be their friend, but it doesn't hurt either.

The 3rd Party Bait and Switch Game

Macadamian is a service company. We bid on projects with one of several models. The two most common ones are "Time and Material" and "Fixed Bid". Fixed Bid projects often are high risk, the customer knows this, which is why they want a fixed bid. It allows them to fix their costs and content, if not necessarily their quality.

While we sometimes estimate the work in a Time and Materials engagement, it is obviously mandatory when we do a Fixed Bid. When I do estimation, I don't have 80 hours to do it in; I often have less then 8 hours spread over a week or even longer. Couple that with the fact that estimation feels more likes an art then a science and you can see how we get into trouble.

A good practice when doing estimation is to look for 3^rd party tools you can buy or license that will save time and effort (and hence money) during the project.

In one particular web application we researched what was supposed to be a top of the line product for charting and other UI widgets. The "marketing brochure" looked really good, it had all the features we were looking for, and the customer has used the desktop version of the controls for years to great effect. And we bought the support agreement! What could go wrong? Ha, famous last words.

It turned out that the 3^rd party control did in fact do everything almost it advertised, just not at the same time. The 3^rd party code was a complete and utter mess, and parameters, methods, and attributes for the widgets changed between the different versions, or were not supported in our version.

We ended up "creatively" working around a lot of the issues, but it added a lot of time and complexity to the project, and ended up making the code more fragile then it had to be.

The moral of this story is before you choose any 3^rd party tool to solve that problem, spend some time and use it. And I mean, really use it. Don't just run some of their canned sample code; spend at least a full day making a proof of concept on one of your most complex pages (or uses cases) to see if it will work as advertised. If it's a web tool kit, look at its source. Is the source clean, well commented, and designed? Review the developer documentation in some detail, and "Google" the developer groups to see what people are saying about it.

It's the least you can do when your entire development plan hinges on it.

Just make a decision

I am pretty big on leadership, and I stress the importance of it whenever I can. This isn’t to say that I am the perfect leader, far from it. I make mistakes, and through these mistakes I hope to improve.

I once told a young cadet that was facing some difficult leadership issues at the unit that the mark of a good leader isn’t in the mistakes you don’t make, but how you learn from the ones you do. It seemed really profound when I told this to the cadet at 3am one cold winter night, and in the light of day, it still seems pretty good.

At Macadamian, this concept of constant improvement is enshrined in our values; in fact it’s the last “C” in “TRACC”. It permeates everything that we do and every aspect of our company. Every new hire goes through training that discusses our values, and we discuss that as part of the employee review.

However, you can’t make mistakes if you never make a decision. A person who never makes a decision is pretty common affair, but they are not really a leader no matter what their business card says.

A leader must be confident, and make sound and timely decisions, you can of course rely on experts in your team for information, but in the end it’s YOUR decision to make.

In almost every case, it is better to make a decision when you have 70% of the information then to make the decision when you have 100%. You will never get 100% of the information, and if you make that decision at 70%, most of the time you will be right. Trying to wait until you get 100% of the information will lead to unnecessary delays, team stoppages and wasted effort.

So just make a decision.

Tasks aren't underwear, they shouldn't be changed daily

I was talking to one of my leads (I shall call him Percy) the other day and he mentioned he was having some troubles with his lead at the customer's site.

One of the challenges Percy is facing are constantly changing tasks. It seemed like everyday Percy and his team’s tasks were getting switched out from under them. This was done with the best of intentions; however we all know what the road to hell is paved with.

The environment that Percy and the team work in is very fast paced, and quite ad-hoc. Everyone is working really hard, and very often I will see emails from them at all hours of the night. Many of these emails directed at the global team. The tasks are switched in the name of efficiency; however it has quite the opposite effect.

There are quite a few hidden costs to this, such as:

- reduced individual morale;
- reduced espirit-de-corps
- wasted effort as team members context switch;
- confusion between who is supposed to work on what;
- wasted effort as multiple people do the same ramp up on the same task
- no sense of accomplishment
- etc

This is especially true in the context of a global team. The biggest drawback to this approach is that the team will begin to doubt the leader; they will lose faith in their leader’s ability to lead. The leader begins to look indecisive, unsure and hesitant.

Constantly changing tasks is never a good idea for the reasons mentioned above, but at least when it happens with local team members, it is easier to explain the rational and do the hand off. With global teams this is harder as the lines of communication are much longer.

In this case, the key to success is to set your objectives at the start of the week or milestone. Have the team take their assigned tasks and get started. If you keep your milestones short then at worst you may lose only a few days of development, but the team will still have their confidence. Weekly objectives are just that, weekly.

Give honest and sincere appreciation.

I have been reading the book “How to Win Friends & Influence People” for the past several days. In a previous post I talked about the first of three principles the author considers fundamental in dealing with people.

The second fundamental principle is dealing with people is to “Give honest and sincere appreciation”. Seems simple, doesn’t it? Well it may not be that simple. The key words in that principle are honest and sincere.

If it is not honest and sincere, the recipient will see through it like a cheap threadbare suit. You will not have the affect you wish, and you will have no credibility when you do mean it. A leader must be honest, and giving false appreciation (also known as flattery) will not get you anywhere. Sounds familiar doesn’t it? Honest appreciation will often get results where criticism fails.

Why does honest and sincere appreciation have such a profound impact on people? It is because people want to feel appreciated, they want to feel important. The author argues that this is one of the key human wants, right up there with food and shelter.

This is why a good leader rewards (praises) their team members when they do good work and thanks (appreciates) them for all their efforts in helping the team achieve their objectives.