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?

Useful Scrum Metrics

Which do you use and Why?

I have already blogged about some common metrics but here are ten that I use or have used most frequently. It is my aim to summarise them here and expand each in greater detail over the next few weeks. (I will come back and add links as I do)

Warning!

Before we begin, the first piece of advice that can be said about metrics is that before you record data or use metrics you should really ask why you are recording the information and how it will be used.

If you cannot be sure that the metrics will be used for the benefit of the team then you shouldn’t record the metrics and certainly shouldn’t use them. If ever metrics are misused they become worthless as they are very easily gamed, especially if the team feel they will be abused.

Metrics are almost always reliant on honesty and there are not many metrics that couldn’t be ‘gamed’ if someone was motivated to do so. Never attribute reward or penalty for a metric or even multiple metrics. As soon as you do they are broken.

Have you ever heard tales of teams that were paid for number of lines of code written or for number of bugs fixed. I have worked at companies where the annual bonus was dependant on a high management approval rating in an annual employee survey.

Any environment where you are effectively penalised for honesty loses all hope of trust, transparency and integrity and your metrics become worthless.

If there is even the hint or suggestion that any of the metrics will be used for anything other than self-improvement and introspection again they immediately become worthless.

But that being said as a Coach measurements can be very useful. Measurements, metrics and reflection and retrospection are hugely valuable for coaching an individual or team on how to improve. An Agile Coach or Scrum Master has a variety of metrics available – and these 10 are by no means a comprehensive list, actually it is a very limited list, Each project or development environment is different and so tailoring appropriate metrics to your particular environment is important, not all metrics apply to all projects.

One last note is that there are myriad tools for tracking projects, some will measure these metrics but many won’t and it will be necessary to manually record the data. It will often be difficult to backdate if you haven’t been recording it.

In projects I work on I try to keep a lot of metrics just for myself, much more than the team uses. If at any point I feel there might be value in a metric I will bring it to the team and allow them to decide if it has value and if they are interested. But too much becomes confusing. As a rule of thumb they team only really have interest in a few of these, although which ones may vary over time. Keeping metrics without using them is also a good way of avoiding them responding to inspection.

Beware of context

I am also aware that metrics can be misleading if taken out of context. Information can be dangerous if misunderstood, if I choose to publish metrics in reports or in the office on a wall I will work hard to make sure the context is clear and if appropriate there is an explanation. But even then you can be sure that someone will misuse the information, so be prepared!

1 – The Burndown:

This is probably the most often used Scrum metric. In essence it measures work outstanding at the start of the sprint and a line is drawn converging on zero at the end of the sprint and each day the progress or burn-down is measured. The goal being to complete all planned(and emerging) work by the end of the sprint.

2 – The Velocity Chart:

The velocity chart can take many forms and can be used to track a number of key factors. In the most simplistic form it is a bar chart showing the number of points or sometimes the number of stories completed in the recent sprints.

3 – The Velocity Committed/Actual Chart:

Sometimes the velocity chart can be further enhanced to show committed points compared with actual points, this is useful when the team is not consistently delivering on commitments.

4 – Release Burndown

The principle is that for a given product we measure the Burndown of the entire product in a similar way to a Sprint Burndown, it may take the form of a cumulative flow diagram or be similar to a velocity chart.

5 – Cumulative Flow Diagram

A cumulative flow diagram tells all sorts of stories about a project, essentially it measures the number of stories in various states as the project progresses.

6 – The Burn-up

The Burn-up measures the actual effort expended in the sprint. In a perfect world it would be an exact inverse of the Burndown. But rarely do we predict all tasks in advance nor estimate the ones we know accurately. It can help see where time went and improve our estimates.

7 – Flow time, Lead Time, Cycle Time

There are some varieties in how these terms are used but I use a simplified version as follows:

