Pyxis

This week, the first dry-run of the Professional Scrum Developer for Java course was given at Pyxis. For this occasion, 6 Pyxissians were on-site for 5 training days. Here is a sample of the many things we have learned.

One of the fundamental aspects that was covered was producing a proper “definition of done”(D.O.D).

For most of us, even with our extensive Scrum background, this was actually harder than we had originally expected. The training course consisted of 4 sprints spread over a 4 day period. At the end of each sprint, we had to demonstrate our accomplishments to the Product Owner.

At the end of the fourth sprint, we had to put our software into production.

Like most teams, we started out with a D.O.D that was too ambitious and wasn’t clear enough. For example :

• We had planned for 100% test coverage for all of our tests, yet it was impossible to demonstrate since we were unable to calculate code coverage for view tests. Even worse, there was simply no available tools to calculate our test coverage for these.
• We also had ambiguous elements, like following the code standard, without stating which one.

After achieving first sprint, we did what we thought were the proper modicifications to our done definition. As you can guess, we failed our second sprint. Our done definition was being seriously violated. We committed to too many tasks and did not take the time to truly understand all the work involved in achieving our done definition. We adjusted for the following sprints. Inspect and adapt as always.

However, when came the time to release the product, we realized that our done definition was seriously lacking. We had no confidence in being able to ship our product to the customer. The Product Owner was disappointed in learning this. We then had to modify our done definition to finally be able to deliver. Unfortunately, we had skipped some important steps in the previous sprints which accumulated up until the last day.

Here are few key points that were missing :

• Exploratory testing
• User Experience testing
• Proper production deployment procedure

This really helped us see how important it is to have a true definition of done and to follow it through sprint after aprint. After all, we had accumulated debts after only 4 days of sprinting. Imagine if we had been sprinting for weeks !

-Nicolas Henin and Nicholas Lemay

Vince came back home today only to be greeted by firetrucks and the local fire marshal. He was quickly relieved to learn that his brand new condo was not on fire. Unfortunately, for his neighbor Harry, the fire marshal was there expelling him from his own home until he got his mess together.

When Vince found Harry he was in a terrible state of mind. You see, 78 years old Harry had been collecting all the newspapers he could get his hands on ever since his wife had died at 52. 26 years of newspaper stacked up against the walls was too much and a suspicious neighbor made a phone call to the local fire department before Harry would turn his home into the biggest BBQ the city had ever seen. Harry had just lost his entire collection.

All this turmoil shook up Vince inside. When he came back to work Monday, he started thinking about all the mess that was accumulating in his own project.

He made the following list of all that was accumulating around him :
- The backlog had tons of duplicate bugs
- A ton of stories were planned for but not estimated
- The main domain classes of the application were starting to have more responsibilities than the companies C.E.O.
- Some of the controllers were getting bloated
- The code produced by the interns had not been peer reviewed for weeks
- The users documentation was dated by two revisions

….

Vince then went to see his Product Owner and told him about the issue. He was dumbfounded to learn this at first, but after a long discussion, he brought the team together, talked about what was most urgent and how much dealing with each issue would cost.

He then added the elements with the best return on the investment at the top of the backlog and chipped in where he could to help the team address these issues. Within a few months, the situation was very promising and the team was now bringing up issues all the time without the need for them to accumulate.

A year later, most of his fellow Product Owners and their teams were engulfed in crap that had accumulated sprint after sprint. Always planning to fix it later,they never ever did.

Meanwhile this team just glided through the problems at a steady pace and it seemed nothing could stop them in their tracks. For the team members, the project just felt like a train anybody would love to embark on. Their biggest pride, was that it was their own.

-Nicholas Lemay

One of the neat tricks of dynamic languages like Python, Ruby, Javascript or even PHP is that you can try any snippet of code in your own little sandbox before you actually use it. This is great for exploring APIs, for learning purposes or for small proofs of concepts.

Let’s take a very simple example. Let’s say you come from a .NET background and are very found of LINQ. You would like to know how this expression would translate in your dynamic language of choice. Here’s a way to do it.

LINQ expression

