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 Mythical Mature Team

On a regular basis I see comments in forums about how in a mature agile team a Scrum Master is not needed, or how the goal of a Scrum Master is to make themselves redundant.

On some level I agree with both comments, but the thing I am curious about is just what proportion of teams are actually mature?

My experience is anecdotal and is obviously reflective of where I have worked and who I have interacted with, but I have worked on Agile projects at 5 major companies, 3 of whom are top 100 companies and 2 major government departments, these are not obscure backstreet companies these are mainstream and in some cases pioneering tech companies. But if you measure Agile maturity on a scale of 1-5 the best would rate a 2/5. They are certainly improving, they are maturing and I am proud to have been part of that process, but they are all a long way from this fabled maturity.

So you might think that the rest of the industry is better and I have just been unlucky – or maybe I am hired because they need a coach to mature.  But again my experience disagrees with this, I do a lot of recruitment: in the last 12 months I have hired 14 developers/testers, and significant numbers at previous clients. I always ask about Scrum to get a feel for their experience and their attitude towards Agile delivery. I must have interviewed hundreds of candidates, and a significant number put that they are certified ScrumMasters on their CV.  But overwhelmingly those that claim to come from companies where they are ‘Agile’ or use ‘Scrum’ – demonstrate what I would describe as immature Agile adoption, sometimes just paying lip service to the concept.

So many, and I mean many! Seem to think that a daily Stand-up means they are Agile, I have had some describe how they are very Agile and follow Scrum closely but go on to describe how the plan is made in advance, a lead engineer estimates and the dev manager individually tasks on a daily basis and that testing occurs in the following Sprint to development and bugfixes are dealt with the sprint after.  I ask about retrospectives and I’d say that maybe 1 in 20 come from teams that hold any retrospectives and those that do describe quite varied experiences.

So for me that mature team remains a myth, something to aspire to.  However, I do notice that over time my role as a an Agile Coach changes drastically, early on a lot of time is spent embedding Scrum Processes, getting the team used to a different way of working, encouraging XP practices, building confidence in the team and showing the value of retrospectives and Agile delivery.  As the team evolves less time is spent on these, as a project progresses there are less impediments, but retrospectives become harder: the low hanging fruit has been dealt with and further improvements require greater insight and more skill to draw them out.  This is not a bad thing and gives time to start pushing out to the rest of the organisation, or taking on a second or third team.

So do you become redundant?  I don’t see it, there will always be some impediments and yes a mature team may learn to solve them by themselves but that is hardly the point, the goal is to allow the dev teams to concentrate on what brings value, and a Scrum Master can deal with many of these problems more efficiently and without distracting the frankly more valuable dev resource.

Also simply by their presence a Scrum Master acts as a counter balance to the Product Owner and the pressure to circumvent the framework.  There seems to be a notion that a mature team is a team of highly skilled software developers and testers that are also interested and eager to enforce Agile principles, and again this is something I don’t see, even the mature teams and experienced agile development teams are not enthusiastic about it in the same way a Scrum Master would be. They understand the value and the importance of Agile, they are wholeheartedly behind it, but that is quite different from the enthusiasm and drive a Scrum Master usually has.

If given the option of completing a task or attending a meeting, many developers would drop the scrum framework in a flash (“just this once”)  or extend a sprint to complete a story (“just this once”). It is also hard to see fault in yourself, and sometimes it takes an observer to reflect your behaviours back at you in a way to enable you to improve.

Metrics can be useful but they can take time and effort to produce effectively, and yes a developer or product owner could do it, but again this is something that a Scrum Master is likely better at and again the developers’ time is more valuable writing code.

Finally, new projects/product increments start and this creates a flurry of impediments, there will be turnover in the team and new staff will need to be hired and integrated into the team, a team may expand or another team needed and all of this runs far smoother with a Scrum Master. When you scale to having multiple teams working together the need for a Scrum Master becomes even greater.

In my opinion, for a new team on a new project a Scrum Master will be very, very busy, but over time as the teams settle and mature I see no reason why a Scrum Master couldn’t support 2 or 3 or in some cases even 4 development teams – assuming they are all located in the same room.

