Archive

Author Archive

Usability lessons learned : The real cost of bad usability.

March 1st, 2010 nicholas lemay posts profile No comments
Confoo 2010

Come join us @Confoo for a Scrum simulation using paper prototyping!

Let’s take a very simple example of a very commonly used software that most people use during their work day : the Web browser.

This serves a good example because a web browser is well known by most people and rather simple to use(or should be). For this example we’ll use Mozilla Firefox and the stats published on their website. For everything else we’ll make the estimates as conservative as can be while still remaining realistic.

According to it’s own website*, FireFox is currently being used by 270 million users. For the sake of keeping this example easy, we’ll make the very conservative estimate that only 10 percent of them use it for long period of times at work. That makes this a total of 27 million users. For these few heavy users, let’s pretend that this browser is very easy to use and that users only waste a grand total of a measly 30 seconds a day figuring out things they want to accomplish compared to if it were optimally designed for them. For the sake of this conservative estimate, let’s pretend the average income of these workers is only 10$ per hour and that they work 5 days a week and only do so for 45 weeks per year.

For our example, we will be using the following formulas

Total time wasted in a year in seconds(182,250,000,000) = time wasted per day per employee(30 seconds) * work day per week per employee(5 days) * weeks worked in a year per employee(45 weeks) * number of employees using FireFox(27,000,000)

Total Wasted time in hours(50,625,000) = Time wasted in seconds(182,250,000,000) / Number of seconds in an hour(3600)

Total cost in a year of wasted time due to bad ergonomics(500,625,000$) = Wasted time in hours(50,625,000) * Hourly rate of employees(10$)

This very conservative example should make it clear to anyone that a very small flaw in the ergonomics of a software that is heavily used by a large number of users can have an enormous productivity cost and produce large wastes of money for employers. A very large part of this waste could be prevented or at the very least diminished by the use of proper software ergonomics/usability practices. In following articles in this series, we will publish means and method to help through proper interface design.

*http://weblogs.mozillazine.org/asa/archives/2009/05/firefox_at_270.html

  • Share/Bookmark

Making my 360 evaluations worthwhile.

February 16th, 2010 nicholas lemay posts profile No comments

Recent blog posts made on the Pyxis blog clearly show that there is a lack of trust towards the true usefulness of 360 degree evaluations. A couple of months ago, I was about to prepare my first 360  evaluation that was geared towards evaluating my own work at Pyxis over the last 6 months. As I prepared to do so, I asked my caddy to guide me through this process. To make things easier to grasp, we simply wrote down the goals I was trying to accomplish with the evaluation and grouped the by theme to see how we should deal with them.

Once simplified, the goal of my evaluations came down to two main themes :

1- Get an evaluation of my performance in order for me to be able to deal my salary for the next year.
2- Get proper feedback in order to get better within the next year.

So far so so good right? A regular 360 should help me meet those goals right ? Right ? Wrong. Totally wrong. The two goals are exactly that, two different goals and should be tackled differently. The first goal is there to evaluate whether or not I have performed to the levels that were expected by my employer and whether or not I should be rewarded accordingly. How is a subjective evaluation based on generic questions gonna help me do so ? Let’s say my job for the past year had been to be a product owner of a software developed at Pyxis. Let’s say my goals were to bring it to market within the first 6 months, to break even with the development costs within the next 3 months and to make a profit for the last 3 months of the year.

What does me having 3/5 or 5/5 on being a team player, having verbal skills, technical skills or management in a questionnaire have to do with me meeting my objectives? How about nil, zero, nada, zilch ? What might actually matters for this point is whether or not I have met those goals. Unfortunately, for most employees,those goals are seldom set in advance and/or are very seldom very clear. Too often, we learn the expectations once we get to our evaluation. Much like we set the condition of success for the user stories we develop during the XP/Scrum planning game, we most definitely should set the expectations far in advance. Then and only then can somebody be evaluated fairly.

As far as number 2 goes, in order for me to get better I need proper feedback. That’s when a properly used 360 can be useful. But feedback on what actually? In my limited experience with 360 evaluations, more often than not, when someone is asked to rate a colleague on a question along the lines of  “Shows commitment to the project” they will come up with an example on when the person showed or lacked commitment to the project. Actually, they might of forgotten all about the project and might rate you on whether or not they like you as a person or not. Why not reverse the situation and come up with the examples and then ask the questions based on a particular event ?

