I’m going to make a bit of a radical proposal here. I propose that we add the following to the Agile Manifesto:
We value interpersonal skills over technical knowledge
I’m not really proposing that we change the manifesto. I’m also not stating that technical knowledge is not extremely important. Remember that the Agile Manifesto states that we value the things on the left more than the right, but we still value the things on the right. I’m just making a point that I think a lot of organizations miss that affects their ability to really get the most out of Agile and Scrum.
Job postings for Scrum Masters, Product Owners, analysts and developers etc often have a long list of requirements for experience and knowledge in certain techniques, technologies, and industries. The initial interview, usually conducted with someone from HR, determines if you’re alive and whether what you claimed on your resume is real. The follow-up interviews with hiring managers often revolve around determining whether you actually have the skills and knowledge, sometimes even including aptitude and knowledge tests.
There’s nothing wrong with all of this. However, it needs to be balanced with the understanding that “hard” skills are only half the story. In an agile environment, where teams work together closely to propose and develop solutions and where they are expected to work with customers daily, the way an employee fits into the culture is almost as important as technical knowledge. A friend of mine described it like this:
I always tell my guys when they go interview a candidate “Remember that we are hiring the right person, not the best one. If he/she is the right person we will grow him/her to be the best, but it doesn’t work the other way around”
I think this might be a bit extreme, but it does make an important point. It’s usually easier to teach technical skills than interpersonal skills. A brilliant developer who doesn’t fit well with the team’s or organization’s culture can do more damage to a team’s productivity and creativity than good. A mediocre or less experienced developer who can bring out the best in others can add a lot more to a team than the sum of his parts.
If I had to choose between adding someone to my team with 10 years of experience as a full stack developer but who dominates conversations and doesn’t take criticism well, or a 4 year developer who asks good questions, proposes ideas, and shares responsibility, I’d go with the latter every time.
As organizations adopt agile practices the need for these “soft” skills, which are usually reserved for analysts and similar customer facing roles, is going to expand. A BA with strong interpersonal skills and weak or out-of-date technical knowledge may provide more value on a team than an experienced developer who doesn’t want to (or isn’t wanted to) work closely with customers.
The BA can learn the tools and techniques of the trade through paired programming and training while improving team productivity with his or her ability to get the information needed from customers quickly, efficiently and painlessly. You obviously can’t form a team comprised of 5-9 BAs with limited development experience, but I think it’s equally naive to try to put together a team that is entirely made up of experienced developers with unknown or unproven interpersonal, presentation and communication skills.