But the prospect of a team or teams without a Scrum Master at all causes me concern as it exposes them to internal and external pressure to compromise Agile principles. And unless there is an enthusiastic team member you are in danger of regressing and whilst you can certainly manage without a Scrum Master, our goal is not to ‘manage’ or ‘get by’ it is to be high performing and efficient.  If the team(s) gets more value from having a Scrum Master than they cost it should not be a difficult choice.

And if you truly want to be Agile, having an expert around to help and to coach would be high on my list of factors that can determine success or failure of a project.

I personally see huge value in having Scrum Masters and Agile Coaches, maybe not 1:1 with teams, but I question your commitment to Agile if you feel you don’t need them at all.

We all still have more to learn, and there are countless opportunities to improve.

The value of a ScrumMaster

In June 2014 a new ScrumMaster was brought in to work with an existing and established development team

At the point of joining the team had already raised concerns about environments and tools but the team had been unable to express specific issues that could be resolved, these problems had been intermittent for most of the year.   The team was composed of a BA acting as Product Owner, a Lead Engineer, three other developers and two testers with the addition of a ScrumMaster this made a team of size 8, which equates to an approximate cost to the business of around £600,000/$1,000,000 a year.

The team measure their productivity using a term called velocity, which is how much work measured using a relative scale is achieved over a period of time. The amount of work fluctuates for a variety of reasons, holidays, sickness, bugfixing, mistakes, environmental issues, focus or context switching, support requirements, spikes etc.  It is an anecdotal estimate of productivity only. But has become the industry de facto standard for measuring improvement. This had been recorded over the previous year and the documented average for the 12 months preceding the new ScrumMaster is noted below as 100 basis points per week.

Velocity can only be used to compare a team with it’s own past performance, i.e. it is a relative scale, not an absolute measure but in that context it is very useful. But should be used with caution. In this case the team had an existing Datum and a set of benchmark stories. The Datum was not modified and the benchmark stories remained in this period, thus there is a consistent base level for comparison.

Year 1 (Prior to ScrumMaster)

image001

The new ScrumMaster, spent some time with the team, observing and evaluating. He sought to identify problem areas and any behaviour in the team where improvements could be made. But unlike a conventional manager or trouble-shooter he did not issue directives on changes to behaviour.

The team scheduled regular ‘retrospective’ meetings where they review the past time period and look for ways to improve.  The ScrumMaster used a variety of techniques, to coach and guide the team to focus on areas identified either by the team or by the ScrumMaster as problematic or where improvement could be made. The ScrumMaster collected and compiled metrics to aid this analysis, and facilitated meetings to be productive in deconstructing problems in a non-negative manner.

By using this approach the ScrumMaster did not solve the teams problems, he did not offer ‘his’ solution to the team, nor issue directives for improvement. The ScrumMaster worked with the team to enable them to become aware of their problems and the ScrumMaster created an environment where the team were empowered to solve their own problems. The ScrumMaster uses his past experience to identify problems and may steer the team to suitable solutions, but relies on the team to solve their own problems.

In the following quarter there was a notable upturn in velocity (productivity)

Year 2 (First quarter after ScrumMaster)

image002

The ScrumMaster is responsible for creating an environment where the team can reach a long-term and consistent performance – a spike or a blip is not considered sustainable, so it is important to not seek to boost productivity with short-term fixes like overtime or cutting quality. The aim is sustainable pace and sustainable quality over the long-term.

The ScrumMaster continued to work with the team identifying more bottle-necks and waste, removing impediments and coaching the team how to work around impediments or resolve them themselves, there is always room for improvement in a team.

The ScrumMaster also spent time coaching the Product Owner and Programme Manager on expectations and in their interactions with the Scrum Team, including challenging the Programme Manager on how his priorities are fed to the team so that the team could focus to be more effective.

Year 2 (First full year with new ScrumMaster)

image003

Velocity is only one measure of productivity and is largely anecdotal, however it is the only real measure we currently have available.  The productivity improvement should be considered in that context. However, there is a clear and notable improvement in the productivity of the team over the 12 month period.  The team deserves the credit for the improvement as they have improved themselves.  But by adding an experienced ScrumMaster to an existing team he has been able to coach the team into identifying ways they could improve and in doing so doubling their productivity – a significant change in just 1 year.  In this instance it could be argued that the ScrumMaster’s coaching of this one team has resulted in £600,000/$1,000,000 worth of added value to the business and assuming the team does not regress this is an ongoing year on year gain. 