Let’s say I worked with Marc on a project for 3 months. Within that time a lot has come and gone. Asking him a random question will render a random answer. But if I want specific feedback in order to get better on a particular subject, I can plan accordingly. If instead I’d ask him : “On that project, we didn’t meet our deadline for 3 consecutive sprints. Do you think I showed the proper commitment ? If not, how did you feel about it what what would you suggest I should change ?” This should trigger memories based on those event and more specific feedback on a more precise theme.

Like some suggested, the 360 feedback should be done face to face. You might not want to go all the way and do it in groups, but for the audacious it’s an interesting avenue.

Also, not having the two conflicting goals might help both goals being reached. Let’s say my annual raise is based on my 360. Why should I be inclined to ask the “questions that hurt” to somebody ? If I get negative feedback I might get scared of not getting my pay raise. Who would want that? On the other hand, if I use it only for a genuine goal of getting better, I have at least one reason less not to ask the real questions.

Also, by setting your goals far in advance, you will have less excuse not the meet them. Actually, you might ask for more frequent feedback from your peers, since you have a clear goal and getting better will help you meet your goal. You will get better, and both you as an individual and the enterprise you work for will flourish from that. How about that. A frequent inspect and adapt cycle. Wonder where I heard that one before.

I hope this small recollection of a conversation I had with my caddy can help you guys or keep this interesting conversation alive.

-Nicholas Lemay

  • Share/Bookmark
Categories: Uncategorized Tags:

Agile lessons learned #7 : Peek under the hood

February 2nd, 2010 nicholas lemay posts profile No comments
http://farm3.static.flickr.com/2165/2002396040_3c849704ba_m_d.jpg

http://farm3.static.flickr.com/2165/2002396040_3c849704ba_m_d.jpg

Mike came over to Dan’s house the other day. Mike had called him to give him a hand with a new secret project of his.
“What the hell is he up to” Olly thought to himself. Mike always had these crazy programming projects in mind.

“At least I might even learn a thing or two from the silly bastard” Mike whispered as he rang the bell to Mike’s house. He got no answer. Mike tried again and still no answer. He tried Dan’s cell phone and still no answer. Finally, as he left to go to his car he heard some loud music blasting from the garage.

“Well, I stand up next to a mountain. And I chop it down with the edge of my hand…” Mike recognized Jimmy Hendrix blasting through the old stereo.

“Dan !? DAAAAAAAN ! Are you there !?” Screamed Mike as he tried to be louder than the speakers.
“Yeah, I’m down here ”
“Man I’m turning down that radio or we’re both going deaf by the end of the hour.”
“What are you up to Dan ?”
“I’m disassembling my outboard”
“WHAT ? Why ?”
“It’s completely seized. Guess a piston is jammed. Gotta figure out why.”
“Oh, didn’t know you were so versed in the fine art of marine mechanics.”
“You’re making fun of me ?”
“Well no. But since you called me I though we were gonna discuss a new software project. Something built around that Jazzy new web framework you were talking about.”
“Django ? Nah man the only Django you’ll hear for the time being is on the radio.”
“Ok then, why are we here ? ”
“Aren’t you pleased that you are here and listening to Hendrix play the guitar ?”

“Actually right now all I hear now is both of us running our mouths. So what’s the deal Dan? ”
“Well actually, I called you up for a very important mecha..programming lesson.”
“Oh really. Which is ?”
“Well, you see most new programmers are afraid to dig up code.”
“It’s like they believe the code they did not write is some kind of not understandable piece of work written by mystical beings.”
“Well if you saw some of the code I’ve seen you’d know some code is so bad it’s like it came out pre-obfuscated…”
“That’s besides the point. The point I’m trying to make is this : How many times have you stopped in your track of understanding a library or piece of external code works because you were afraid to dig in ? ”
“Many times”
“How often do you see it at work ? ”
“All the time.”
“Do you think it slows down your progress”
“Definitely.”
“There you go, lessons learned my boy.”