Flow-time is the time from when a story is started to when it is completed by the team.
Lead-time is the time from when a story is added to the backlog to when it is completed into production – from conception to getting the value.
Cycle-time is the average time from when a story is started to the point where it is completed – we could be working on multiple stories at once, or overlap them. e.g. each story could have a flow time of 3 weeks but we could stagger them to deliver 1 per week.

Using averages for these allows us to measure whether we are improving over time.

8 – Health check survey

A health check survey is more touch-feely than the other more raw metrics but can be useful for gauging the team’s own opinion of their progress and behaviour. You can measure opinions on anything, from software practices to interactions with other teams, to quality of stories, anything the team has an opinion of can be measured.

9 – Predicted capacity : Actual Capacity

Each sprint during planning – stories can be broken into tasks, each of those tasks can be given a time estimate. When totaled up and the team has committed to the Sprint content, this total effort estimate is the ‘predicted capacity’ at the start of the sprint. This is the important number. Tasks will almost always be added as the sprint progresses and many of the task estimates will be off, but the initial predicted capacity is a measure of what the team is anticipating the workload will be for the sprint.

In theory the actual capacity of the sprint is simply the number of team members multiplied by the number of hours available in the sprint, excluding, planned holidays, planned meetings, predicted time on non-sprint activities.

Tracking these figures allows the team to gauge whether the capacity is realistic in relation to the previous sprint, the end result will be a (hopefully consistent) ratio.

10 – Scope creep

This can be covered by the cumulative flow diagram, and by the release burndown, but sometimes it is useful to explicitly report on what has been added or removed from the Scope each sprint.

The Chart is not the Voyage

Or more conventionally – The map is not the terrain.

This is an old quote attributed to Alfred Korzybski which is highly appropriate to my current client, as we make Charts of the oceans. They will be the first to agree that a chart is not the topography.

Charts can and frequently go out of date and so frequent updates of changes have to be notified to mariners promptly. In response to the Titanic disaster there was an international convention for the Safety of Life at Sea and now all larger ships are legally required to carry the latest charts and to keep them up to date in response to warnings. But even with an up to date chart no mariner would blindly assume it covered all hazards or was completely correct at any given point in time. Sands shift, sea beds may have objects that drift, some hazards may seem too small to note at some scales, some Hazards are temporary, etc.

The expression though is a warning to planners and navigators that the information they are using to plan is a simplified and likely an out-of-date illustration of the terrain. Navigational charts will often come with additional advice on approaching ports or other hazards but none can confidently claim to cover everything accurately.

Have you ever used a Sat Nav and found it taking you a convoluted and often much slower route because the pathfinding thinks a particular route looks shorter but is actually a narrow country lane that has limited passing places, I’m sure we’ve all see photos of trucks stuck in a narrow road as a result of following a map (or Sat Nav) without really understanding the terrain.

Planning

When planning a project you gather information to help you make the plan but here is the challenge of all planners:

If you try to cover every detail, every eventuality and every hazard it would likely take you as long as if you acted out the plan, probably longer as you would be mapping potential avenues that are never followed.
If you over simplify the plan you may omit key information and as in the case of the Sat Nav missing something crucial like a bridge being closed could throw the plan entirely. Making it difficult to stick to a plan.
If you plan from an illustration it is difficult to truly anticipate how long the actual journey will take.

Accurately planning for a team, large or small requires that you understand in detail both the journey and the team.

So how is it possible to get a team to successfully follow a detailed project plan?

Is it possible to successfully follow a detailed plan?

In a rather defeatist way, my answer is that it is not possible, or at least not consistently.

In waterfall projects, the normal solution is often to add huge amounts of contingency, if I think it is a 6 month project, call it 12 months etc. Have milestones to regroup and get back on track, but contingency when not needed is waste and in waterfall contingency is generally consumed. But contingency is in essence a form of planning based on an assumption that our plan is flawed – which it likely is, but this is hardly efficient.

We may also throw more staff at a plan or change scope or move dates the usual reactive crisis management that occurs when a Waterfall project is running late, but all of these are the result of a flawed plan, and in my experience the longer the plan duration the more inaccurate it becomes.

So if it is not possible to successfully plan a complex project why bother?

Essentially what I am saying is that Eisenhower hit the nail on the head when he said

“Plans are useless, But planning is indispensable”

Eisenhower

Planning is Indispensable

In Agile terms, my advice is to set a clear Vision, we absolutely must know where we want to go, and then simplify the plan into high-level objectives, and then prioritize them. Flesh out the detail of the highest priority item, and begin to explore more detail on the next highest priority and so on. Have a plan that has the minimal detail and expand it as you go and be prepared to adjust. Agile projects have the wonderful tendency to separate the wheat from the chaff and you will get a much leaner solution, lower priority features are deferred until later and often dropped altogether.

If we return to a voyage analogy if I were planning a voyage that involved multiple stops, I’d want to know the final destination and the major ports on the way perhaps an idea of key navigational way points, I would eventually want a detailed chart for each stage of my journey but I don’t need to study them yet (the charts may change or perhaps I will need to add a stop or skip one), the detail only matters when I reach that point. Right now all I need are detailed charts for the current stage, so long as I can plan that part of the journey I can proceed.

How long will the project take?

“But I’m a Project Manager and I need to know how long the project will take.”

If you have been nodding along with me as you read this you will be in agreement that the notion of accurately planning a complex project is a flawed concept, and that your previous attempts to predict project duration inevitably result in inflated estimates to cover contingency and you are not competitive. So the question becomes one of “do you really need to know how long this will take?” Or “why do you need to know how long it will take?”

Generally this falls into a number of categories:

1 Dependency:

If you are planning a launch date and it must coincide with another particular event then this may seem to be a reasonable request, but the question isn’t really one of how long the project will take, but one of how much can be completed by that date? Can it be delivered in phases? What is the MVP? How fixed is the date? Could it slip? Could it be deferred? What are the consequences if we are late?

The best advice would be to defer fixing the date as long as possible if content (MVP) is critical, or to ask yourself if you are willing to adjust scope, and or cost to meet the date? It is rare to find a project where 100% of the requested features are truly mandatory on a particular date and when that is the case it is unwise to have a fixed delivery date.

2 Return on investment

More often the usual reasons for wanting a plan are because of cost constraints or price/profit related issues, neither of which are helped by an inaccurate plan. What they mean is “How can I predict whether this project will be profitable?” or “I’d like an estimate for how much is this project going to cost me?”

Both of these are perfectly reasonable requests but neither require a date to be plucked from the air and written on the back of a contract for the soul of the Product Owner.

In all cases where Scope, Time or Cost are a limiting factor Agile planning and Agile delivery should mean that you get the highest Business Value items for the lowest cost, and that you will know at the earliest possible moment when there are issues that may impact on the success of the project. The aim is to deliver value at the earliest opportunity, in theory this is the most efficient and therefore most profitable/lowest cost solution for the given parameters. And if the project fails it will fail quickly for the lowest cost.

Agile doesn’t guarantee success or profitability, but when applied well it maximizes the value of successful projects, and perhaps more crucially in commercially driven projects it enables mitigation of failures at the earliest opportunity.

But you will have spotted that doesn’t answer the question: An estimate is a different matter entirely – see Estimates – Planning and estimation are frequently confused and they really shouldn’t be, but that is another topic.

3 Resource allocation

There may be other projects and you may want to predict when the team will become available, but assuming you are working on the highest priority project then your team is being utilized in the most appropriate way. Programme planning, like project planning is better done at a high level for the future and only becoming more specific as the task draws closer. If there is a dependency then see above, otherwise trust that the project/product will be completed as quickly as possible and the team can move on to the next task at the earliest opportunity.

Summary

There is nothing wrong with planning, planning is vitally important, the mistake is relying on a flawed plan, rigidly sticking to it in the face of reality.

Plan with the expectation that your plan will change.