Is showing-up half the battle?

In the office we have been discussing the possibility of developers Working from home recently. With mixed reactions, and mixed experiences.  Judging by this comment from the Yahoo! boss a couple of years ago we are not alone.

http://money.cnn.com/2013/02/25/technology/yahoo-work-from-home/?hpt=hp_t1

Marissa Meyer’s view on home working was:

“To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices. Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. Speed and quality are often sacrificed when we work from home. We need to be one Yahoo!, and that starts with physically being together.”

My personal experience was that as a developer when I was working on a clear piece of work I found working from home far more productive, less distractions, I enjoyed my own domain and often it seemed like coming to the office was unnecessary. I am by no means someone that has a negative impression of remote working.

But Scrum is a very different way of working. Pair programming is common and even when not pairing there are continual short conversations; clarifications; general evolution and interaction when implementing and testing stories. The to-and-fro is never ceasing, there is a buzz to the team process.  My experience is that even the need to pick up a phone breaks that flow and interrupts the spontaneity.  A dev may have a very quick trivial question for the Product Owner and may feel comfortable asking it in the context of a team room, but if they need to make a phone call they may not bother and make an independent assumption – I have seen it happen regularly, and assumptions are the path to the dark side.

I know there are a lot of teams that work remotely, and some successfully, I am not saying it can’t work, but my preference for a truly productive team is to have the whole team together in one room all working together.

That doesn’t exclude consideration for flexi-time, family emergencies, general common sense, good-will and the practicalities of life, all of those are far more important than rules on attendance. But in my opinion the norm should be everyone in the office in one room all together working towards a common goal.

Like Yahoo! we want to create an environment where we can be successful, we also want to create an environment where employees feel valued and respected, where their needs are considered important and ultimately a place where they want to work. But in my idealist vision at least Working from home is a ‘perk’ that doesn’t fit easily with Agile/Scrum. One of the core principles of Agile is The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Whilst it is possible to make Scrum work remotely anything that gets in the way of face to face conversation is an impediment that I would prefer to remove if I can. There are many tools to reduce that impediment but I’d rather remove it entirely and have everyone in the same room.

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.

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.

What is the Minimum Viable Product?

A question came up this week following a discussion on story writing that I think bears further discussion.

What really is the Minimum Viable Product? 

To explain my thoughts I will use the building of a Skyscraper as an analogy.

The project vision is to build the UK’s tallest building. To achieve that it must be over 1000ft tall and 88 floors.

What is the MVP?  There are many possible answers to this, but the first two responses that spring to mind are:

1                 My MVP is over 1000ft tall and 88 floors, without that it simply fails to meet my vision.

But let’s say I underestimated the costs and after 65 floors I run out of money, I have been agile and each of the floors was a complete deliverable, the building is perfectly functional at 65 floors, in fact it was probably functional at 1 floor.   So surely at any point it was an MVP?

construction

2                 My absolute worst case scenario MVP a single floor

This is where things get confusing.    No serious customer would consider a 1 floor building with massive land costs and hugely expensive foundations ‘Viable’  the project would never be signed off.  As such this is not viable.  However, I’d still suggest aiming for the ability to deliver in phases, e.g. a delivery after each floor.

In this situation I’d say an MVP is the minimum that a customer would accept. And that is a conversation, would he agree to a MVP of 88 floors but a first phase goal of 20 floors, with the ability to expand later? As you can imagine the MVP is likely to change according to the circumstances. Our goal is to delight the customer but our plan is to build the product in such a way that if at any point he is satisfied or better yet delighted, we can ‘deliver’ immediately.

skyline

My point – hopefully not lost in the mix is that an MVP is about thinking about the minimum that a customer would find useful – usually this is closely related to the original vision. In the case of this building – what if the last 10 floors were empty unfinished shells? or similarly we leave the project in a state where it is valuable as is and the Vision can be achieved in a future project  – The building still will meet the vision and those floors could be finished later?

Having an MVP in mind is useful, it may help with some decisions, but every project is different and MVP will likely evolve with the project. A good Product Owner or BA will be able to work out what is the true MVP and why. The PO can focus on the customers evolving needs so that the customer gets the best ROI at each stage, but most of all they will be aware of what would be the solution that would delight the customer.

An MVP is a tool like any other, in most cases it is a fall back position, not the goal.

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.

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. 

Agile in action

For the most part it was a pretty normal sprint, the team read and refined the stories, asked questions and clarified the requirements. One of the stories referred to a text editor where text would be cut and pasted. There were questions about formatting and content and the PO was sure that maintaining formatting was not required and that the text would be standard text.

The team worked through the story and completed all acceptance criteria and everyone was happy, except one of the development team who felt an urge to work closely with the users and get actual examples of the text they used and how they worked. It turned out that one of the source documents was non-standard in the sense that the text editor selected was not able to cope with the source data, when pasted critical characters were lost.  We investigated further, and it also turned out that formatting and layout were also very important to the users in some situations, something not fully understood at analysis.