“Now would you be so kind to roll up those sleeves of your and give me a hand removing the crank from this bad boy.”
“Ah man. I knew I shouldn’t have gotten myself into this.” grunted Mike as they lifted the crank.
“You see now Mike, a compression ring completely blew off one of the piston and got jammed in the cylinder.”
“You just saved me 400$ worth of mechanics right there.”

-Nicholas Lemay

  • Share/Bookmark

Ergonomy lessons learned : Ergonomy sells.

January 22nd, 2010 nicholas lemay posts profile No comments
Ergonomy lessons learned: Ergonomy sells.

Ergonomy lessons learned: Ergonomy sells.

This week, the Montreal auto show is being held at the Palais des congrès. For many people, it’s their first peek at many of the cars they will be shopping for during the year.

While listening to the people voicing their opinions while trying out the different cars, it it obvious to the outside eye that a car’s interior design, it’s “ergonomics” could very well be the deal breaker for many potential customer.

If you go to any car show you will be able to see a pattern similar to this one :

1- Subject opens the door and sit down.
2- Subject looks around, commenting on the color, space and general feel the car gives them.
3- Subject starts fiddling around with the controls the seat adjustment, and the ever popular cup holders and i-Pod plugs.
4- Subject gives the exterior another look and either

A- gives the exterior another look

B- Gives the trunk or backseat a look

C- Gives the specs and pricing sheet a look

A small percentage only will go to C. Actually a lot of people won’t even go through with the all steps.

From simply sitting in the car, getting in and out and getting an overall “feel” on the car’s interior design, a lot of people either walked away from the car or stayed to look
further at the car’s spec sheet containing the pricing, the security options, the fuel consumption, etc. Features on which you would expect most rational people to base
their decision to make a 15K$ + investment upon. Yet the cup holders, the I-Pod plugs and the positioning of the defrost buttons all came into play prior to all of these costly
car features.

People will not care how well something is built if it is not appealing to them first and easy to use. Car designers and software designers alike are victim of this reality.
They say you do not judge a book by it’s cover. In Montreal that day, there sure was a lot of people judging a car by it’s interior.

-Nicholas Lemay

  • Share/Bookmark
Categories: Ergonomie logicielle Tags:

Agile lessons learned #6 : It takes two to tango.

January 16th, 2010 nicholas lemay posts profile No comments
Agile lessons learned #6 : It takes two to tango

Agile lessons learned #6 : It takes two to tango

In early April 1999, FreeFall inc’s first major web project was canned. Andrew, the lead tech on this project was now without a project to work on.

Being the best and youngest programmer of his former team, he was quickly drafted by a small team working on embedded software. After the first week Andrew felt devastated. He was back to working with old technology with team members whose age averaged more than his own parents’. The last time most of these guys had followed any resemblance of a training course, Andrew was busy fighting teen acne.

Even worse, through the years these guys had developed their own technologies and terminology and were totally cut off the rest of the world. Andrew began feeling like Christopher Columbus might have had it easy with the culture shock compared to him.

Around that time, pro wrestling was the biggest thing on prime time TV. Andrew and his college buddies would gather on Monday nights to watch the “rasslin”.

“Man, that old dude is just becoming a parody of his former self.” Said Andrew
“What d’ya mean” said Mike
“Just look at him! He couldn’t wrestle his way out of a paper bag. He’s dragging all the young guys down. All of his matches have the crowd booing him out of the building as of late”
“Oh really ? “How about his up and coming opponent; are they any good or just a bunch of jobbers ? ”
“Oh man they’re great. They are doing this new fast-paced Japanese influenced style.”
“Oh ok. Couldn’t they just make him look good ? The whole thing is staged after all you know.”
“Look at them, they are booing both guys now. And they’re cutting the match short. ”

“One…..two….threeeeeeeeee it’s over” said the commentator with some despair in his voice.
“Finally it’s over. Out with the dinosaur. Man I wish I could get rid of the dinosaurs I’m working with within a three count.” Said Andrew.

Andrew went on explaining how terrible it was to work with guys that were so behind the curve and so slow.

