How to Evaluate a Good Fit for XP?

Posted by Vikas Hazrati on Jul 15, 2008

Sections

Process & Practices

Topics

Collaboration ,

Agile ,

Teamwork

Tags

Interpersonal Communication ,

Interviews ,

XP

Many Agilists believe that Agile is not for everyone. Some people do not fit well into the Agile philosophy and bring negative undercurrents to the functioning of the team. In an interesting thread on the Extreme Programming group, members discussed ways to evaluate if a person is a good fit for XP. The group discussed various factors on which the evaluation criteria should be focused.

Ken Boucher suggested that soft skills like, communication and ability to work with the team, are more important than the programming skills. According to him, programming skills can be taught but teaching soft skills takes longer and is difficult. Ken added that they do day long interviews which include pair programming sessions, white-board designing and having lunch together for evaluating both technical and soft skills.

On the other hand, Kevin Petteys debated that communication skills are subjective and the real evaluation of the person comes from technical skills. According to him, he had been on projects where there were well spoken people who knew nothing about programming.

David Peterson suggested that programming and communication go hand in hand. If a person cannot communicate clearly, there are less chances that he would be able to write clear code. Pat Maddox, suggested pair programming with the candidate as a way to evaluate both technical and communication skills. According to him, pairing reveals important facts like,

1. Can they learn patterns quickly after I teach them? (maybe they don't know red-green-refactor. That's okay. Can they do it for the second test we write though?)
2. How sharp are they algorithmically?
3. Do they recognize opportunities to refactor?
4. How do they communicate when thinking through a problem?

Some members on the group objected to pair programming, as an evaluation technique, citing reasons that the candidate might feel threatened or he might get the feeling that he is being subjected to a stressful situation. Other members debated that if a person feels threatened then may be he is not a good fit for XP.

The discussion then drifted towards the best way to evaluate a person technically. Most members agreed that writing code was one of the best ways. Kent Beck added, that writing code communicates a lot about the approach to work, however, it does not measure much about the character and interpersonal style. The group discussed and debated the type of coding assignment. Some members believed that canned problems like the FizzBuzz test might be handy whereas others thought that canned solutions do not reveal much about the capability of the individual to react to real world issues. They advocated real life production worthy problems. D.André Dhondt suggested a middle ground,

There are definitely pros and cons to pairing with a pre-canned sample vs real code. I wonder if I'd be happier with both. Let the person work independently for 45 minutes on a pre-canned sample, then pair with the person on a real story (but one that's carefully selected for fewer company-specific or industry-specific nuances).

D.André added that the main thing that he is looking at is communication, cadence and coach-ability. All this is easy to determine if there is enough collaboration happening, irrespective of pre-canned or real world scenario.

Craig Davidson tried to summarize the discussion with his thoughts. According to him, the most important thing to look for is enthusiasm and passion to work on an XP project. There should be a craving to learn. The person should care about the languages he knows and the problems he can solve.

In summary, most members on the group agreed that a good fit needs to have the right combination of technical and soft skills. There was a general consensus that pair programming with the potential candidate would be able to reveal these skills. Other factors that need attention are enthusiasm and eagerness to work as a part of XP team.

1. Back to top

   Vindicated!

   by Bruce Rennie

   
   Ha hah!
   

   
   A friend of mine and I have ongoing discussions about the relative merits of technical and "soft" skills. I'm in the soft skills corner. In my experience, developers have a thirst for learning when it comes to technical knowledge, I can count on them to cover that. On the other hand, soft skills are for "managers and other deadweight".
   

   
   And yet, when I've encountered failing or struggling projects, it's usually not the technical problems that are the problem...
   

   Reply

2. Back to top

   Re: Vindicated!

   by Kurt Christensen

   Agreed, wholeheartedly. The bitter truth is that most of these discussions take place in the context of software development for corporate IT, and guess what? In that environment, it's silly to talk about "technical skills" like we're sending rockets to Mars. Turns out writing database front-ends has been done before.
   
   So, if I'm forced to choose, I'm inclined to ditch those who lack the "soft skills", as they usually end up creating lots of hard problems.

   Reply

3. Back to top

   You've ignored the far more critical and vastly harder items like we all do

   by Damon Wilder Carr

   Not to be critical however. In fact we are not as technologists often prepared to do anything about this even when we can see it. Once you see it however nothing else can seem the same as you can get very fatalistic due to our inability to apply our big brains as we can with 'code' or 'architecture'. These are the hardest issues in organizational behavior. To be incredibly specific you might have read this, but to my world this is the fundamental precept by which all logic in agile is built. Fail to truly embody this, and all else crumbles like a bad proof in physics with an irrelevant error in currently used applications, that is disasterous and exponentially shown in later application

   
   
   

   We covered this in detail here:

   
   
   

   blog.domaindotnet.com/software-is-a-wicked-prob...

   
   
   

    ... we are now encountering problems of a different nature where the computer is no longer at the center of things the human is -- and the machine is now acting to provide or organize information the humans need to produce results. these are called "wicked problems", described by Horst Rittel and Melvin Webber (1)

   
   
   

   (1) 1973 "Dilemmas in a General Theory of Planning"
   pp 155-169, Policy Sciences , Vol. 4
   Elsevier Scientific Publishing Company, Inc.
   Amsterdam

   
   
   

   Compare this with:

   
   
   

   
   
   • Individuals and interactions over processes and tools
   
   
   
   • Working software over comprehensive documentation
   
   
   
   • Customer collaboration over contract negotiation
   
   
   
   • Responding to change over following a plan
   
   

   
   
   

    

   
   
   

   Utterly different and the amazing guys behind this really could not have attacked this and frankly I'm not sure why I do. It's the 'idiot tax' we all pay where in spite of forces like.. Uh.. the profit motive and invisible hand of markets? still dominates. And it's not us but the expectations of others we must serve.

   
   
   

   <em>There is really not a compelling market for 'technology for the sake of technology' I hear unfortunately.</em>

   
   
   

   Here's the problem: said another way:

   
   
   

   The realities of what the act of writing software IS and how it is best framed in terms of assumed constraints when getting ready to start really thinking about the real issue sounds nuts to us, but it is what needs to happen as the junk in people’s heads is not only wrong but incredibly damaging on us.

   
   
   

   How many will BELIEVE, SAY AND EMBODY things like 'we are on track! We're still learning about the problem at what perhaps is the 3/4 mark but who knows! In fact of course it is sub-optimizing for us to force any ‘get the release out’ as of course its about the value we can deliver. You tell us, not the opposite when to release and we should not core or change behavior if we happen to know you release a build!

   
   
   

   We should just ‘notice’ ah they put that build in prod. cool. Otherwise it’s not agile as you have two standards of behavior. In fact for a solid model just ask corporations to deliver 1.2 as well as say the Ubuntu project. They cannot for the most part because they love their work. I hear some do it for free! Hey Bob, you don;t need that 20 million next year as you can hire open source developers. They are the new outsourcing solution! Their free! But you can pay them enough for food..

   
   
   

   So you see here it’s all about the human models of though and sure if you are doing agile OF COURSE soft-skills are critical. In fact I was really taken at how your points listed are utter common sense if you think about it. How could these things still seem interesting?

   
   
   

   That’s not about you just the horrible neglecting of the 40,000 lb. guerilla in the room that we know we cannot do anything about anyway.

   
   
   

   <strong>People think software is like building a car that has started it's movement in a very deterministic way down its assembly line.</strong>

   
   
   

   It's not enough we know that is wrong if others with power believe the opposite and force us into unreasonable places that indeed hurt themselves. This is why a true character of a culture can often only be understood in panic. For example, I recall a project where things were going quite well.

   
   
   

   If interested there is a lot of content on this and much more from the highly technical Domain Specific mandate using C# 3.0 techniques to the abstract yet ‘no less’ (more) important issues like this. To my team and I ignoring either is akin to malpractice on our part,

   
   
   

   NOTE; We live transparency. Anyone who wants can get all our code, see our bugs, our failures, our occasional moments of competence.

   
   
   

   Damon Wilder Carr

   
   
   

   blog.domaindotnet.com/

   
   domain.dot.net team
   
   
   sponsored by agilefactor
   
   

   blog.domaindotnet.com/the-domaindotnet-philosop...

   Reply

• Older >