The team, the PO and the BA worked together, they all got involved and came up with a solution, and we have written a new story to be included in the next sprint, which means a slight delay in functionality being released to the users but as an observer to this incident I was very proud of how agile the team behaved and how smoothly we adjusted to what was in effect a significant blow to the initial design.

That may not sound a big-deal but if you consider that had we not challenged the requirements, had we not had open and effective communication with the Product Owner and the users, had we implemented requirements as written we would have been able to sign-off the work and likely get all the way to release and delivery to the users – weeks if not months later before this problem was identified, by which time the cost to resolve would have been considerable and the disruption to all would have been significant.

This is a great example of where agile can be a great tool.  A situation where the team made customer collaboration a priority over contract negotiation, and responded to a change rather than adhering to a plan.   Sometimes I worry that the benefits of agile get lost, but on days like today I feel like agile really has made a difference.  I feel immensely pleased with the team.

Velocity

I have seen a number of discussions recently about velocity, and generally the harm it can cause when used incorrectly. Most seem to advocate not using it to avoid mis-using it but whilst it is a blunt instrument it is just information like any other metric and for a process that relies on empirical evidence to adapt and evolve it seems odd to ignore a very useful metric, so instead I will try to explain how, when and why velocity could be used to add value.

My car has a trip computer and among its varied metrics it offers an ‘instant fuel economy’ feature.  Why? I don’t know, but to my mind it is a pretty useless feature, but it is there and at any time I can take a spot check and it will tell me how much fuel I am using in mpg.   When racing up the hill to the Air Balloon roundabout foot down it drops to around 20 mpg, when coasting down with my foot off the pedal I get 99 mpg.

If I were to take a single reading half way up the hill and claim that my car does 20 mpg I would get a totally distorted view of the velocity with which I consume fuel, equally if I took a single reading coming down at 99 mpg.    I’m sure most of you would think I was nuts to even consider taking a single reading as an absolute indicator of future velocity. But somehow with ‘sprint velocity’ people think that is okay.

Let me stretch the analogy further. I know that a single measurement is a little crazy to base things on, so let’s take an average over the last 100 miles. That is a pretty solid and reliable metric, most of us would consider that to be a reasonable predictor.   But I have spent the last few weeks only driving around town, stop start, traffic jams, short journeys and so on. But now I have a long trip, mostly motorway, will my average fuel consumption velocity be a good indicator of the next 100 miles?  No it won’t, common sense tells me before I even look that my velocity will be different under different conditions.  A velocity only has meaning if the measured data is representative of the future conditions.  Equally I tend to drive with a heavy foot, but I am quite sure if my father were to drive the same journey in the same car the consumption velocity would be quite different.  The same is true if I drove a different car, the velocity would be different even if my driving conditions were the same.

Velocity tells you only one thing – what was consumed in this car in these conditions. It offers no view of the future, or of alternative conditions.

But I am free to interpret, I can predict, I can guess, I can extrapolate all I like, but it is not the velocity that comes up with these figures – it is me. If I make a prediction and it is wrong, I cannot blame the velocity, the velocity is a measurement of what was, not of what will be.

So how is it useful then?    The most obvious is to say that if I believe that my typical journey over the next 100 miles will be similar to the last 100 miles, similar driver, similar journeys, similar car then it is not unreasonable to expect similar results.  It can be a predictor.

Or let’s say that I am a little bit eccentric and I decide that I want to increase my average MPG and I spend the next 100 miles on similar journeys in a similar car, but I try very hard to improve my driving to be more efficient, in that case it can be a blunt measure of improvement in my driving if the average goes up, I can measure improvement.  I would caution myself very carefully on this particular measurement because it could easily be a change in the road conditions not the driver that is the cause for a change but even so it is a measure – the interpretation of meaning is mine.

Or if nothing changes that I am aware of and the average goes noticeably down or up, it might be an indication of a problem it might be an indicator there is a problem with the car, or my driving, or even just different fuel.

So now I understand all about the velocity of fuel consumption my current average is 50mpg. How much fuel will I consume on my next journey?     There is no way to tell, to even make a reasonable estimate I’d need to know an approximate distance, I’d need to know the terrain and even with all that there are still unknowns, I may hit a delay in traffic, or a diversion, I may get asked to call in and pick up milk, I may even breakdown.  And if I could predict all of that and gave you an estimate, would you trust it to any degree of accuracy?  I wouldn’t, I might trust the estimate to a degree, but I wouldn’t play to fill up on empty on such an estimate I’d almost certainly plan a significant buffer to ensure I didn’t run out of fuel.

I hope most of you would agree with my views on fuel economy, there are simply too many unknowns to make accurate predictions.

And yet, I reset my trip computer fairly regularly every 1000+ miles or so, and on average over that 1000 miles my economy is in the region of 48 ish, it very rarely fluctuates significantly from this. Over a very long timeframe I can get a very accurate estimate, that is consistent 1000 miles after 1000 miles.  That still tells me nothing about the next 20 miles or even 100 but long term I can be consistent.

Another interesting observation is that to get this measurement I am using an extremely accurate tool to measure, I am in a known unvarying state – same car, same driver, similar journeys.  And yet with all this certainty I still don’t trust my predictions to any degree of accuracy I buffer I plan contingency.   But if I stop talking about cars for a moment and I talk about software, more specifically a team developing complex software with a great many unknowns, where the team members can take leave, be sick, have family troubles, they can leave the team, or new people join the team, they can learn new skills, use new tools.  But we are expected to estimate, often to a very specific dates, large quantities of unknown and often very complex work. What is more odd is that those estimates are often taken as commitments.

If a rational person wouldn’t trust a reliable and regular machine like a car to give specific accurate predictions with fairly well known parameters, why do similar rational people expect such accuracy from a domain far more variable, far more complex and far more unpredictable?

My rather long winded discussion on fuel economy is really summed up in one sentence.

There is only one estimate on how long a software project will take that I would trust and that is one given the day after the project is completed.

Otherwise use projection tools like velocity in context,  if the future conditions are likely to be unchanged then velocity can be a useful tool, but the longer the average the better.  And if your circumstances change: the team, the type of work the domain, the tools your current velocity is meaningless until you have enough information to create a new measurement.  And think of your car, what value is an snapshot measurement without context.

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.

Back to Scrumdamentals

It has been a pretty difficult few weeks for me, busy, busy, busy and frankly more management than coaching. Cue air violins!

In the division I am working in there are three Scrum Teams, up until now I have been responsible for two and the third has tried a number of ways to accommodate the lack of a Scrum Master, one member of the team took on the role for a while on top of their other duties and a Project Manager took it on for a while, again on top of other duties. But these part-time roles have been unsuccessful and I was asked to take on a third team.

I was very reluctant to dilute my other responsibilities and expressed this to the department head, and so we agreed it will be temporary and I’ll be training a new Scrum Master for that team to take over in a few months. Which is great but also means I now have responsibility for three teams and training of a new SM, and we will be losing one extremely valuable member from a team.  As I say Cue violins, but my concern is not just workload, it is the teams themselves, one of the teams already feels I don’t spend enough time with them and spreading me thinner wont help with that. So that is problem 1, 2 and 3 but my other and now more serious problem is that the final team is in a state of flux.  The Product Owner has moved on to a new role and it has been difficult to find a replacement.

A Product Owner is a difficult role, and seemingly undesirable. The product is essentially a suite of very closely integrated sub-products with what is intended to be a single front end, the product cannot easily be split because of how closely coupled it is, but the system is so complex there are at least three Business Analysts and an Architect who when combined cover the understanding of the system. The chief architect is ultimately the product owner, he makes the call on the roadmap and the priority of content into the system, but doesn’t have visibility of the fine detail at an individual story level, that is down to the BAs who are doing it on top of their other responsibilities. So prioritisation is at Epic level, with the BAs prioritising the smaller individual stories.

And to cap it all we have hit a spate of recruitment and retention issues. We had decided that the volume of work was such that we would expand and have a second team on this product, but over the last few months two contractors have left, primarily for family reasons (and higher rates) and a very experienced member of the team has got a promotion so he too has left, and as I say another team member has volunteered to be trained as a ScrumMaster, all told a major impact on one relatively small team. So I have been very very busy recruiting (30+ interviews over the last 3 weeks). I have spent the last couple of weeks almost exclusively interviewing and screening CVs. Thankfully offers have been made and I’m hopeful we will have a new team up and running in a few weeks.

But it is essentially a brand new team; a new Product Owner Dynamic; and a major new piece of work.  A new Product Owner, and 3 new proxy product owners(Business analysts) a new Scrum team comprised of a former tester and 4 new former developers (I say former as once in a Scrum team I hope they will all see themselves as a cross-functional team).  All this got me thinking. At first I was anxious about the disruption, I am also anxious that the Product Owner representatives are not dedicated to what is a major product, but after some thought I realise that disruption is the wrong word, the team can’t really be disrupted, there isn’t enough left of the old team to call it a disruption.

New Structure

What we have is a fantastic opportunity, we can create and build a new team from scratch. It is not often you get to join a team at the beginning and are able to shape it to be the team you want to be a part of, usually it is a case of fitting in. But the new team members are joining a high profile new product together and get to shape it as we collectively see fit.

All of the team have had some exposure to some form of agile development they seem strong developers and eager to use Agile, so there will be a degree of Scrum training and coaching but for me the crucial task is to build a team first, get them working together, learning strengths and weaknesses and growing into a team.  I still have a lot of worries, especially about growing a new team whilst also supporting the existing teams, I cannot give the teams as much attention as I would like, but I am actually pretty excited about the prospect of helping build a new agile team.

I have been trying to think of a good place to start, no doubt the level of Scrum training will vary so I thought that I might try a combined Scrum Training and team building exercise. My train of thought led me to http://www.lego4scrum.com/  it is my hope that when they get on board, I will set up a session for them and mix it up with the other existing Scrum Teams. I plan to write up a review after the event which I will post here.