It is not often possible to measure the impact on a team, and velocity is a fragile tool for that, but I hope it is clear from these metrics the value that one person can have on a team.  It is highly likely that Year 3 will not have the same growth but even if the new velocity can be merely sustained the value to the organisation is significant.

Estimating at a project level.

One of the most difficult aspects of the transition to Agile is the confusion over how estimation is done.

Estimation is difficult, the experts suggest that even with a full picture of what is required and with clear detailed and fixed requirements, the best estimators cannot realistically estimate better than within a 25% margin of error. It’s easily possible to do worse than this. But It isn’t possible to be consistently more accurate; it’s only possible to occasionally get lucky.

But in agile we start without clear requirements, we don’t have a fixed scope and chances are the requirements we do have are at a high level and there are many unknowns. I could talk about the cone of uncertainty but I’m not convinced most businesses will accept that level of uncertainty even if it is based on sound reasoning. In my experience they would rather base decisions on a specific guess than an accurate ranged estimate especially a wide range. Sounds daft when I say it like that but I bet you have experienced it.

Nevertheless it is still often necessary for commercial reasons to have a solid estimate before starting a project (Agile or otherwise), in many situations projects need to provide a good ROI or are limited by a budget.  In some situations the ability to estimate reliably could be the difference between the success and failure of a business. These estimates can be crucial.

So how do projects provide reliable and useful estimates?

First of all it is worth noting that estimates are largely misunderstood in general, they are misused and can often be damaging to the project. But still estimates are asked for and used to make important decisions.

In a survey from a few years ago*, a range of IT companies were asked about estimation strategies, the results were both worrying and yet reassuring that difficulties were universal.

* http://www.ambysoft.com/surveys/stateOfITUnion200907.html

Around 44% of the project teams in the survey described themselves as ‘Agile’ so this is a balanced pool of projects and should give an idea of estimation across the board.

When asked to give estimates to the business for project delivery around 65% of teams were asked by the business to provide estimates within the 25% margin of error range that experts in the field say is ‘impossible’. 11% were allowed no margin of error at all they had to specify a single date or a specific cost for the project,  conversely 21% were not asked to give any estimates at all. The rest allowed a margin of up to 50% on their estimates.

So how did that pan out for those companies?

Well 40% never even tracked whether those initial estimates were correct, it is difficult to draw any conclusions from this, but 40% came within that magic 25% of their estimates, which frankly is an incredible statistic, when I first read this I started questioning the validity of the survey. 40% of software project estimates were more accurate than the ‘experts’ say is possible to achieve consistently, 40% is more than just getting lucky it is frankly unbelievable.   At this point I was about to dismiss the survey as nonsense, but I read on…

How is it possible?

In order to achieve the 25% margin of error the projects did the following:

  • 18% admitted they had padded their original estimate
  • 63% de-scoped towards the end of the project to deliver on the estimated schedule.
  • 34% asked for extra funds to complete the projects on the original estimated schedule
  • 72% extended the schedule to deliver the promised scope (effectively revising the estimate and success was then measured on the revised estimate not the original)

It is impossible to tell from this how many of the projects matched the original estimates, but clearly it wasn’t very many, it is not a stretch to conclude that the vast majority of respondents de-scoped and/or extended the original estimates, including those that had already padded the original estimates.

Moving goalposts is the key

My reading of this survey is that very few if any delivered what was estimated in the originally estimated time-frame/budget. It makes very bleak reading and regardless of whether the project was or wasn’t Agile the estimates did not deliver what the business asked them to.

If we take the stated purpose as being simply to plan and budget and assume the estimates were not padded or interpreted then they hold very little value based on  the lack of accuracy.

In my opinion if any of the businesses that demanded such specific estimates went on to actually base business decisions on the accuracy of those estimates, then they were just setting themselves up for disappointment and future problems.

There is no way from this survey to conclude what the accuracy of the original estimates actually was other than to say that even with padding, de-scoping and extending schedules they were still unable to meet the original expectations and were overwhelmingly wrong and seemingly nearly always underestimated the true time/cost. This reads like a recipe for disappointed customers and shrinking profit margins.

That is a very long winded way of saying that (according to this survey at least) no one in the industry, Agile or otherwise is producing reliable estimates for software projects, we consistently get it wrong, and more worryingly fudge the figures so we never learn from our mistakes.  So any suggestion that estimating Agile projects is more difficult is not based in fact, estimating for software projects is difficult full stop.