“I wish I could help but this is pretty desperate. Management won’t unblock any budget for training courses or for coaching.”
“That’s sad. Ever tried doing some pair-programming with these guys?”
Pair programming? What’s that ? ”
“Well basically two programmer sit together in front of a single computer and program together. Each of them has a specific role. The pilot and copilot just like in a rally.
The pilot pretty much executes the coding, while the copilot takes notes of what the duo wants to accomplish, review what the pilot is doing and gives feedback on the work being done.
“At a frequent interval, each of them alternate the roles. This breaks monotony and keeps you refreshed. How often have you felt drained after a long session of programming ?”
“All the time.”
“Well this will help you out. Also, this process will protect you from yourself. Meaning that with continuous peer review, it it much harder for you to rationalize introducing weird bits of code into the software. Every time you do, someone else will be there to catch it.”
“As a matter of fact, after a while, most realize that the quality of their work starts going up. Way up.”
“Finally, working with a real human rather than working alone with a computer makes the whole programming process more human. You have to experience it for yourself, but you’d have a hard time going back to locking yourself away in a cubicle after a couple of weeks of pair programming.”

“That sounds great but how will that help me with my elderlies? I mean won’t they just slow me down? ”
“At first yes. Like anything else in life there will be a learning curve. But after a while all the discussion brought by the continuous exchanges will bring the other guys up to speed like you wouldn’t believe.”

“You know Andrew, it’s true what they say : it really does takes two to tango.”
“What do you mean.”
“Remember when we used to say that a particular wrestler was so good he could have a four-star match wrestling against a broomstick.”
“Yeah”
“What it means is that if you really are as good as you pretend to be, it’s your job to make other people better than they could ever be by themselves. Who knows, you might even learn a trick or two from the old dogs”

-Nicholas Lemay

  • Share/Bookmark

Agile lessons learned #5 : Waiting for a superman

December 22nd, 2009 nicholas lemay posts profile No comments

As far as he could remember Marc always dreamed of being a pilot. At age fifteen, while most of his friends were chasing girls, he was working 5 days a week to gather money for flying lessons. By age 18, he was already certified as a flight instructor. After a few years of service as a bush pilot in the northern most par of the country, he finally got a break working for a regional transporter. In April that year, his engine was due for it’s 3500 hour overhaul. Pat, the senior technician at Aviair Regional Airlines performed the overhaul, a routine job for him by then.

As the FAA later found out, Pat got pressure from management to do the overhauls faster than usual as they really needed to get those planes off the ground during the harsh financial times of the enterprise. This caused him to leave a pressure hose on that was requiring change but that would also have required ordering a new piece and further delays. Unfortunately for Marc, the part hose up mid-flight three weeks later while flying above mountains. He now had to decide whether he would crash in a farmer field or in a country road nearby. Marc made a quick decision and decided to head towards the fields.

He managed to pull off a text book belly landing in a field that was way rougher than anticipated. When the emergency crew got on the site of the crash they found Marc unconscious and half-disfigured. Had he been a lesser pilot, all 13 of his passengers would have died that day.

Later that year, Marc got decorated for his heroic actions, as he saluted his former coworkers in the assistance for a last time. He saw this as his farewell, the accident having impaired his eye sight beyond possible repair, leaving him unable to get medical clearance and thus revoking his pilot’s license.

As the news of his heroic act got around, Marc started to be asked to give speeches about it across the country. Marc was not seeking publicity although he appreciated all the warm feedback he got, he always politely turned the offers down.

One day, he got a call from Peter, a friend of his that was now a project manager at FreeFall inc. After the usual salutations, Peter got around asking Marc for a motivational speech. In his mind he thought, if people met Marc there was no way they would not be positively influenced by him.

“It might even bring out a hero or two out of my employees you know, the project really is in disarray.” Said Peter
“Well I don’t know much about software development actually.  But why do you need heroes ?”
“Well everything is wrong. I really need someone to take the lead and fix our major issues. We have quality issues like you wouldn’t believe.” Said Peter, with his voice getting more desperate.
“OK. Why do you need heroes? ”
“Because we have quality issues…I already told you that.”
“Ok so you wouldn’t need heroes if you had no quality issues right?”
“What do you mean?”
“Well the only reason I’m unfortunately perceived as a hero is that I managed to do my job properly when someone was forced to slack the quality of his work ”
“I was doing my job properly for years prior to my accident, but you never heard of me in the news did you?”
“Of course not but…”
“Now, if their was no quality problem, your staff would only have to do their job and everything would be business as usual right ?”
“Well yeah.”
“Anything you could do to help the quality of the software your guys are building right now ?”
“Well the guys were talking about getting more time to do more unit testing and automated builds the other day, maybe I should give these guys a talk.”
“Who knows, might save you from having to deal with super heroes. Grown men wearing tights usually don’t go over well in office meetings ”
“Point taken, thanks Marc.”

