Hiring and firing in Scrum

I am exposing my ignorance here but I can’t find anything in Scrum that covers this, even Internet searches reveal very little so I don’t know if I am doing the right thing.

Scrum is about product delivery and so I am aware this is not in the scope of Scrum, but for it to work in practice we need to understand how it interfaces with business decisions. On many issues there is little or no conflict but on people management there seems to be a gulf and people for me are where product delivery starts and ends.

Most discussion seems to make the assumption that the team already exists and is highly motivated. But what if it isn’t, what if someone leaves? what if we need a new team?  What if a member of the team is not motivated or is downright destructive? How is that handled?

Hire a new team member

There are some situations that are easier than others. For example, the team is lacking an expertise or has insufficient people with a particular skill, or we simply need a replacement for someone that has left the team. We discuss it at a retrospective and the team conclusion is that a new team member would be a potential solution. I as Scrum Master can take that proposal to the programme manager (the business) and he will take the decision to hire (or not). The conversation likely includes the PO as it has budgetary implications.

But this is where it gets tricky, if they agree and a vacancy is posted, who sifts the applications? I’d want the team to have a say. There are a number of practical reasons it can’t be the whole team, typically there may be over 25 applicants for each role, that is a time consuming exercise, there is also an element of privacy to consider, so as Scrum Master I take it on myself, or the team chooses a delegation perhaps asking a few of the team for input, but hopefully as Scrum Master I am best placed to understand the requirements of the team as a whole.

Assuming I also filter with telephone screening, that is another time consuming task, is it okay to class it as an impediment that I resolve myself? And if so when I have a shortlist of just a few and want face to face interviews, again it can’t be the whole team so I ask the team to select a representative and typically the interview panel will be a Scrum Master the Product Owner and a team member. But if I am objective the Scrum Master has had significant influence in this decision, so does that undermine the sense of servant leader if I am effectively shaping the hiring decisions?

Also if that is considered an acceptable model, it is actually no different to when I was a department manager which immediately makes me stop and question whether the SM has too much authority in this scenario. That aside it feels right to me, it is pragmatic,the team gets influence but the time consuming aspects are shielded from the team. The only real danger is that the SM has a disproportionate influence on the process.

Build a new team

The second scenario is similar, the programme manager has more work or a new product and needs a new team. Best people to hire a Scrum team are likely a Scrum Master and Product Owner, possibly with input from a team member on an existing Scrum team. But this time there is no team to say what skills are needed, it becomes the judgement of the PO and SM. We are back to implied authority again.

I said at the start that I am on shaky ground, is this the right way? I haven’t seen recruiting, talent acquisition and interviewing as key skills for a Scrum Master or Product Owner, but in the last 18 months I have hired at least 15 people. I have bolstered one team and built up another team from nothing. Which as anyone used to recruitment will tell you is a significant time commitment. But whilst I don’t think of it as a Scrum Master responsibility, I can’t think of anyone else better placed and better suited.

Fire someone

But now I move on to a negative issue, let us consider a scenario where the team has a dysfunctional member, they are disruptive and by their behaviour they are holding the team back and coaching cannot solve it. It can be very difficult to get a team to deal with this in a self-organised way. So much time is spent team building, that pointing fingers at a member can be hard, especially if they are popular despite their behaviour. 

As a Scrum Master this is possibly one of the hardest issues to face, helping a team to see that improvement means hurting one of themselves is challenging to say the least, getting them to do so publicly in front of the party in question is almost impossible.  It can potentially be risky from an employment law point of view if the person feels this is done in a hostile manner. Managers are trained to focus on behaviour, and will normally be in possession of facts to support behaviour based criticism or discipline. Other team member may not be.

I see two ways to handle this the first is that the SM goes outside the team and reports his opinions and observations and has the person removed by a trained manager, chances are this is what the team wants but is unwilling to say so. But this in my opinion is wrong, it places the SM in a position of authority and the team have backed away from autonomy and independence. The right but harder way is to force the team to make the difficult decision and for the team to discuss openly and request changes. To essentially bench the disruptive influence. This may be raised as a retrospective discussion and a good SM should be able to focus the discussion where it needs to go, keeping it behaviour based and factual to avoid making it personal, sometimes retrospectives can be tough and even unpleasant but retrospection must be honest.

I didn’t say it would be easy!

Is this now management?

But in all this what I have proposed is moving the Scrum Master well in to the realm of management. Recruitment, discipline action, are yet another skill set to add to an already diverse role.

What I have described has worked, I’ve been there and done it, but just because it works, it doesn’t make it right and doesn’t mean it will work again.

Where in your opinion is the line drawn between Scrum and the hiring and firing decisions and how can we safeguard the SM from losing credibility by gaining authority?

How not to motivate

A friend suggested I watch this YouTube video on Motivation: Worst way to motivate

I thoroughly enjoyed this video and it is well worth watching.  The outcome flies in the face of some conventional logic but supports the view that we have come to know and love in Agile.

Spoiler Alert: for those that don’t watch the video, the premise is that The Federal Reserve bank in the USA commissioned a study in how to motivate staff and get better productivity, essentially how big  a bonus do you need to give to have an impact on productivity.

The study was carried out by scientists at MIT, Carnegie Melon and University of Chicago  and the outcome will surprise some of you.

Essentially what was classed as small or moderate incentive bonuses had no noticeable impact on productivity when applied to any task that wasn’t purely mechanical.  And large bonuses (equivalent to 3 months wages) caused a measurable decrease in productivity. Yes that is right, give someone a significant incentive when working on even mildly cognitive tasks and they got worse.

In other words incentives are bad, very bad.

The key to increasing productivity according to this study is in 3 areas:

  • Autonomy

  • Mastery

  • Purpose

More on that later…

Quick tangent…

My mind immediately jumped to the financial crisis. If the Federal Reserve believe that financial incentives have a negative effect, why are financial incentives the principle method used for rewarding bankers?   Does that mean that if bankers were paid an appropriate salary would they actually be better? Or is the conclusion that banking requires no cognitive input 🙂

It is not all about money.

It should be noted that for the study to reach the conclusion ‘salary’ had to be off the table, people need to be paid enough as a base salary for that not to be a motivating factor. This is easier said than done.

What I find interesting is that this study also supports old-school psychology too. Some of you may be familiar with Maslow’s hierarchy of needs.  Essentially once basic needs are met, security housing food etc. which have a direct correlation with income, things get more fuzzy, needs above essentials no longer have a direct monetary driver.  We get into Psychological needs: areas of personal relationships, social standing, and then on to our need for self-fulfillment, creativity, fun, personal achievement.  All of which have an element of financial impact but it is clearly it is not the primary driver. Once Basic needs have been met money becomes far less important to us.

Maslow's Triangle.pptx (2)

For example we don’t learn a musical instrument for financial benefit, or do a crossword, many of us have a hobby that takes huge amounts of effort, research, expense and often inconvenience and usually for nothing. Some participate in PTAs or Churches or social groups and clubs, or even write a blog. For most people money simply doesn’t drive us (Assuming we have enough to live), it is an enabler. So in theory if you have a reasonable base salary and you are content, then motivation needs to come from elsewhere.

Money cannot buy happiness, but being broke sure makes you miserable.

Aha, all looking good until…

A company in the USA read a similar study and concluded that if someone earned $70,000 they would have enough to be content, all essential needs would be met and so money would not be a factor and they could focus on productivity, so he raised the pay of all employees to $70,000.  Perfect! Only it wasn’t, humans are contrary soles and whilst the pay raise was great for some, we also measure our social standing by income, not because we care about income, but because it is a measurable metric of your value in society (or at least the workplace).  So when someone you felt was in a job that required less skill or less status than you was suddenly earning the same you felt disgruntled, your salary hasn’t changed, last week you were happy but today you feel you are relatively less important.  So it is about money and at the same time not at all about money.

Do you pay fair?

Paying fairly doesn’t mean pay them all the same.  Laszlo Bock from Google in his book Work Rules goes even further than this:- he says to deliberately pay unfairly, if you have a good employee pay them excessively, deliberately take money out of the equation.

My take from this is as follows:

Pay your staff well, pay them what they are worth as a base salary and review it regularly, but do not include any performance based incentives. And if you include profit share or Christmas bonuses, apply them equally (% based) and do not have them performance driven.

What you want is a secure workforce, you do not want them to be thinking they could earn more elsewhere, and you do not want high turnover of staff. Show your employees that you truly value them, pay above market rates to ensure stability, and be prepared to pay exceptional employees exceptionally.

So with a reasonable and appropriate salary (with no performance incentives) as our foundation, we can concentrate on the real issue of how to maximize productivity, and this is where it gets interesting…

more next time.

What makes a good interview?

My experience of recruitment is largely anecdotal, I am not a professional interviewer or HR expert. My limited experience of interviewing has been as a candidate, a hiring manager, or sometimes even as a subject expert. I’d estimate that over my career my experience is approximately 8:1 in favour of being an interviewer over being an interviewee, but I have been on both sides of the table often enough to know how it feels from either perspective. 

Over the last 5 or so years the amount of effort I have put into recruitment has been considerable, especially considering it is not really meant to be a significant part of my role. I’d estimate that I have hired an average of one person ever 2 months or so.   I even like to think I am pretty good at it,  although as you will see I am probably mistaken in that opinion.

What is striking though is how much time this takes, very anecdotally I’d estimate that depending on the quality of the CVs that I receive, on average only 5% will make it through the screening and interviewing to getting an offer(probably less). But the 95% that get rejected still consume a lot of time, and of the 5% selected we don’t always get it right, and I’m pretty sure quite a few good candidates get missed. The process is far from ideal.

recruitment

But what makes for a good interview?

As a candidate I have had interviews lasting less than 15 minutes (where I was offered) and interviews spanning 3 days, for a graduate recruitment programme, and just about everything in between. I have had good experiences and bad.

Some, in fact most interviewers seem to forget that the candidate is also interviewing them, and that the candidate is deciding if they want to work with you in the same way you are assessing them – it is not a one way decision by any stretch. Such is the lack of understanding and sheer arrogance of some that I have been asked extremely obscure technical questions that provide no clear value, I have been challenged(insulted) to gauge my response, I have had panel of interviewers quick-firing questions and had interviewers who were clearly reading my CV for the first time during the interview.  Why would any good candidate have any desire to work for you after an interview like that?

I haven’t kept accurate records, and I appreciate this is anecdotal but I’d estimate I have turned down close to three job offers for every one I have accepted over my career. Now I am well aware that I am fortunate to have in-demand skills at a time when the market is booming, I have also had a lot of rejection.  Similarly, as a hiring manager I’ve had too many candidates turn down offers, or more frustrating get a better offer before we could complete the hiring process.

The hiring process is so expensive and so important I am surprised at how often it is treated in a cavalier manner.   Why oh why would you be so arrogant to treat candidates with anything less than the respect you would expect them to show you?

To be the best, hire the best… for you.

I have recently been reflecting on the impact of our choices when hiring new staff. Over the last few years hiring has been a major activity for me, and so I am particularly interested in what the impact of these hiring decisions has on the team and the organisation.

I have a number of experiences that I feel are relevant and two particular opinions I have recently heard that I would like to discuss.

The first was from a blog post: http://zachholman.com/posts/0x-engineers/   in this the author is critical of everyone chasing after the type ‘A’ engineer, it makes an interesting read and refers to a popular belief that the good software engineers are worth 10x as much as the ‘average’ engineer.  I don’t intend to get into the basis or accuracy of the claims, but I am satisfied that it is a generally well accepted opinion that there is a significant difference in ability, and value of output between those deemed average and the top end of the scale, I have heard figures ranging from 10x as valuable to 1000x as valuable from quite well respected authors.

But ultimately the author compares software engineers to restaurants and concludes that most of the time he would be content with an average restaurant as we can’t always all eat in the best restaurants.  This is the point where I try hard not to be dismissive. The analogy is suggesting that most of us are content with ‘Good’ food and don’t need ‘Great food’ but the reality is that we are not only comparing quality, we are comparing relative quantity AND quantity, if we use his 10x value estimate then what we are comparing is a 1/10th of a ‘Good’ meal to a whole ‘Great meal’  We’d need to eat (and pay for) 10 ‘Good’ meals to get the same quantity/quality (value) of food.

He does have some good points about a good team being better than a star player and I’ll come back to that but I for one am not content with a tenth of a meal.

By contrast I looked at Work Rules! by Laszlo Bock (SVP People Operations at Google)

Lessons from WORK RULES! include:

* Take away managers’ power over employees
* Only hire people who are smarter than you are, no matter how long it takes to find them
* Pay unfairly (it’s more fair!)
* Default to open: be transparent, and welcome feedback
* If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

Laszlo advocates hiring only the best, by hiring the best you get the best output, you certainly have to pay more but you don’t have to pay 10x the salary to get a 10x software engineer, it makes financial and practical sense, a small team of high achievers must be amazing and they clearly are for Google. But…

Here is where the real word kicks in.  Most of us don’t work for Google or Apple, we will not attract the best of the best, most organisations are unable to employ an entire team of 10x engineers, many of us are lucky to hire a few high achievers, when location, salary, benefits, and image are factored in, we can be selective and choose the best of what is available to us, but a good engineer is hard to find.

So I am saying that I don’t want a team where the primary qualification is a pulse, and I am highly unlikely to be able to hire (and retain) an organisation full of 10x engineers.  My world is the grey area somewhere between.

This brings me to what has been an inevitable consequence of the real world – a mixed team.  I didn’t like the restaurant analogy so I will go with cars.

cars

Lets say I have a team of five developers, as a very general rule a team will travel at the pace of the slowest member, and whilst you may be able to improve the speed of the slowest a little, the high performers are stuck at the slowest speed and may well be getting bored and frustrated.  It is no good one or two members zooming-off, knowledge doesn’t get shared resentment grows and very quickly you are at a standstill with a dysfunctional team. An effective team moves at one pace – the pace of the team, and as the original blogger wrote, a team that works well together can actually be far more effective than a single star player.

And this is where things get more messy, as either a Scrum Master or a Department Manager the goal is the long-term development of the team, I value all the team and I’d like to see everyone have the opportunity to develop and get better, a single star-player held back is bad, I don’t want to see that, but equally I am aware that an effective team can be amazing, and then again a dysfunctional team is a disaster. I want to grow and build a team that are greater than the sum of their parts not a group of individuals moving at the pace of the slowest.

So I find myself both agreeing and disagreeing with Laszlo, yes I want a group of the best engineers, but that isn’t going to happen, I don’t live in silicon valley and I don’t have that budget, and even if I did then I’d still prefer a great team of engineers. I believe that a team working well together can achieve far more and far better software than even ’10x’ individuals.

I aim to get that by hiring for the team. I will still aim to hire a team where they are smarter than me if I can but my primary goal is to find someone good that will enhance the existing team, that means I value the ability to communicate over their technical depth, I value their willingness to learn and to question over their certainty of their own knowledge, I value a desire to give customers what they want over a desire for a perfectly engineered solution. I suppose I am saying I value the team over individuals – even star players.

But I have a dark side too, anyone that is holding the team back needs to go, whether they are disruptive or not pulling their weight or simply because they don’t mix well with the others. I think we should be aggressive in hiring the best people for the team but equally aggressive in removing obstacles whatever form they take even if it means changing the make-up of the team.

I don’t want to close before addressing the other items on Laszlo’s list.  I want to voice my agreement over the other points,

* Take away managers’ power over employees

It really makes no sense to hire smart people and then tell them what to do, we hire smart people because they know more than us in their area of expertise – Let them use it!

* Only hire people who are smarter than you are, no matter how long it takes to find them

I agree with the caveat mentioned above, we don’t all have that luxury and for the most part it depends heavily on the next point.

* Pay unfairly (it’s more fair!)

Double what you are willing to pay and be selective. But don’t stop there! Retention is as important as recruitment, don’t lose someone good by being stingy, if you discover you have hired a star, give them a pay raise immediately, I can guarantee that when they go it will be for only 5%-10% more than you currently pay – don’t let that happen and offering to ‘match’ after they have one foot out of the door is far far too late. Let them know you value them now and make it hard for a competitor to lure them away.  Don’t worry if it upsets other people, if they know that reward is based on ability and performance they will respect it even if they don’t like it.

* Default to open: be transparent, and welcome feedback

I am a huge believer in transparency in development, so many projects fail because problems were hidden ignored or deferred or where customers were excluded until it was too late and too costly to change. Be honest and open and learn to see that finding a problem early is a good thing, even if you’d prefer not to hear it.

 * If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

This goes with the first point but let the team lead the way, they likely do know best, and make work a place they want to be, if a team of engineers is happy and enthusiastic you will see an amazing improvement. And trust them.

Trust the team

I shall add that as my own piece of advice for success with software development.  Trust the team, trust their judgement, trust their opinions, trust their concerns and trust that they will do the right thing. In my experience a good team will reward that trust ten-fold.

In my opinion if you cannot Trust your development team it is a failure of management as you have hired the wrong people.