janvier 2011Monthly :

Note to self:

To delete a user in Windows 7, don’t use the UI (the postgres installer complains that the user still exists). Instead run the following command:

NET USER postgres /DELETE

I just finished reading Great Business Teams: Cracking the Code for Standout Performance.

In Great Business Teams, renowned business consultant Howard M. Guttman takes you inside some of the world’s most successful corporations—Johnson & Johnson, Novartis, Mars Incorporated, and L’Oréal, to name a few—to discover how a powerful new high-performance horizontal model has changed the way leaders lead, team members function, challenges are met, and decisions are made. He also reveals how and why the organizations that have implemented this innovative team structure have become great companies, able to ride the crosscurrents during lean times and truly soar when opportunities arise.

As Agile team coaches or organizational coaches, we aim to increase the teams’ performance in an attempt to deliver better results. We improve quality, help the team work more efficiently, and have fun while delivering increased business value. Interestingly, many of the observations presented in Great Business Teams: Cracking the Code for Standout Performance are in line with the Agile values and principles. Here are some of the keys points to remember:

1. Great Business Teams are Led by High-Performance Leaders who:

• Create a “burning platform” for fundamental change;
• Are visionaries and architects;
• Know they cannot do it alone;
• Build authentic relationships;
• Model the behaviors they expect from their team;
• Redefine the fundamentals of leadership.

Isn’t this what we would expect of the Product Owner in Scrum?

Interestingly, the author positions the process by wish the leader achieves these objectives by asking tough questions such as:

• What is the business strategy and how committed are we to achieving it?
• What key operational goals flow from the strategy and how do we make sure these goals drive day-to-day decision making?
• Are we clear on roles and accountabilities?
• What protocols or ground rules will we play by as a team?
• Will our business relationships and interdependencies be built on candor and transparency?

Hence, the support of an external coach is useful and can help the leader ask powerful questions.

2. Members of Great Business Teams are Us-Directed Leaders

Members of great business teams think of themselves as accountable not only for their own performance but for that of their colleagues. Similar to the concept of self-organized teams, great business teams typically take accountability to achieve their objectives.

On high-performing teams, accountability goes well beyond the individuals recognition that he or she is part of the problem. It even goes beyond holding peers on a team accountable for performance. “Us” accountability includes holding the team leader accountable as well.

3. Great Business Teams Play by Protocols

Once a leader with the right skills is in place and supported by a self-organized team, the group needs to agree on the rules they will play by. Obviously, the more structured its way of working together, the less likelihood of misunderstanding, conflict or costly delays and bottlenecks the team will encounter.

One important set of protocols related to decision making.

Straight-up rules such as “no triangulations or enlistment of third party”, “resolve it or let it go”, “don’t accuse in absentia”, and “no hand from the grave or second guessing decisions” can eliminate much of the unresolved conflict that paralyzes teams and keeps them from moving to a higher level of performance.

4. Great Business Continually Raise The Performance Bar

No matter how much it achieves, great business teams are never satisfied, they implement self-monitoring, self-evaluation, continuous improvement, and raise the bar. The continuous improvement process helps a highly performing team to keep improving its performance and deliver impressive results.

5. Great Business Teams Have A Supportive Performance Management System

Having the right individuals in the right roles and establishing clear rules of engagement are not sufficient. The performance monitoring systems have to be inline with the expected behaviors.

• Team and individual goals have to be crystal clear;
• The necessary technical and interpersonal skills have to be provided;
• Performance has to be monitored;
• And feedback has to be timely an well thought out.

The book wasn’t written for an Agile audience but after reading it, it seems to me that applying the Agile principles would come close to cracking the code for standout performance.

Where ever we read about self-organized teams, it often seems to be a binary thing – either the team is self-organized or it isn’t.

When people suggest that the team should become self-organized, the suggested process is presented as fairly easy and straight forward.

If you are amongst the people who believe these previous two statements, I am sorry to be the bearer of bad news. In exchange, I will offer you a free reality check. Team self-organization is neither binary nor straight forward – self-organization is an evolutionary process that takes time.

We have been helping customers implement self-organizations for years and we have been pushing the limits within our organization. Based on that experience, I am sharing 7 levels of self-organized teams.