- Nicholas Lemay

  • Share/Bookmark

Agile lessons learned #4 : The red pill

December 16th, 2009 nicholas lemay posts profile No comments

A man’s life is primarly interesting when he has failed.
For it’s a sign that he tried to surpass himself.

– George Clemenceau

Tim was an Agile coach. One morning, he bumped into Andrew, a senior manager over at FreeFall inc, a fortune 500 company.

“Hey Tim! How about that Agile thing? Do you guys still have a daily Scrum in the morning?
“How’s that coming along?”
“I don’t know how to put this Andrew, but we don’t ‘do the Scrum thing’ in the morning.
Being Agile is way more than doing daily meetings.”
“Oh really? What else is there to be Agile?”
“You might wanna grab a doughnut with that coffee, I’ve got a few things to show you.”

Tim went on explaining the different aspects of scrum, the roles and the different ceremonies. But he knew the selling point to the manager was the continuous improvement brought by the frequent inspection and adaptation the team puts itself through.

You see, with Scrum all you problems will become apparent. Think of the problems as cream being poured into a coffee. If you just keep on pouring and stirring all the time everything stays in a confused mess. But if you take time to stop stirring your mess, the cream will rise to the top and you’ll get a clearer view of what’s going on.

To achieve this here are some important steps:

Courage:
You can call yourself Agile if you want to. For that matter, you can call a cat a dog if you want to. But you are not Agile without frequent introspection and a true and deep desire to be better tomorrow than you are today.

This all start with courage. Courage to admit that you can be wrong. Courage to tell someone else that he/she was wrong. Courage to truly listen when someone is criticizing you. Courage to take what is on the table and make yourself a better you. A better team starts with a better you.

Desire:

Why do you desire to become better today than you were yesterday? What is your source of motivation? Are you so disgusted by your current situation that you wish not to have to experience it in the future? Have you seen better and want to recreate it? Do you see change as a desirable thing? As a source of motivation?

Failure must be an option:
If you are now allowed to fail, you cannot become better. You must be allowed to fail in order to be able to freely admit your failure in order to get feedback to help yourself get better. You should never seek failure, but you should not fear it.

Awareness of consequences:

Once you start into this continuous self-introspection game you will be cursed. Cursed for life. You see, most people have exactly the same problems as you and might still go through for the rest of their life. But you WILL see them. Just like Neo in the Matrix can see the code of the Matrix, you will see the problems when people within the mess have no idea how deep they’re in.

So you have two choices. To quote Morpheus talking to Neo:

“You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes.”

So what’s it gonna be? The red pill or the blue pill? Because once you take the red pill, there is no turning back.

- Nicholas Lemay

  • Share/Bookmark

Agile lessons learned #3 : Adult day care

December 8th, 2009 nicholas lemay posts profile 1 comment

Henry had been working for FreeFall for the past 7 years. A bachelor in software engineering, he had first joined up for an internship as a software developer, or has he later learned, as a code monkey.
Along the way he and his friend Pete got promoted to managerial roles in the IT department.

Three years had gone by since he got promoted and Henry had become borderline depressive. He was just coming off a full month’s vacation with his wife.
As with most monday mornings, Henry was late. He dreaded mondays. He never came in on time. But he couldn’t have cared less. None of his employees did.
Neither did his superiors. Actually, it was expected for the higher ups to come in late. They called it working in the boss’ timezone.
As Henry dreadfully packed his frozen lunch into his reusable bag, he kissed his wife goodbye.