Do estimates have value?

Now that is a different question, if I was running a business and I received a project estimate of 6 months, I would be foolish to consistently believe it will be delivered to the defined scope in that time-frame. But that doesn’t make the estimate useless.  If one project estimates 6 months and another estimates 3 months. I can conclude that the first is likely to take longer than the second, especially if the same person or group has estimated both.  Both estimates are likely wrong but chances are that on average and over time they will be wrong by a consistent margin, which makes them predictable.

If I check historic records I might be able to see that projects estimated at 6m generally take 8-12 months, or better yet I could ask the estimators to compare the current proposed project and identify a previously completed project that is closest in size and scope and use the actual figures from a sensible comparator.  Empirical evidence is so valuable I’m surprised more emphasis is not put into keeping track of past estimates and actual delivery costs and schedules.

Estimates are not commitments

Essentially we need to accept estimates as simply estimates not as a plan or a commitment.  Any PM that transposes an estimate of a software project straight into a plan is nuts, and it happens so often that in my experience developers turn white and have panic attacks when asked for an estimate, painful experience says they will be misused and ultimately the one that gave the estimate gets blamed.  If the business could be trusted to accept that estimates are not an exact science and factor in realistic contingency based on empirical evidence then developers would be less afraid to give estimates.

So how should we do it?

I have two suggestions, the first is to use an extension of the Planning Poker process.  Take a group of people that are experienced with software delivery and relatively knowledgeable about the scope and complexity of what is being asked. E.g. Product Owners, Business analysts, Project managers, representatives from development and testing.  Ask them to give estimates of a variety of projects relative to each other.  I’d use Fibonacci numbers or T-shirt estimates, to keep it at an abstract level.  If possible I’d try to include a benchmark project (or more than one) where the actual time/cost is known.

Blue-11Blue-6If we accept that the best we are going to get is a granular; relative; ball-park estimate of a project then this should give you that and more. In fact for budgeting purposes a reliable granular estimate is of far more value than an unreliable specific figure, and far more valuable than the estimates in the survey. Over time it is likely that the estimation team will learn and improve, they will get better with every completed project. I’d have far more confidence saying a project is either a Medium or Large T-shirt.  The T-shirt sizes could map to high level budgets.

My second suggestion which could be used in conjunction or independently of the first is to set a budget and ask the team to provide the best product they can within that time/cost. A good Scrum team will be able to prioritise stories and features to ensure you get the best value for money. If that budget is based on the poker estimates above it is more likely that the budget chosen is realistic and you will get the product you want.  You will also very quickly be able to tell if the project will be unable to meet the goal and can cut your losses early, rather than having to pour more money into a money-pit project that is over-running but too far down the line to cancel.

Estimation is a difficult skill to master but a group is far better than an individual.

Is estimating story points waste?

I occasionally participate in some of the discussions on Scrum/Agile where questions are posed and answered by experts. I have noted that there is a pretty strong contingent that see estimating as ‘waste’ and advocate against estimating, there are various techniques proposed that involve not estimating. I will state upfront that I am not one of them, and although I do understand and agree with many of their reasons, I feel that in some situations they may be missing out on a number of subtle and not so subtle benefits that the process of estimation brings.

Do it my way.

My first counter argument is that I object to anyone saying ‘their method is right and yours is wrong’. In my experience every team, every organisation and every project, is different, suggesting a one size fits all is ludicrous. I believe a good Agile Coach will assess each situation and seek to find a suitable framework for that particular situation. Blindly proposing changing a situation to fit your preferred method is hubris – in my opinion.

I will refer to my experience of ‘estimation’ and how and why I feel it is not waste and does actually add both direct and indirect value to a software delivery framework.

How can you assess ROI – without knowing the I?

First and foremost, it is very simply often necessary. Some are fortunate to be in situations where direct ROI (Return on Investment) is not scrutinised. But I have nearly always worked in situations that are commercially driven or commercially motivated. A feature is prioritised based on its value to the customer (the R in ROI) but not in a bubble, if the cost of providing that benefit is high (The I), the priority changes, often the feature can be assessed as not viable. A Product Owner or a business cannot make a judgement on ROI without an estimate of both R and I, if the team isn’t providing that estimate then the Product Owner or BA is doing the estimating themselves on some level and an estimate of work taken outside the team is highly likely to be less accurate and therefore less useful than if provided by the team.