from name in names
where name.Length > 3
orderby name
select name.ToUpper()

Python

Assuming you are runing on a Unix machine simply type python in a terminal. Once in the interactive interpreter, you are free to do pretty much anything you want with the language. You can import any eggs you have installed and anything that is in your PYTHONPATH. You can even add paths to your PYTHONPATH on the fly if you want to. At the prompt you would simply type the commands you want until you get the desired result.

Here’s a way to translate the above expression in the interactive interpreter :
>>> names = [ "guy","jean","bob","serge","jacques","yvon"]
>>> sorted(name.upper() for name in names if len(name) >3)
['JACQUES', 'JEAN', 'SERGE', 'YVON']

Pretty concise expression wouldn’t you say? The last line is python outputting you the result of you query. Neat huh ?

RUBY

Ruby had it’s own interpreter. It’s called IRB. On most UNIX machines, you will need to install it, unlike python. It pretty much works the same way as the Python interactive interpreter.

You start it by calling IRB. Then you have access to pretty much anything you’d like just like in Python.

The console looks like this:

irb>names = [ "guy","jean","bob","serge","jacques","yvon"]
irb> names.select {|name| name.length() >3}.each{ |name| name.upcase}.sort
=> ["JACQUES", "JEAN", "SERGE", "YVON"]

IRB also kindly print out the results.

By the way, all the examples above are built into the language without the need of anything like LINQ.

Javascript/jQuery

As far as Javascript in concerned, the way to have some fun is to use the FireFox add-on called FireBug.

One there, simply go into the console section and any Javascript library that is available in the page you are currently viewing will be accessible. For this example, we playing with the jQuery library by going directly on the jQuery.com site. Isn’t that sweet. Wanna resolve the above LINQ query using FireBug as your sandbox ? After some fiddling here is the solution I came up with :

var names = [ "guy","jean","bob","serge","jacques","yvon"];
jQuery.grep(names, function(name){return name.length > 3})
.map(function(name,i){return name.toUpperCase()})
.sort()

FireBug kindly prints out the result of my execution as this :

["JACQUES", "JEAN", "SERGE", "YVON"]

PHP

How bout some PHP ? PHP comes with it’s own interpreter.  Simply type php -a in a console. It’s not as cool as Python’s or Ruby’s but it does a decent enough job. So how does this expression translate in PHP ? Well, it’s definitely more verbose, but at least you got to try it out in a sandbox first to minimize any surprises from the quirks in the language.

php > function toUpper($name){return strtoupper($name);}
php > function longerThanThree($name){return strlen($name)>3;}
php > $names = array(“guy”,”jean”,”bob”,”serge”,”jacques”,”yvon”);
php > $filteredNames = array_map(“toUpper”,array_filter($names,”longerThanThree”));
php > sort($filteredNames);
php > print_r($filteredNames);
Array
(
[0] => JACQUES
[1] => JEAN
[2] => SERGE
[3] => YVON
)

Conclusion

There you go. Mission accomplished. Had you done the exercise yourself, you just would of quickly learned how to write a snippet of code in 5 different languages !

I think this is all pretty neat. As an added bonus, besides the PHP example, all solutions are very elegant and were discovered using trial and error as a learning tool. Something that is unfortunately not available in non-dynamic languages.

-Nicholas Lemay

The need for a course for Scrum developers :

If you’ve been following my series of recent blog posts entitled Agile Lessons Learned you might of seen some repetitive patterns emerge, mostly about the need for proper engineering practices.  In my mind, engineering practices compose the first pillar underneath the success of any Agile teams. You could have the best Scrum process in the world, but if you do not have the technical skills to support the process, you’ll never have a productive software development team.

The name of the game here is working software.  If you’re not constantly delivering working software sprint after sprint and a good quantity of it I might add, you are doing something wrong. It all starts with clean code that works. Clean code makes maintenance easier. It makes the addition of new team members easier. It makes documenting the code almost a non-issue. Being confronted to quality software, new members are most likely to bring up the quality of their work up a notch than when presented with sloppy code. Quality triggers more quality. Sloppiness triggers more sloppiness.

Inadequate training sources

But how do you start right ? You could buy a few books here and there and spend a couple of months trying to grasp what you can. You go back and take a few semesters worth of evening courses. Your spouse and kids may not approve of that though. I also wish you luck finding teachers who teach software engineering practices like TDD. A quicker way might be to try and immerse yourself within an already Agile team that has  awesome engineering practices in place already. Your boss and spouse might not be too anxious about you leaving your job though. What’s left then ? Well up until now you were pretty much on your own.

Introducing the Scrum.org courses

Being part of Pyxis, I’m extremely proud to see that we’ve partnered with Scrum.org to give the Scrum Developer Classes starting June 7th to June 11th. The first edition will be given in .Net. During the 5 day course, developers of all levels will be totally immersed in a Scrum environment and coached through the whole process by our Agile engineering experts. During those 5 days, attendees will be presented the latest tools of the Microsoft ecosystem(Visual Studio 2010,  SQL Server , T-SQL, etc) and the latest in engineering best practices(TDD, Agile Database Development, Emerging Architecture, etc) .

They will also go through the cycles of real Scrum iterations, just like Scrum teams developing production software. They will even be coached about addressing team dysfunctions! It is my firm belief that this kind of exposition to the best practices is the best way to get the real feeling of what it is like to be an Agile developer. I also believe that this will be beneficial to the teammates of attendees who have been exposed  to the industry’s current best practices and latest tools. Finally, this course will lead attendees to get the  Scrum Professional Certification.

I can’t wait to follow these classes. Hope to see you there. It’ll be tons of fun.

Excited about becoming a certified Scrum professional ? Here are some details about these classes :

For a complete course description :

Description(English)

Here is the syllabus :

Scrum Developer .Net Syllabus

And an awesome introduction video :

Professional Scrum Developer Intro

-Nicholas Lemay

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -Robert A. Heinlein

Specialization is for insects. Image source: flickr.

Like most children, Tony had to pick a sport. Not being the athletic type he decided to pick up baseball just like most kids in the neighborhood. It was his one and only passion. He daydreamed about playing baseball in school and practice all winter while waiting for the next spring camp. When the local professional team moved away, most kids quit playing baseball and went back to either playing soccer or hockey.

Tony kept on playing for a season or two, then quit playing sports altogether having a hard time finding a league for players his age.

When it came to his professional life, Tony had the same attitude. When doing an internship in college, the quality bug bit him and he decided to become a full-fledged tester. Having secured a job in the country’s number one employer, he now saw it as a personal challenge to be the best tester on every team he ever dealt with. He most often was.

When projects started shifting to object oriented design, he started feeling a bit behind the curve. When the teams shifted to web design, he was really lost, but still kept helping the teams by finding bugs manually.

When the teams started switching to Agile, developers started taking quality more seriously and started writing their own tests. Tony felt terrible. Sure he was still finding bugs here and there, but the quality was really getting better and he felt more and more useless. He then had a talk with Maxim, the ScrumMaster who was leading the Agile initiative.

Maxim explained to him that instead of being threatened by change, he should embrace it. After all, he was the one championing for better quality all these year when nobody else cared. Now that everybody cared about it, maybe he could have a leadership role within this new team.

Tony decided to give it a try. He talked to the programmers about learning about testing and developing using those new web frameworks. After a couple of weeks of pair-programming, Tony was actually the one driving the developers about not skipping tests and doing rigid TDD.

Even more so, with his years of experience doing testing, he was always the one thinking about corner cases during the planning sessions and in his pair-programming sessions. Without him knowing, he was one his team’s biggest asset. Tony wasn’t just a one trick pony after all.

Nicholas Lemay

Tax season. What better way to welcome the wamer weather than filling out tax forms. Forget about the return of birds, the blossoming of trees, driving with the windows down or the reappearance of short skirts. Spring calls for serious work. To make matters worst, this year I could not manage to find out how much interest I payed on my student loans during the past year.

I wasn’t able to do it through my bank’s online service even though I remembered doing so  the previous years. I felt pretty bad about myself, considering I’m a supposed to be an IT specialist and all.

I called the customer support in shame only to be told that my information was indeed available online. I felt even worst. The very nice lady on the phone walked me through these very precise steps :

1- Go into my monthly statements
2- Select the account from which I pay my loans
3- Select the month of December
4- Go to the bottom of my statement

This is where my information was hiding all along ?!? How intuitive, right? You would have figured that one out, right ? You might wonder why someone would decide to hide this info this deep since it makes no sense at all right? Well it does in a certain way. If you look at the 4 steps above and translate them into an SQL query, it does look more natural. It would look something like this :

Select SUM(interests) from Account where date >= 2009 and date <=2010.

Makes more sense now ? This is what happens when software is developed backwards. When the back end drives the front end. Instead of having the natural user interactions dictate the way it should be implemented, we have the implementation dictating the interactions.

Take radios as another example. Just like one of my university teachers used to point out, most users could not care less about radio frequencies. Yet they had to learn about them in order to use a radio properly. Even though it was less natural to use as a result, it was more cost efficient to bind the user directly to the choice of frequency without an abstraction layer.

When designing interfaces, a good practice would be to always ask yourself : Who’s driving who ? Is the implementation driving the interaction or vice versa?

In other words, are you trying to fit the tool to the user or fit the user to the tool ?

For more on this subject, I would invite you to read this article

Nicholas Lemay

After a few months of Agile coaching things were starting to look brighter over at FreeFall inc. The Agile process was slowly but surely setting itself into place. Problem was, even though the team was pumping out an all out effort, their capacity to deliver was shameful. Tim had managed to convince FreeFall to hire Andrew, an Agile developer to give more technical coaching to the team.

“Man, I can’t believe this. The build machine is dying on me again !” Shouted Andrew
“Again!? What did you do ? ”
“I’m running the analyzer on our code. The code is so bad that ALL the code analyzers are dying on me”
“You’re running this on a 486 with floppies or what?” Asked Tim.
“If only I was. This machine is state of the art. Cost them a fortune. Man, it really looks like we have a serious case of skunk code here.” said Andrew

“Skunk code ? What’s that?” asked Tim
“Well you know some animals have defense mechanisms more evolved than others. The skunk for one, well, it just plain stinks. Most of it’s defense comes from just plain stinking so bad you won’t dare approach it.”

“I see. How does it relate to code ? ”
“Well you see, code usually starts with the best intentions. Then people introduce small flaws here and there.”
“Ever heard of the broken window principle ?”
“Can’t say I have.” said Tim perplex
“Well it’s a pretty simple theory. You break the window of a building and don’t fix it. For some reason, people who come next will notice it and take less care of the rest of the building. Within a year the place might actually start to fall apart.”

“Interesting, looks like what we have here. How does that relate to my skunk smelling code though ? ”
“Well you see, at some point the code base will contain so many code smells, people will be so repressed by it that nobody will dare touch it to fix it.”
“It thus becomes protected from ever being touched. Just like a skunk.”

“I see. What should we recommend to the client ?”
“Well for one they could stop adding more smells to this mess.”
“Any new code has very little reason to be messy.”
“How could they prevent that ?” – Asked Tim
“Behaviour Driven development or Test Driven Development properly applied should help a lot.”
“Take Cucumber, GreenPepper, xUnit, Rspec or whatever else you can think of and learn how to use it and why.”
“Pair programming should also be mandatory on most if not all coding activities. Try it out. Most people can’t go back to their old ways once they try it”
“Running the analyzers on the code can also give a hand, although it cannot replace the above two practices. Give a look at Sonar and the likes and find out what can help you or not.”

“That’s nice. How about the existing code ?”
“Well that’s gonna have to wait till I get my build machine running properly.”

Nicholas Lemay

Casey viator@Colorado Experiment - photo credit to oldtime strongman

”If you find a man in the desert who has been digging a hole with his bare hands for months and you show him a shovel, he will probably try to kill you with your own tool. If you dare come back later, he will still be digging the hole with his bare hands, even though he still has your shovel with him.” — Unknown

The muscle memory theory

In 1973, the Colorado experiment was conducted in order to test the effectiveness of brief and extremely intense exercise. The pictured subject, Casey Viator was  a de-trained bodybuilder coming off a year long layoff. The experiment lasted exactly 4 weeks. By the end of the 28th day, he had gained 63 pounds of muscle and lost over 17 pounds of fat. To the author’s knowledge, such results had never been produced prior to this experiment and have not been replicated since. The results have often been attributed to “muscle memory”.

The theory behind muscle memory is that the body always tries to maintain a certain balance. In order to grow, it has to be overloaded in order to give the body the signal it needs to adapt. Over a period of time, once the body grows accustomed to a certain level of muscle size/strength it then becomes the the new balance the body tries to maintain.

When someone is under stimulated, the body will regress somewhat rapidly until it falls back to it’s “balance level”. Once there,  it will try to hold on to the balance it was accustomed to. Eventually, since it is under stimulated, it can actually regress back to previous levels of size/strength since higher levels are no longer required. But with proper stimulation, it can grow back to the previous maximum levels in less time than it first took to reach those levels because of the so-called muscle memory.

When it comes to human behaviour, the same phenomenon is visible. Just like with with muscular balance, the body seems to try and maintain it’s comfort zone as some sort of defence mechanism. Once taken out of the comfort zone, it often triggers the reflex of going back to the old ways of doing things, no matter if it the previous behavior has a positive effect on the person or not.

An Agile transition as an example

When putting forth a transition in an enterprise such behavioral patterns must be understood and dealt with. Let’s take an Agile transition that takes employees who are used to a very hierarchical environment and are moving into self-organized teams as our example.

Applied to teams

For starters, let’s take a look at something as simple as task assignment. This shouldn’t be rocket surgery right ? Well, it depends on you standpoint.  Many people have become so accustomed to having tasks assigned to themselves they have a hard time dealing with the relatively simple responsibility of self task assignment. Actually, many people will look around for somebody to assign something to them or pretend they are committing to something while in fact they let everybody else decide and take what’s left.

Just dealing with the Product Owner on the appropriate scope of a sprint is something a lot of team members might find hard at first. Telling no to somebody who is asking you to do more stuff is not the usual behaviour most of us are accustomed to. Not convinced. Here are some examples. When we were young, we were expected to do what our parents asked us to do. In school, we were supposed to act the way the teacher asked and to do all our homework. At work, we are supposed to accomplish whatever work we are asked to do. See a behavioural pattern there ?

On the technical side, it is quite the challenge to ask developers with 20 years of experience who have never written a single test in their lives to do all their programming test-first. By TDD we don’t just mean writing test. What we mean is that while developing software, not a single line of code is written without a test written to test it first. None.

Funny thing is, once most people get the hang of TDD, they will have a hard time going back to your old ways. Unfortunately, you will often find programmers skipping tests altogether, even though they are at least aware of the benefits. In extreme dissonant cases, some will be sabotaging their own work on purpose for no apparent logical reason other than to maintain their previous ways of working.

Applied to managers

It also works the other way around. Having power over people is something that is seemingly very hard to let go of. In Agile teams, management is often seem as an umbrella protecting the team or as a coaches. Either way, they are helping the team attain it’s goal while supporting it when it needs to and protecting it from distractions. Other responsibilities might be helping team members get the proper training and also by keeping them on track regarding delivery objectives.

It requires a lot more soft skills to be a successful Agile manager than to simply be someone who’s main attribute is to dispatches work. It also involves the humbling task of letting go some of the grasp managers often have over every doing of their employees. It is only too common to hear about managers embracing Scrum, only to find them minutes later behaving exactly as they were before. This is done in spite of them being entirely aware that their previous behavior is unproductive and is what conducted the requirement for change in the first place.

Just like with weight training, it takes a long period of stimulus for the body to recognize the current state as the state the body needs to maintain. It is the same with change, the longer you keep at it, the more and more it will feel natural and it will just become the new habit. Remember, some things you think of as an habit now might have once looked to you as insane too.

-Nicholas Lemay

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

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