“What’s wrong honey ?” she said
“Nothing special honey, it’s Monday you know.”
“Don’t worry about it sweetheart, you’ll be be back in no time”
“Yeah”, he said with dispair in his voice. “Right after adult day care…”
“Adult day care?” she said “What do you mean ?”
“That’s a phrase the guys coined up at work.”
“You know, just like when we were young our parents would drop us to day care ” he asked
“Yeah…”
“Well our job is just like it. The difference is barely noticeable really…”
“You’re kidding me right” she said with a puzzled face
“I’m not joking around. When we were kids our parents would drop us there in the morning and pick us up in the afternoon. At work, we take the commune and it drops us there
in the morning and they pick us back up in the evening”
“Ok and ?”
“At day care, the lady would drop each of us in our own little parks with a bunch of toys so we wouldn’t bother each other”
He took a break to see if she was still following him.
“Well you see at work we each have our own little cubicles or closed offices and we have our computer to play with until our time is done and we can go back home”
She clearly had heard enough.
“Enough with your childish stories. You’re just trying to get late to work. The sooner you leave the house the sooner you’ll be done with it.”
“Off to work you go ” She said as she kissed him on the cheek.

That afternoon, Henry had a meeting with Tim, a former schoolmate who later became an agile coach after completing his major in human psychology.

Henry spent his entire morning Googling details about that Scrum thing and the Extreme Programming practice.

Henry figured, one of the major problems at work was based on communication problems. All his team members were dispatched throughout the office floor in small cubicles with sliding doors.

The entire place was so quiet you sometimes felt like screaming just to see if someone was still alive. Actually, some days you actually felt as if somebody had actually died.

By the end of the week, he couldn’t get his discussion with Tim out of his mind and he booked a dinner between the two on Friday. After a couple of beers, they concluded a deal where Tim would come in at
FreeFall for a couple of month and coach the Agile transition. The team got off to a slow start, but eventually they saw the value of what they were doing popping out of everywhere and they
were really sold on the entire thing.

Eventually, they even got carried away and Tim had to step in and show them how to take the time to learn everything at a proper pace

“Baby steps, baby. Baby steps, that’s the only way my boys ” Tim said. As Henry tried to conceal his laughter.
“What’s so funny ? ” asked Tim.
“Oh nothing.”
“No seriously?”
“Well I find it amusing that you’re telling the boys to take baby steps, while they’re in day care”
“Day care ? ”
“Well you know, we’ve got this running gag about FreeFall being a daycare center for adults and our cubicles play the role our parks did when we were young.”
“I get the picture.” said Tim slightly amused. “Wonder if those Ruby on Rails developers ever thought they were actually building adult rattles….” continued Tim.
“But seriously about them cubicles, can we talk about those in private.”

Tim took Henry to the coffee machine to have a little talk. Tim got Henry to talk about the communication problems the team was having prior to their Agile transition.
They also noted the ameliorations that had occurred.
“You see dude” Tim called Henry “We’ve just made a small dent into the damn that was blocking the communication in your team. Now there’s a little water trickling.” he said passionately.
“Now then, do you want to keep the damn or do you want to bust the damn wide open” said Tim as Henry’s eyes opened up widely.
“Alright let’s do this”.
“You’re giving me “carte blanche” Henry ? ”
“Yeah man.”
“Cool, get ready for a flood come Monday morning.”

On Monday, Henry came in earlier than usual but he still managed to get in last. Five minutes in and he was already purple in the face and storming towards Tim.
“Are you out of your bloody mind ?”
“Pardon me ?”
“You just tore our entire team’s cubicles and replaced them with folding tables ? Are you freakin nuts ? Some of my employees have lost their Window privileges
and are now sitting together with the interns. How am I supposed to justify this to my boss. The union guys will tear me a new …”
“Come on Henry. These are just silly cubicles. Give me a chance to prove that what I’m doing has value. I’ll meet up with the team after the daily scrum and I’ll commit myself to two things :”
“Which are ?”
“First : I’ll do my damnest to make this work for the next two weeks”
“Second : If the results don’t come and they don’t like it, they can have they old ways back and I’ll put my head on the log”
“Fine Tim, two weeks, max. I’m all for this scrum thing, but don’t you make a fool out of me.”
“Promise I won’t Henry”