Whose waste? Are you eliminating waste or dumping it on someone else?

So if ROI is a factor and someone IS doing an estimate somewhere, then calling it waste and not doing it within the team is just pushing it out to somewhere else, you are not eliminating waste you are moving the work elsewhere and to somewhere where the results are less accurate or reliable. This is not ‘lean’ it is not eliminating waste, it is actually just pushing a problem upstream and adding risk.

How much waste?

Even if you still believe that the act of estimating is waste – just how much waste are we talking about? I find story refining vital, one of the biggest hindrances to flow of getting stories to delivery is not having them refined in advance, if a story is well prepared the team can pick up and go. So assuming you agree with refining stories then estimating a story is simply a couple of minutes tagged on to the end of a refinement exercise – we are talking minutes – the waste(if you still believe it is waste) is tiny and yet the commercial value of the estimate to those outside the team is high. If you push it back on the PO or BA their effort will be much greater, you may even be creating waste by refusing to estimate.

Subtle benefits.

But even ignoring the commercial need for estimating, there are other benefits too. As part of the refining process a story is discussed and assessed until the team feel they have a common understanding. But how can you be sure they have sufficient understanding, when does the conversation end? In Scrum at some point they are able to estimate the story this is a natural destination of the conversation. In this situation the very act of estimating is a tool for focussing a discussion and reaching a consensus, the readiness to estimate is a measure of the conversation concluding.

Is an estimate a Barometer of consensus?

But it can also be a barometer of a consensus of understanding. If when estimating there is a wide distribution of estimates or a single estimate that differs from the others this is immediately an indicator that common understanding has not been achieved and that the requirements may not have not been universally understood, I say May as we do not know the reason for the difference without further discussion, but without an estimate this discussion would not have occurred. A consensus and narrow distribution of estimates is an indication that there is a common understanding, the fact that there is a relative size estimate that can be used for other purposes is a bonus. In this example the value in measuring that you have a common understanding of requirements and agreement that a story is ‘ready’ is hugely valuable to promoting flow.

Is an estimate a conversation starter?

But there is more, an estimate is a conversation piece, it may throw up suggestions of quicker solutions or ways to combine stories or breakdown stories. Without an estimate there is no focus for these discussion, without an idea of scale or scope there is no incentive to find a smaller solution or a more efficient solution.

An estimate is a conversation not a number.

In essence what I am saying is that an estimate is not just the number, it is the result or the output following a conversation and whilst you may debate the value of the output, the value of the conversation is considerable and is so often underestimated.

Agile Transition Frustrations

On the back of my good day last week, I have run in to a somewhat frustrating day today.

I have taken it upon myself to challenge the adoption of Agile in the organisation, it has been over 18 months since they adopted Scrum, and there are currently 7 Scrum teams each with a Product owner and there are 3 Scrum Masters and an Agile Coach/Scrum Master.  Sounds great! except that not one of those 11 roles have a job title to match.

In every case someone is ‘acting …’ – they are seconded from another role.  In most organisations that wouldn’t be a problem, you could be pretty flexible, temporarily at least. But in the Civil Service a job description and responsibilities are a big deal, every 6 months there is an appraisal of your work where you are measured on objectives that are constructed based on your job description and designated roles and responsibilities of that job, so unfortunately those in the roles of PO and SM are struggling to meet any of their objectives, not to mention a lack of support and backup as those more senior in the organisation are not familiar enough to formally provide it.  So it is being provided informally by those that are enthusiastic about agile.

So I decided that the time had come and I wanted to press it with HR, I want to create formal roles to reflect the work being done, to allow those interested to be able to apply and those doing the roles to be recognised and rewarded. And then finally I wanted to ensure there was a support network in place. (I could be biting off more than I could chew)

But today I met with two people – one responsible for organising the support network and one from HR, the lady from HR was fantastic, all you could ask for from an HR rep, she seemed genuinely concerned about the people, about ensuring they got the support and had career options and had clarification of their roles and responsibilities. But the support network guy… Now I don’t know if he misunderstood my request, or whether he was irritated by agile or what the situation was, but I felt I was on the back foot, he suggested that ‘some agile advocates’ were so zealous in their agile application that they created a rigid process worse than the ‘traditional’ approach. He seemed to suggest that as agile had no process that formal support was unnecessary, and he then spoke for a while about how the process was not understood, followed or even liked by the organisation, and I must confess at this point I wasn’t sure if he was talking about agile or the professional support network he was responsible for.

