As within most organizations, the salary review process is an important one at Pyxis. The process is important for the employee-shareholders so they know there is a process, they understand it and deem it to be fair. It is also important for the organization as a whole to retain the talented employee-shareholders and provide a compensation that compares favorably to the market.

Most traditional organizations would agree that the process is very important but there is a distinction on how the process is handled within Pyxis. At most traditional organizations I worked for (and with), the salary review process is tied to the performance appraisal process and to the budget allocated by Human Resources. At the end of each year, the employee receives a performance rating which determines the percentage of salary increase – people receive an average increase for an average rating and an above-average increase for an above-average performance. The guidelines are clear and applied to everyone the same way. The salary review process takes place between an employee and his/her manager.

We like to do things differently. I have already described that Pyxis is organized in communities.

In a business context, communities are similar to functional departments with some fundamental distinctions. In traditional setting, members of a functional department or of a project team work together to achieve a goal. With some exceptions, team members share nothing but their common goal and a common boss. By comparison, in addition to sharing a common goal members within a community also share common values and culture and they operate within agreed upon self-defined norms. Analytical-Mind.

The employee-shareholders are offered a few options when it comes to their salary review:

• They can use the process put in place within their community (in this case, my only responsibility is to ensure fairness across communities).
• They can suggest an alternate approach that respects fairness (in this case, my only responsibility is to ensure the fairness of the proposed process).
• They can follow the approach recently used by Tremeur Balbous and Jean-François Proulx for their salary review.

The “Tremeur and Jean-François” approach

• The employee-shareholder must complete and document a self-evaluation (a 360-degree feedback similar to this one is often used). He must evaluate its contribution to Pyxis for the year ending and propose a new salary for the coming year.
• The employee-shareholder must then submit his self-evaluation to at least 3 other employee-shareholders with whom he worked during the year that ended in order to obtain their feedback and determine if the salary requested is appropriate and fair.
• If the employee-shareholders consulted do not belong to the same community as that to which the applicant belongs, the requester needs to validate his requested salary with at least 2 members of the community of belonging.
• Ideally, the community leader should be involved in the process since he is responsible for the financial framework of his community.
• At the end of this process, the applicant holds a meeting with me to discuss his findings and request salary.

Factors having a positive impact on salary determination

• Performance in his role;
• Contribution to the success of his community;
• Contribution to the success of Pyxis as a whole;
• Revenues generated directly;
• Income generated indirectly;
• A marked increase in responsibilities – in the case where an employee justifies a pay increase by the marked increase in his responsibilities, the excess (beyond the base increase) is considered an additional increase. The additional increase will be removed in the event the employee ceases to assume the responsibilities for which he had obtained a further increase.

Does your organization use a non-conventional salary review process?

You might be interested in these related posts:

1. Variable salary that fluctuates with the company’s performance
2. Helping employees grow without an HR department?
3. How would you feel if your colleagues knew your salary?

It took us a little longer than expected, but we are proud to be releasing version 2.4 of ProjectCards today.

Here are the key changes :

• Introduction of the Team Capacity Feature that will replace the current and non-intuitive Velocity feature
• Introduction of the Scrum Template
• Some visual and usability enhancements

To learn more about the new Team Capacity Feature and the other improvments, you can refer to this blog or the change log.

But above all, the best way to experience these new features is to try out ProjectCards 2.4 and to give us your precious feedback. We try to include customer suggestions in every releases !

Stay tuned for details ProjectCards 2.5 that will be released in the coming weeks.

-Nicholas Lemay

It’s been a tough but fulfilling week.  Did some coaching, facilitated a retrospective and gave a session on dirty backlogs.  But now the week is over and I finally get to go home and give a huge hug to my 11 year old resource!

You might have guessed, but I’m talking about daughter who I love more than anything!  But since she’s simply a resource, I can easily replace her with any 11 year old kid and it’ll work just fine.  I get home, Vanessa has been replaced by…Sara and I give her a big hug, ask her about her day, play a game or two and prepare dinner.  Since I know exactly what she likes and what she’s allergic to, it’ll be shrimp dumplings with peanut butter sauce.  Mine you, I’ve never met Sara before, but a resource is a resource – It’s all the same.  If I can easily replace my material resources, such as a printer, and expect the same results, why would it be any different with human resources? What so special about humans?

A small favour

To at least all you fellow ScrumMasters and Agile coaches out there, I’m asking you a tiny little favour: Please stop referring to individuals as resources.  Just like my daughter, individuals working in a team are not interchangeable.  Team members go through the classic evolution stages, learn to work together and strive to become highly efficient.  If you pluck someone out and replace them like you would a memory chip, it will negatively affect the team.

Using the term “resources” does nothing to discourage this all too common practice in many organizations.  Slowly help your organization to drop the term “resource” when referring to individuals and maybe, just maybe, it’ll change the way project teams are perceived – Not just as bunch interchangeable robots hacking away on a keyboard, but a group of motivated individuals who are determined to find that perfect synergy.  In the corner over there, you have a true team (not to say a family) that is sharing a common vision with common goals and the unwavering belief that together they can deliver higher business value all the while lowering cost.

Now go home and hug your family.  Hopefully, no one was replaced

War is too important a matter to be left to the military. – Georges Clemenceau

In between college and university, I spent a couple of years working for a major truck leasing company. I was mostly surrounded by passionate individuals who were specialized as diesel service technicians.

Most of the time, I heard nothing but compliments from the drivers who enjoyed the extra care these technicians took. They knew that it was this care that kept them out of the trouble on these long roads. They had a real trust relationship going on.

Once I entered the IT business however, I experienced something completely different. People cutting corner wasn’t even considered special. It’s actually pretty much the norm of the industry. Things seem to have gotten so out of control that you can seriously expect from day to day to be asked to botch your job in order to meet someone’s ludicrous demands. Why is that so ?

Is building quality software so unimportant ? The billions of dollars spent annually worldwide on developing software seem to say that at least a few people do need properly built software.

Is software so easy to build that anyone anywhere can tell you how to build it properly ? I seriously doubt that.

I see many people practicing mechanics, plumbing or electricity during the week-end. We could say these are activity most people can take up quite easily. Whereas I know much fewer people taking up programming as a pastime.

Funny things is, I have yet to meet someone who would readily tell a mechanics not to fasten his bolts properly because he is short on time. I have never see someone tell his plumber not to cut the water before plugging in the the new dishwasher even though the outcome might be quite amusing. I have sure as hell never seen anyone tell the electrician to leave the electricity on while he’s doing his job.

Then why is it that so many managers, clients and various project stakeholders feel the need to tell developers how to do their job ?

Georges Clemenceau was once quoted as saying that “War was too important a matter to be left to the military“. I think software is too important a matter to be left up to people who do not know a single thing about it. I truly hope the software community can take matter into their own hands and try to fix this situation.

That’s why I’m very pleased to see movements like the software craftsmanship movement and the Agile movement that try and improve the bond between the different stakeholders.

We are all in this together after all.

-Nicholas Lemay

Assisting teams and organizations adopt Scrum and Agile practices for many years, I have realized, sometimes the hard way that Agile is a culture change. If you are interested in exploring more the topic of cultures and their implications, there are many resources available. I suggest you have a look at Bill Schneider’s work. I also suggest this blog post from Michael Spayd.

I have found Schneider’s core culture model very useful to assess the culture in place in a group that wants to adopt Scrum and Agile. Depending on how much time you want to allow, you can do an intuitive assessment or have some people go through the questionnaire that you can find in the book The Reengineering Alternative. By having the questionnaire by multiple persons at various levels and with various roles in the organizations, you can develop a good understanding of the culture in place. With the assessment results in hand, you have a marvelous tool to drive conversations and start identifying the challenges of the transition to Scrum and Agile and where to focus efforts.

Adopting Agile will certainly bring significant challenges in creating a team/collaboration culture, solid incremental software engineering practices, value driven planning, etc. Therefore, the last thing you want is tooling to get in the way. I have found that people put too much focus on the tooling for managing their scrums and not enough focus on the core issues. My advice, especially in the early stages of a product or project, is to use the tools that will provide the highest level of collaboration and interactions. Those are collaborative sessions where you use flip-charts, post-its, whiteboards, etc. Until we have tools that support a very high level of interactions and allow teams to create story maps and other models collaboratively and efficiently, I think it is wise to stick with those simple tools in those product exploration and definition sessions.

For various reasons, a significant portions of the Scrum / Agile teams will want to use an electronic tool to do planning and tracking. Again, I think the best tools are the ones that do not get in the way of collaboration. As outlined in Scrum and Agile Built Into Microsoft Team Foundation Server I presented how we design Urban Turtle to blend much like a chameleon into the existing environment for organizations that are using Team Foundation Server. The Urban Turtle team is committed to enabling software teams to create kick-ass software fast and we are always striving to make the user experience seamless and simple. Give Urban Turtle a try and please let us know what you think we need to improve in Urban Turtle or what you think we completely got wrong. Please be candid. We have done a release per month (5) since the release of TFS 2010 and intend to continue sustaining this pace. Therefore, there is a high chance that if your suggestion is great, it will be included in the product soon.

I value a lot exchanging points of view and experiences. Please do not hesitate to comment here, or send me an email to setup a live conversation.

In a previous post, Sprints and Compelling Goals, I expressed my opinion on why I think commitment driven planning is much more powerful than capacity planning. In the next post I will present why I think compelling goals drive collaboration and creativity. Stay tuned!

Cheers,

~françois

With the Agile approach, we constantly try to implement self-organized teams. Many of us believe that autonomy leads to improved results whereas control may bring consistency.

« The opposite of autonomy is control. Control leads to compliance; autonomy leads to engagement » – Drive, by Daniel Pink

I asked myself, “Why do people need to control?” and came up with 2 reasons: lack of trust and ego. I feel it is important to understand where people come from in order to understand the environment in which we live and operate. As coaches, it’s also important to know why people behave in such a way so we can help them.

I recently talked about fears, which is closely related to the need to control.

The problem with novelty, however is that, for most people, novelty triggers the fear system of the brain. Fear is the second major impediment to thinking like an iconoclast [...] There are many types of fear, but the two that inhibit iconoclasting thinking are fear of uncertainty and fear of public ridicule (Iconoclast: A Neuroscientist Reveals How to Think Differently).

Lack of Trust

If we are in control of our environment, then we have a far better chance of survival. Our deep subconscious mind thus gives us strong biochemical prods when we face some kind of danger (Control)

Everything that the brain sees or hears or touches has multiple interpretations. The one that is ultimately chosen – the thing that is perceived – is simply the brain’s best guess at interpreting what flows into it [...] These guesses are heavily influenced by part experience (Iconoclast: A Neuroscientist Reveals How to Think Differently).

Ego

On the other hand, ego is a completely different beast. The motivation behind controlling to protect the ego is at least as challenging to address as the lack of trust. The reasons behind the need to control to protect the ego are:

• to avoid an un-pleasant situation – including being ridiculed
• the lack of humility
• to hide a personal motivation

Once again to be successful as change agents, it is our role to dig into the reasons behind the need to control. I’m not talking about psychology, I’m simply talking about root cause analysis of the situation in an attempt to properly address the symptoms.

Once we understand the source of the need, we are in a much better position to positively impact people and successfully implement the transition.

The more radical and novel the change, the greater the liklihood of new insight being generated. To think like an iconoclast, you need novel experiences (Iconoclast: A Neuroscientist Reveals How to Think Differently).