The end of the two weeks coincided with the end of the sprint and thus the sprint review. At the retrospective, the team had an activity where each member could give out a symbolic flower to a team member
for an extraordinary performance. Some of the team members decided to give one to the ScrumMaster for taking out the cubicles, which most recognised was an impediment to the team’s success.

On the last Friday of the following sprint, the entire team decided to head out for lunch and beers at the local terasse. The sun was warm, the beer was cold, the staff was lovely and the discussions were great.
After a few suds they realized they had seriously busted their lunch time. They could not have cared less. The team spirit was great and they were ahead on schedule.

They came back to work laughing and on their way in you could hear some of the employees grunting because of the distraction.
“Who are those slackers coming back from lunch in the middle of the afternoon ?” asked some of their fellow employees.

They were starting to look like outcasts. Eventually the lunch and beer became a staple of this team and even as the team members came and went, the tradition seemed to hold on.

The following spring, Maurice, the senior member of the team and John the new inmate as they liked to call him decided to organize a fishing weekend for the entire team. Surprisingly, the entire team accepted the invitation.

When they left the office that day, the entire place went back to it’s dead silent state. Had he kept his manager office’s door open, you could of heard senior manager Pete cussing his current director.
Pete was besides himself. How could the director cut off his budgets like that ?
His team had been dysfunctional for as long as he could remember and now things were starting to get personal.

Pete thought he had the perfect plan. He had been working for the past few weeks on a secret team building activity.

All it took to fix his teams’s spirit he thought, was a 4 hour activity which his boss would not finance. Yeah right.

-Nicholas Lemay

  • Share/Bookmark
Categories: Agile, Développement logiciel Tags:

Agile lessons learned #2 : In Peter we trust(ed).

December 3rd, 2009 nicholas lemay posts profile No comments

Tim came over to Chris’ house the other morning. Chris is a professional fishing guide. He actually gets paid to do what men work all year round to get to do for a single week. They both packed their gear before the sun had even lifted.

By 5:30 they were hitting the water. The lake was so calm you could the see the the reflection of the mountains as clear as in a mirror while the morning fog lifted off the ground. As they arrived to their first spot, it looked as though the boat was cutting waves through a sea of mercury.

By 7h30 they both had caught their quotas and started chilling in the back of the boat looking for catfish.

“Man is that the life or what ?” – said Tim.
“You betcha!”
“Man can you believe I actually get payed to do this ?”
“Yeah, ain’t that a shame ?”
“So are you still the Master at your job?”
“If you mean, SCRUM master then yes, I still am.”
“Oh excuse me, oh master of scrum”
“So when are you getting promoted to being God ?” Chris laughed.

“Oh you mean just like Peter right ?”

Peter was their former boss when they both were working in a warehouse back in college. The guy had no manners, no formal education but a truckload of ambitions. He went from broom-boy to foreman on the night shift within his first year. Within five years, he was in charge of the entire shipping department.

Before he hit age thirty, he was in charge of the entire regional section of the now multinational enterprise. He used to have the following saying : “When I wake up, I tell God He can go back to sleep. I’m in charge now.”. He repeated this phrase so often that he started believing his own hype.

“Actually, I’m not in charge of anyone” said Tim.
“Really ? ”
“Actually, I don’t even have what you’d call a superior ? ”
“You’re serious?”
“Yeah. In scrum all you have are self-organizing teams where each members has a crucial role in the entire process.”
“Actually, baring similar talent, experience and other qualities, not a single one member is more important than the other one. ”
“Wow, if Peter heard of this idea he you blow a gasket!”
“Damn straight.”

Tim went on explaining the finer advantages of self-organizing teams :

-> Members are more committed to the success of the project since they were all deeply involved in the decisions process. Feeling they have a certain amount of control of the projects destiny they gradually get more and more deeply involved and connected to the project.

-> No hierarchy means the people accountable for the success of the project are the ones working on it. This removes the pressure sent on the teams superior who’s usually the person that’s accountable for the teams success, yet is the person who has the less influence on the actual day-to-day work being done.

-> Self-organizing teams lets creative mind break loose, whereas in teams where the job in imposed, the creative people in a team are stuck waiting for their boss to tell them how to do things instead of letting the ideas emerge from the most imaginative people of the group, whoever that may be.