I felt very deflated, I really thought I would be pushing on an open door, this was someone (me) wanting to utilise their expertise and help make the system work by making it relevant to those doing the job and I was being criticised for not being ‘agile’  I found myself questioning what I was doing. Was I being un-agile? Was I imposing structure and regulation?

In the end the HR rep concluded very diplomatically that we were not ready for him yet and we would re-convene again without him – phew. But it still made me stop and think, was I doing the right thing?

So I have spent this evening thinking a lot about it, and on reflection I put it down to a belief that agile means no formal process. This is clearly wrong on a number of levels, but in the Civil Service it would be an impossible situation, formal process is so ingrained that you need a very formal process to not have a process.

The agile principle is that we favour “Individuals and interactions” over “processes and tools”. But that is not the same as saying we don’t believe in processes. I believe that the people are crucial and that providing structure, support, training and opportunities is very much the agile way, and if I need a process to do that so be it.  What is un-agile is to not provide these vital people support because a process gets in the way – which is the current situation.

Sometimes being challenged in your thinking really helps clarify understanding, and whilst I left the meeting frustrated I am now very pleased I had that conversation, I feel more certain than ever that it is both right and necessary for me to challenge this situation, and keep the focus on the people. 

Coaching is the easy option?

I have run into a strange dynamic in the agile transition today.   As part of the transition to an ‘Agile’ organisation I have been pushing HR to create and formally recognise new roles, specifically Scrum Master and Product Owner, up until now it has been by unofficial secondment.  Part of me feels pleased that we are getting traction over the move and formal recognition is a major step forward in the Civil Service.

But now I have hit a rather significant hurdle, how grades are classified, the Civil Service – or at least this particular location – classifies and grades roles based on accountability, responsibility and number of reporting staff.  So a servant leader that coaches and supports and has no direct reports comes out classified as a very junior admin assistant, the people doing the role it turns out are two or three grades higher than ‘proposed’ which is clearly a serious mismatch.

The advice has been to reword the job description to add responsibilities and authority and accountability, but that feels wrong to me. I am trying to educate and apply Agile principles to the organisation and this feels like a very unpleasant compromise.

It seems that somehow coaching is classified as an easy skill and the lack of apparent direct accountability and responsibility does not sit well with the pigeon holes that the roles must fall in to.

I have tried explaining that coaching is actually far harder than managing, using coaching skills to help a team discover for themselves what to do next is a very difficult skill, but when done right what they learn gives a far deeper understanding and more likely to be maintained than any amount of compelling, controlling or micro managing task assignment.

Those involved seem to understand and appreciate what I am saying but we are challenging the system, it will be an uphill battle. This is new ground and a transition to Agile is rarely easy and it seems the bigger and more established the processes the harder it is to change.

But I wonder why coaching is seen as an easy option. It rarely is. A coach actually has to be pretty mean, they have to be tough.  We have to turn a mirror on people and often show them some unpleasant aspects of themselves, often they are unaware, which can be even tougher to deal with. I sometimes have to sit back and watch someone fail knowing I could have prevented it – not because I want to see them fail, but because failure can teach far more than correcting them.

I sometimes get pressure from management to assign tasks, or to get the expert to do a job because it is quicker, or to challenge certain behaviours directly. I resist and this can and often does reflect badly on me, but I resist because I believe providing an environment where the team learns for themselves is far more valuable than any short-term gain resulting from taking away their independence.

I see my job as protecting the team and creating an environment to grow and learn. I do this by asking a questions to provoke ideas, I challenge where I see potential, sometimes I stray into leading questions if I think it helps but I try very hard not to provide answers, and if I slip into leading rather than coaching I hope I get someone turning a mirror on me and coaching me how to be better.

I love my job, but I don’t coach because it is easy, I coach because someone needs to be tough and push you to do better.

There is a quote in Lyssa Adkins’ book – Coaching Agile teams, which I will paraphrase a little, it says so much.

A friend likes you the way you are, a coach respects you too-much to let you stay that way.

Anyone that thinks a coach or a Scrum Master is the easy option should try walking in those shoes for a while, it may put a whole new perspective on things.