1. No opinion: Team members follow the direction of their manager. Not to be confused with Zombies or Living-Deads, these individuals are neither happy nor upset about being directed in their tasks – things are the way they are, period. These team members do not pay much attention to the organizational structure or who the actual leader is. They are strictly interested in “doing their job”. Although they may express an opinion with regards to the current structure, they don’t necessarily believe that self-organization is a better alternative. If you are moving towards self-organization, you shouldn’t spend much time convincing these people since they will gladly follow the official structure.
2. Status quo: Team members have benefited from the current structure in the past and wish to preserve it. They are un-likely to want to change to any other team structure (including self-organization) until they clearly see the benefits of transitioning. To move towards self-organization, you will need to spend time demonstrating what the new structure will bring them specifically and gaining their trust so they are willing to experiment with what you are proposing.
3. Selfish and irresponsible: Team members are happy to take advantage of being self-organized but only as long as it benefits them and that there are no increased responsibilities. Once a situation negatively impacts them (while benefiting the team), they aren’t willing to cooperate and when they are asked to take accountability for something, they shy away from the responsibility. In a nutshell, these individuals want the best of both worlds. To successfully transition to self-organization, it is critical to explain that they will need to make a decision and pick self-organization with responsibility or freedom outside the self-organized team.
4. Interested and learning: Team members are very interested in being self-organized but aren’t familiar with the changes required for them to become autonomous. They are ready and willing to learn and fully embrace the proposed structure. These are key people in a transformation, they are the ones who will pull the others forward as long as you take the time to explain what they need to do.
5. Self-organized: Team members are fully accountable and play by the rules of the team. They recognize their strengths and weaknesses and work on improving the organization of the team in order to become fully autonomous and self-supported. They deliver great results and need minimum involvement to remain in their current state. This is where you want your teams to be.
6. Leading a self-organized team: Although the team is self-organized, leadership is always required. These individuals will willingly take responsibility to organize the existing teams (they are team members and not managers) or the new teams you are hoping to transition to the new model. In a transition, you will want to work with these individuals to spread the new model and increase the number of self-organized teams.
7. Independent: Team members are too much self-organized. As a consequence, they no longer wish to be part of the organization and wish to go on their own. Although rare, in the event that self-organization transforms into full-autonomy, it may be necessary to break down the team and use some of the team members to help lead other self-organized teams.

The road to self-organization is long but very rewarding. Each organization needs to determine how far they are willing to push the model and how fast they wish to move.

You may also be interested in this post: I don’t believe in self-organized teams…

After many hours trying to find a complete solution to execute some Silverlight automated tests on a TFS 2010 build server without any success, I was forced to try to build my own solution. Thanks to my colleague Mathieu Szablowski, a Microsoft ALM expert here at Pyxis, we were able to craft a solution by combining StatLight (an open source tool used to run Silverlight tests) with a custom activity in Team Build 2010.

Configuring Silverlight test execution

With StatLight, it is possible to run automated tests from a Silverlight Test Project (created from the Silverlight Toolkit project template) and write the results to an XML file. The general principle here is to configure your build to run the Silverlight tests and have the build react if something is wrong.

The first step is to download and install both the Silverlight Toolkit and StatLight on your build server.

Once this is done, open Team Explorer on the build server and follow the steps below:

1. In the BuildProcessTemplate folder of your TFS project, make a copy of the DefaultTemplate.xaml template file.

2. Rename the copied template to a name like SilverlightDefaultTemplate.xaml and open it to edit the workflow.

3. Go to Process -> Sequence -> Run On Agent -> Try Compile, test, and … -> Sequence and add a sequence named Silverlight Test Run just after the “If a compilation exception” box.

4. From the toolbox, add an InvokeProcess TFS activity in the sequence. Open the properties and enter the following name: Invoke StatLight.

5. Still in the properties, enter the path of your StatLight installation on the build server in the FileName property. Example: “C:Program Files(x86)StatLightStatLight.exe.

6. In the “Silverlight Test Run” sequence box, create a TestResultFile variable that will be used to indicate where to write and read the XML report file generated by StatLight. You can assign the following value: BinariesDirectory + “TestResult.xml.

7. You must use the “-x” parameter to indicate to StatLight what Silverlight test file (.xap) to run and the “-r” parameter to specify where to write the test result report. In the arguments property of your “Invoke Statlight” activity, enter the following line: “-x=” “” + BinariesDirectory + “SilverlightTestProject.xap”"-r =” “” + TestResultFile.

8. To ensure that your build service will be able to interact with the StatLight program, you must configure your build service to run in interactive mode. Open the TFS administration console, select Build Configuration, click Properties on your BuildService and select Run build service as: Interactive Process.

Your Run Silverlight Test workflow box should almost look like this:

Note: To see your custom activities in the workflow (xaml template file) without any errors, you must open your XAML template file in a project that reference your custom activie’s dll.

Now you can run a build and verify that Silverlight tests were run by checking that the XML report has been posted at the location specified by the “-r” parameter in the argument properties of the “Invoke StatLight” activity.

Creating custom activities

Or you can run the code below to add a warning according to the desired behavior:

Here is an exemple of the result in Activity Log (detailed build information) with one failed test:

Until Microsoft provides a built-in alternative, this solution will enable our team nSemble to develop fully tested Silverlight applications using Agile engineering practices and continuous integration required to implement working software iteration after iteration.

Our organization is well known in Canada, France, and other French speaking countries around the world as a leader with the Agile approaches. We are one of the few organizations in North America with over 20 full-time agile coaches (employees).  For most part, our governance model relies on self-organization, the absence of hierarchy, and transparency in our decisions. This is what is well known from customers who have worked with Pyxis and potential employees who wish to join the organization, but what is much-less known is how Pyxis is a real-life laboratory for management, organizational behaviours, and team dynamics.

Most of the people who come in contact with people at Pyxis or who have worked with us will agree that the organization is different and throughout this year, I will share some of the inner working of our organization.

Pyxis helps software development companies to become places where results, quality of life, and fun coexist sustainably by being first and foremost an example of what it proposes to its clients and by coaching them.

We help our customers transition to Agile because we know it works – not because it is written in books but because we have been living the Agile way for 10 years now.

As the first post on the inner working of our Agile organization, I will explain the root cause of this difference. More posts will follow on self-organization, agile management, governance models, and growing a profitable organization by leveraging people’s inner motivation (remember autonomy, mastery and purpose?).

The fundamental reasons why Pyxis is different

After observing the organization from the inside for over two years, I have had the opportunity to appreciate that we are fortunate (and one of very few organizations) to have a real-life laboratory for human experiments – no, not the kind usually reserved to white rats. Our structure allows us to experiments with governance models (the way people are managed) and observe first hand the organizational behaviors that arise and the impact on team dynamics. We pride ourselves as being an incubator for highly performing teams and as such, we often experiment new concepts within our organization before trying them out on our clients – which is not often the case in consulting, but I digress…

The first reason behind our uniqueness is the philosophy of the founder. François sees the world differently from most people and although he has an opinion on many topics, his real contribution is that Pyxis is not a profit-maximizing organization. Like every organization, Pyxis wishes to generate a yearly profit but that is not the reason why Pyxis was originally created. Pyxis was born with a purpose to improve how software development is made and more importantly to improve the quality of life of people within those organizations.

This is critical to understand the organization because it leaves rooms for experiments (making mistakes is a critical part of learning), for employee satisfaction (people truly enjoy working at Pyxis), and deliver great results (highly motivated employees deliver better results).

There are other reasons why the organization is different but in my opinion, this one is fundamental.

This is a follow-up on my blog about Framework-free dependency injection in Ruby.

Alright. So you’ve heard of AOP and never tried it before in Ruby or Python. Or maybe you tried it in Java a few years back when it was the new buzz word using an exotic framework and quit before it ever got working.

Today, I’ll present a rather simple way of doing method interception or AOP using Python and Ruby.

Your application

Suppose you are in the following context:

• You are building a killer Twitter client.

• You are using a fictional MVC framework similar to Django* or Spring MVC. No Ruby on Rails** allowed

• Your controller methods need to return a response that the framework will process to produce the HTTP response.

• Your user needs to be logged in in order to access most of the functionalities of your Web app.

You are working on an existing App and are introducing the second method of your controller and it now looks like this :

class TweetsController:

def display_users_tweets(self, request):
user = request.user
if not user.is_logged_in:
return redirection_to(login_page)
user_tweets = Tweets.get_all_tweets_for_this(user)
return rendered_template(tweets_template, using=user_tweets)

def display_users_most_popular_tweets(self, request):
user = request.user
if not user.is_logged_in:
return redirection_to(login_page)
users_most_popular_tweets = Tweets.get_the_most_popular_tweets_for_this(user)
return rendered_template(most_popular_tweets_template, using=users_most_popular_tweets)

Alright. Not too bad. But in only two short methods we already have some code duplication.

Then you think to yourself : “I know, I’ll use my charming IDE and extract methods” and get the following result :

class TweetsController:
   def required_login_redirection(request):
       if not request.user.is_logged_in:
           return redirection_to(login_page)
return None

def __user_tweets_template_rendered_for_this(self, user):
user_tweets = Tweets.get_all_tweets_for_this(user)
return rendered_template(tweets_template, using=user_tweets)

def display_users_tweets(self, request):
user = request.user
return required_login_redirection_for(user) or self.__user_tweets_template_rendered_for_this(user)

def __most_popular_tweets_template_rendered_for_this(self, user):
users_most_popular_tweets = Tweets.get_the_most_popular_tweets_for_this(user)
return rendered_template(most_popular_tweets_template, using=users_most_popular_tweets)

def display_users_most_popular_tweets(self,request):
user = request.user
return required_login_redirection_for_this(user) or self.__most_popular_tweets_template_rendered_for_this(user)

This is much cleaner. We have encapsulated the redirection verification logic responsibility in a single method.

This work pretty well for our simple case. But what if we had more calls in the controller methods ? What would we do then ?

The issue with what we did is, we did not attack the problem from its root.

Requiring the user to be logged in is a precondition for executing this method.

Then, wouldn’t it be nice to be able to require the user to be logged in prior to a single line of code being executed in each of these methods ?

AOP and Python decorators to the rescue

This is one of the times when AOP, method interception, wrapper methods or decorators come in handy.

Remember the days when we had comments like these on top of our functions ?
/*******************************************
* Pre-condition : x most be a positive int
********************************************/

Wouldn’t it be nice if you could replace all of this dead text with executable code ?

With Python, you can do so by using decorators.

Your controller would then end up looking like this :

class TweetsController:
  @requires_user_to_be_logged_in
  def display_users_tweets(self, request):
      user_tweets = Tweets.get_all_tweets_for_this(user)
return rendered_template(tweets_template, using=user_tweets)

@requires_user_to_be_logged_in
def display_users_most_popular_tweets(self,request):
users_most_popular_tweets = Tweets.get_the_most_popular_tweets_for_this(user)
return rendered_template(most_popular_tweets_template, using=users_most_popular_tweets)

Wow. Me likes that ! If you’ve never written a decorator in Python here is a quick tutorial on how I wrote this decorator.

Python decorator example

def requires_user_to_be_logged_in(function):
    def requires_user_to_be_logged_in_wrapper(self,request, *args, **keyWordArgs):
      if request.user.is_logged_in:
          return function(self,request, *args, **keyWordArgs)
      return redirection_to(login_page)
    return requires_user_to_be_logged_in_wrapper

Some explanation :

• The first method requires_user_to_be_logged_in is the decorator itself.

• That method receives the function that it decorates as its sole parameter

• requires_user_to_be_logged_in_wrapper is an inner function that receives the parameter with whom the original method was called

• If you look at the return statements, you can see that we alter the return value of the original method only if the user is not logged in; otherwise, the original method is called exactly as if called without decoration since the precondition
  was respected

AOP and decorators in Ruby

Alright. Now that we have seen how cool implementing a decorator in Python is, let’s see how we could do this in Ruby.

class TweetsController

def display_tweets
puts “tweet tweet tweet”
end

def display_users_most_popular_tweets
display_tweets
end

display_users_most_popular_tweets = requires_login(:display_users_most_popular_tweets)

end

In the above example, we simply take the display_users_most_popular_tweets function, and reassign it to the original method decorated by the requires_login function.

How do we decorate the method ?

def requires_login(func_name)
  old_method = instance_method(func_name)
    define_method(func_name) do |*args|
      if user_is_logged_in
        old_method.bind(self).call(*args)
      else
        redirect_to_login_page
      end
    end
end

Just like in the Python example, we use an if statement to see whether or not not we need to do a redirection. If not, we call the original method using the same parameters it was originally called with. Otherwise we override the call completely and call the redirect_to_login_page method.

-Nicholas Lemay.

* Of course if you are using Django you already know about the very useful @login_required decorator.

** If you are using Rails, you could use the kick-ass before_filter in your controller and apply the requirement to be logged in to the proper controller methods.

As a leader, I believe it is important for people I work with to know my beliefs. As the leader of a self-organized company, I want to share those beliefs.

I personally believe that:

• people are good in nature and wish to accomplish meaningful goals;
• people truly wish to be successful and should be trusted to achieve success;
• collective intelligence leads to better decisions;
• individuals working together will find the solution to their problems, they know more about their skills, competences and environment than anyone else outside the team;
• long lasting knowledge is best learn through hands-on experience;
• as long as we learn something from the experience, failure is an investment, not an expense;
• true success is achieved when people are in it for the long run;
• a systemic perspective is useful to understand the entire system;
• short term goals are rarely optimal and tend to maximize locally and not globally;
• motivation comes from within, external factor do not really motivate people;
• motivated people deliver better results and are highly contagious;
• no single individual can (and should) be attributed success;
• success attracts successful people;
• you should judge people by their intention not their actions.

What are your beliefs?

This is a question I received from Etienne in part 2.

“But when there’s a problem with the behavior of a New Feature, how do you call that?”

It depends. When talking about a new feature, my guess is that you are talking about a feature that has yet to have been released.

In that case, even when using the bug type in a backlog, I would never raise a bug on a feature that has yet to have been released. The feature is not delivered, thus the bug is simply remaining work that has yet to have been addressed in order to be able to deliver the feature.

In that case, I would either add the details of the strange behavior in one of the existing tasks or create a new task to the story related to this behavior.

One strange thing that I have seen being done was team members raising a bug mid-sprint to be fixed later in the sprint or in another sprint(!) for a feature that got broke by the development of a new feature.

Why people would do this is beyond me. This is allowing the software to regress on purpose !

I would rather follow the Primum non nocere(first do no harm) maxim that is used in medicine.

Ideally, introducing a new feature should never make the software regress. At least not on purpose. Of course, there will always be times unwanted behavior is introduced without us knowing.

As always, having a fully automated test suite goes a long way in making it much easier for a team to discover the regression they are introducing as they go along and to make adjustments along the path.

I’ll be back soon with more feedback on how we are using our bug free backlog within team Sosoft.

Feel free to give us your feedback on our approach. Maybe we’re just a bunch of loonies after all

-Nicholas Lemay.

I finally finished writing this post that I started just after Halloween – not because it is long or complex but simply because other things were more of a priority. Anyhow, back in October and in the spirit of Halloween, we had decided to rent a Halloween movie that was somewhat kid-friendly. Our selection ended up being Shaun of the Dead, a 2004 movie. Don’t worry, I haven’t turned into a movie critics and I won’t pretend this movie ranks anywhere in my top 3,000 favorite movies – that’s not the point here – but the movie made me realize how many (most?) employees are zombies.

“What the heck are you talking about?”, you ask.

I’ll spare you the gory details but there’s a scene at the end of the movie were the zombies end up being captured and turned into normal workers. The scene is great as it portrays the zombies perform mindless (and numbing) tasks while people around them don’t seem to notice them or even mind them at all.

[You may also be interested to read what Derek has been publishing on the topic of zombies in the workplace]

To simplify things and explain the analogy I came up with after watching this silly movie, I will start by explaining that in my opinion people (employees) fit into one of three categories.

The LIVINGS

Although at first, we may believe that everyone fits into this category you may be surprised to find out that it isn’t so. LIVING people are those who take full responsibility of their life while they don’t necessarily travel the path the most followed. LIVINGS do a lot of introspection to make sure they are living the life they truly want and they aren’t afraid to step outside their comfort zone.

In organizations, the LIVINGS aren’t afraid to look for a better way to do things and challenge the status quo. They aren’t happy just mechanically doing their job and they look for challenges that will make them grow professionally. You can find LIVINGS at every levels of an organization.

Although not measured scientifically, I believe there is only 20% to 30% of the working population that are real LIVINGS.

The ZOMBIES

At the other end of the spectrum are the ZOMBIES. Contrary to the LIVINGS, the ZOMBIES are dead workers. They perform routine tasks without getting intellectually and/or emotionally involved. No matter how old they biological body actually is, the ZOMBIES are counting the days ’til retirement – or if retirement is more than 5 years away, they are counting the days until their next vacation, until next week-end, and sometimes the hours until the end of the day.

In industrial times, ZOMBIES were seen punching in and punching out of their day job. With the advent of modern technology and the disappearance of the punch clocks, ZOMBIES can pass their time updating their Facebook page, sending useless emails and performing tasks on their computer to keep their body active since their soul has died.

Although not measured scientifically, I believe there is between 20% to 30% of the working population that are dead ZOMBIES.

The LIVING-DEADS

Somewhere between the LIVINGS and the ZOMBIES is the majority of the working population. The LIVING-DEAD are very difficult to distinguish from the LIVINGS as they seem to perform their tasks with some interest. The main difference between the LIVINGS and the LIVING-DEAD is that the latter were once part of the LIVING population but at some point in their career, their brain has been captured by ZOMBIES – just like in the Shaun of the Dead movie, once a living is bitten by a zombie, there is a gradual decline toward becoming a full-fledged zombie.

Although not measured scientifically, I believe the majority of the working population (between 40% and 60%) are LIVING-DEAD.

Can ZOMBIES and LIVING-DEAD transform back into LIVINGS?

Contrary to the movie, the LIVING-DEAD and the ZOMBIES can come back to becoming LIVING individuals but the road back is difficult. The sad news is that most large organizations are based on rules, on controls and on structures that help breed ZOMBIES by converting LIVINGS into LIVING-DEAD. The good news is that there are ways out – I know, I used to be a ZOMBIE myself…

What category do you fit into?