-> In a traditional team, communication is centered around the superior. He/she is the communication bottleneck of the entire team.

He also went on explaining how scrum as a process is so well suited for self-organizing teams:

-> Frequent inspections means the members skill progress more rapidly and by doing so the members build more confidence in themselves and do so at a much faster rate.

-> Frequent releases means rapid adjustments. Teams do experience failures. But they are short lived and since they come from a short time investment, do not take as long to recover from.

-> The roles are well defined and the development team is at center stage.

-> Communication is encouraged through daily stand up meetings, sprint reviews, demos and retrospectives. Also, working in open space areas and pairing is heavily promoted from many scrum practitioners through XP engineering methods.

“Wow that looks great said Chris. Too bad I never experienced self-organized teams when I was working … I mean when I had a real j…You know what I mean.”
“You think it would of made things different”
“Maybe. Wonder how a guy like Peter would fare in such an environment. That guy must have been promoted to King of the free world by now”
“Actually Peter got fired the other week”
“REALLY?!”
“Yeah saw his profile on LinkedIn. He was looking for a new job.”
“Wow. Must of stepped on too many toes.”
“Hehehe. Ever heard of the Peter principle?”
“Can’t say I have.”
“It came from a guy named DR Laurence J Peters. He wrote a whole book on the subject. It can actually be summed up to this: “In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence” meaning that in a hierarchy, the best member of a certain level is usually the one promoted to a superior level. Thus someone will keep on getting promoted until he his no longer good enough to be promoted any further. Thus reaching his own level of incompetence.
“Damn, Peter sure did have the right name.”
“Indeed he did, indeed he did” said Tim laughing

-Nicholas Lemay

  • Share/Bookmark
Categories: Agile, Scrum Tags: ,

Agile lessons learned #1 : Challenge everything.

November 25th, 2009 nicholas lemay posts profile 1 comment

Grown-ups never understand anything by themselves, and it is tiresome for children to be always and forever explaining things to them – Le petit prince by Antoine de Saint Exupéry

Jonathan was in a rut. Despite his best efforts on FreeFall’s brand new mega-project, nothing seemed to click. Everything just felt wrong. He could not quite put his finger on it, but he just knew something was going terribly wrong. Feeling powerless, everyday he got more and more anxious about the whole ordeal.

Once the project started to go haywire, FreeFall started to panic. Having a limited budget for outside ressources, despite losing millions on the project, they decided to hire Erol as a single Agile coach to do an assessment of the situation.

One day Jonathan and Erol met at the cafeteria where Erol had basically set up his office. Erol felt there was no better place to start conversations with people than the cafeteria. Things that people would never of said in official meetings, Erol was told in a matter of minutes. This jump-started his information collection like nothing else.

“I know you are here to help us” said Jonathan.
“I also feel that everything seems wrong but I can’t quite put my finger on it. Can you help me with that ?”
“If you’ve got five minutes, I’ve got a real story that might help you.”

Jonathan grabbed himself a coffee while Erol told him the following story:
“When I was young, I grew up in Haiti. I lived on the same street as all of my family. This was great when parties were thrown. We’d just get all together outside and party until the sun came up and then we’d party some more.”

“Christmas tradition was to cook a huge turkey based on the family recipe that came all the way from my great-grandmother.”

“The final step of the recipe was to chop a part of the turkey off before putting it in the oven”

“At six years old, my sister asked my mother why she was cutting off a part of the turkey. She said it was because her mother did it like that”

“So my sister asked my grandmother why she did it like that.”
“She said because your great-grand mother did it like that.”

“She then went on to see her great grand-mother”
“She asked her why she cut off a part of her turkey”
“She said, that she used to do it like that because her oven was too small to fit a turkey back then”

“You see, for generations, my family had been throwing away a part of their turkey for no good reason. If my sister did not challenge every member of my family until she found the root of the problem, we would of been throwing away turkey for generations to come even though the answer had lied next door for years.”

“Maybe I should start challenging what seems wrong” – said Jonathan
“Maybe you should Jon, maybe you should…”

-Nicholas Lemay

  • Share/Bookmark
Categories: Agile Tags: