Agile for the real world.

I have once again this weekend been drawn in to reading articles and discussions on LinkedIn, mainly discussing how Scrum=Bad, KanBan=Good, or KanBan=Bad and ScrumBan=Good, and a variety of similar content that frankly is just noise to 99% of the people involved in Agile Software delivery. The reality is that most software professionals really don’t care.

Did I really say that?

It might be a little ironic and I might just be adding more to the noise but I’d just like to bring us down to earth a little.

My experience of Software delivery has been mostly large corporations and the Civil Service, and what I can say with a good deal of confidence is that the staff involved in software delivery want Agile, no question, they are overwhelmingly in favour. I suspect that a step back to Waterfall would see hands go up in horror and a great deal of frustration and maybe even many people leaving in protest.

But I see it as the difference between learning to drive and understanding how an engine works. Most, and that is a sweeping generalisation, but most of the teams I have worked with want me to teach them how to drive, they want to use the skills they learn and to be taught how to teach themselves. What they are not interested in, initially at least, is the mechanics of the car. When they become proficient that may change they may believe that for particular types of driving a different vehicle may be appropriate, but initially simply learning to drive and practicing the basics is as much as is needed and they are happy to have a car suggested to them.

Recently I have been working very closely with three development teams and indirectly with others, and of those teams I’d estimate that maybe 10% have an active interest in the mechanics of Agile Software delivery as a topic and probably less than half of those would give two hoots which flavour of Agile we follow, so long as we follow the principles – most see the framework as a tool like any other it is about getting the job done right. But 100% want to be shown how to use Agile techniques to improve their way of working, but they rely on an expert to guide them. They wouldn’t hesitate to tell me if they thought it wasn’t working.

Most have had no prior Agile experience other than minimal training. Many have been in Agile workplaces in the past but if I am brutally honest they seem to have been poor implementations, a few had good experiences and a very few have been exposed to more than one variation of Agile frameworks.

In the real world a development team wants to build software, perhaps a little over simplistic but a coder wants to code and a tester wants to test. Now I can encourage them to co-locate, cross-skill and try to mix things up, they can use Agile to improve and most have an inherent desire to be Agile and improve. I can show them how to use TDD or BDD, I can encourage them to Pair Program, and they will be enthusiastic and supportive. Most will join in Retrospectives with relish and find true value in Stand-ups, most see the value in Sprint Reviews and the closer engagement with Customers – Why?

Why? Because they are embedded in a framework that works for them, they see positive results and they like what they see. But that doesn’t translate to wanting to have a discussion on the finer points of Agile frameworks. Most don’t see value in a debate on the differences between Scrum and Kanban.

As an example: I have read a lot about #NoEstimates recently and I find it interesting, there are others in my organisation that I could discuss it with and share ideas. But honestly I suspect the teams I work with really don’t care, they use Story Points and T-Shirt sizing because I showed them how and because it works, they see the value. Would they change to NoEstimates – maybe, probably! if I encouraged them to, but the likelihood of the suggestion coming from the teams is low, and it is unlikely to have support or interest of the majority. Certainly not enough of them would have sufficient interest and understanding to make it an inclusive discussion.

However, The same was true of Pair Programming, initially I met quite a bit of resistance from the teams, one guy in particular was very much opposed and resisted, but I encouraged the teams to try it out for a Sprint and then another, and now it is a regular part of their routine and the biggest opponent is now the strongest advocate.

You may be thinking that these teams were not very Agile, or they are not sufficiently mature, but that simply isn’t the case. It just isn’t their primary area of interest. While I am reading about Agile techniques they are reading Tech journals or exploring new tools. As an agile practitioner these details and nuances matter to me, but to a software developer they are just another framework, another tool in their toolkit. The teams may be self-organising but sometimes it needs an outside catalyst to encourage them to push their boundaries.

My point is that software delivery is the goal, the Agile Methodology of choice is just a tool selected to do the job, don’t expect a horde of zealots raising pitchforks and screaming “Scrum”, or “KanBan” any more than they would demand TFS or Jira or any other tool. At least not until they have used it enough to be proficient. That debate is reserved for the agile practitioners.

I have seen Scrum adopted well and adopted poorly, the same with Kanban, neither is a silver bullet, and one is not better than the other (In my opinion). Again in my opinion, when I hear complaints about scrum it is generally because it is not Scrum, but an unchanged organisation that has applied scrum titles, or a cargo cult that follows the schedule without understanding the purpose. And sadly the current trend of handing out certificates to anyone that has done a half-day training course demeans the framework. Too many people see Scrum as a means of control rather than a framework of support, and sadly that is the weak underbelly of Scrum, the framework can be used to create self-organisation but can just as easily be used to stifle it if you have the wrong mindset.

Agile is a mindset much more than a process, the framework is simply scaffolding, but if your mindset is wrong the implementation will be wrong.

I love Scrum, I think it has so much promise and when used well I think it can be hugely effective, in most situations it would still be my starting point with organisations new to Agile, especially when management is not fully engaged. One of the likely intended side-effects of Scrum is that it becomes a tool to regulate the rest of the organisation and create stability for the teams to grow, it creates a protective bubble to enable agility to develop.  

So It saddens me when I see Scrum being seen as a barrier to agility. When ScrumMasters are wolves in sheep’ clothing and simply managers or PMs assuming a title and then undermining the framework, because they don’t understand the essence of the role. Where cargo cults masquerade as agile teams, and when they fail they blame Scrum.

My dad used to say that a “bad workman blames his tools” this was never more true than with Scrum. As a tool in the right hands it can be fantastic, in the wrong hands it becomes a fine quality chisel being used as a crowbar.  

The debate will continue and sadly because of its early success in widespread adoption Scrum has had many poor implementations and so is in danger of bad press which could ultimately spell it’s doom. Far too many experienced agile practitioners are advocating against Scrum based on bad experiences, but I for one believe that as a framework Scrum is good, but sadly there are too many cargo cults giving it a bad name. 

Is Agile a Quantum Leap for a Project Manager?

I have been asked why you can’t have Project Managers in Scrum, and there are a number of discussions on boards that have entertained me, where there is a question about whether there is such a thing as an Agile Project Manager?

The problem for me is that Project Managers are measured on the wrong things, their objectives conflict with Agile goals they are almost always put in a position where they are pressured to conform to a dysfunctional notion.  I see them as a sort of dysfunctional Sam Beckett from Quantum Leap “…striving to put right what once went wrong and hoping each time that..” well you get the picture. There is a notion that the plan in their mind is more important than the reality in front of them.

But in Agile we value “Responding to change over following a plan”

At it’s heart, the job of a Project Manager is to plan a project – usually in fine detail, and then to manage the project to ensure it doesn’t deviate from the plan, and when it does deviate, which of course all but the simplest projects do, the PMs job is to take corrective action to get a project back on plan.  It is about dates, and deadlines and the all-important plan. (cue lightning, harsh shadows and ominous Gantt charts).

All we need is a strangely dressed hologram saying “Ziggy predicts that if we skip all testing of the software there is a 93% chance that we will meet our deadline and the software wont devolve in to a pile of un-maintainable junk for 9 months and 3 days.”

Al_Calavicci_Handlink

The project Manager then gets to ‘Leap’ to a new project without having to stick around to see the mess left behind.

This is in so many ways the very opposite of an Agile philosophy, I see nothing wrong in having a plan, understanding the vision and the goals is crucial. Even some milestones are often beneficial, but the more detail there is in the plan the more waste there is. Everyone including the Project Managers know perfectly well that the plan is flawed, just like every other plan they have ever produced, the difference is that in Agile we accept that the domain is too complex for a fixed and immovable plan. In agile we adjust as new information becomes available, but the traditional Project Manager wrestles with reality and desperately fights to shoehorn a complex reality into a flawed plan.  We all know this, the statistics on ‘failed’ project plans are staggering and yet some still persist in this notion of creating fixed plans and punishing teams for deviating from them.

Agile in contrast focuses on getting the customer what they want, and they do this by getting something to them as early as possible and as often as is practical and then responding and re-evaluating, changing the plan to accommodate the customers evolving requirements. Maximizing value early for the customers benefit.

So can there be an Agile Project Manager? I don’t know, but if the role involves valuing following a plan over responding to change then it becomes an oxymoron.  And with a Product Owner and a Scrum Master I fail to see what useful purpose they can serve in a Scrum framework.

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.

One swallow does not a summer make.

Version One  are currently in the process of compiling their 10th State of Agile Survey (Link to Agile Survey)and this caused me to go back and look at the previous results. As an Agile advocate and practitioner I am very pleased to see that last year 94% of organisations say they practice ‘Agile’  albeit that 70% were relatively new to it and could be said to still be in the transition period. This is all great news, it is a sea change and a clear move towards accepting Agile software development as a mainstream way of working.

But, and it is a pretty big ‘but’ how many of these teams are really, truly Agile and how many are jumping on the bandwagon and saying they are Agile when really all they are doing is one or more activity that has its roots in Agile and so ultimately only slavishly adopting Cargo Cult behaviour.

For those not familiar with the term Cargo Cult, it is where some elements of behaviour are mimicked with the expectation of getting the same results, but without really understanding why you are doing it. Cargo Cult    

With many flavours it is difficult to say what makes a team Agile, it is after all an attitude rather than an action, but there are some actions that are generally considered to be core to Agile Principles. At a minimum I would consider: Co-located teams; Iteration reviews; Retrospectives; Continuous integration and Prioritized backlogs as key.  The list goes on but I would struggle to believe a team can be agile without a minimum of those.

So by using my benchmark of what is the minimum less than half 46% (likely even less) do all of those. More than half of those are claiming to be Agile are doing it without co-located teams, without regular reviews, without regular planning, and without regular retrospection. I want to ask them in what way are you Agile?  You could do all of those and still not be Agile, but if you don’t do any then it is doubtful you are able to learn and adapt.

It is with almost despair at times when I am interviewing a candidate and I ask if they have Agile experience, they invariably answer “Oh yes” when I ask them to describe it they will say “well we have a daily stand-up”, sometimes they say more but for a majority that is it.  I don’t hold this against the candidate, most developers when offered a true agile environment learn fast and thrive, but having a daily stand-up does not make you Agile.

The transition to Agile is now in a pretty vulnerable state, the early adopters were motivated and were likely already Agile in nature and the techniques followed on, they succeeded because of their attitude and created a framework on the back of it and for many this works.  The mainstream have heard it works and are mandating a change but are in danger of creating a wave of cargo cult teams paying lip-service to Agile, and when the transition proves difficult they are blaming the framework rather than understanding that it is a change in attitude and a change in culture and not simply a 15 minute standing meeting that must be endured each day.

The message we as Agile practitioners need to get across is that the transition is not always quick and it is very often difficult, but if you adopt an Agile attitude it will pay dividends, if you simply pick and choose one or two ‘Agile’ techniques in isolation without understanding why, you are in danger of failing without ever really trying.

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.

Vision without action is a daydream. Action without vision is a nightmare

Waterfall vs Agile?

Sounds a bit daft to even be having the debate, surely by now there is no one left that still thinks waterfall is the better choice for delivery of complex software projects, unfortunately that is very far from the truth, there seem to be many that still prefer waterfall and recently I even heard it talked of in terms of the good old days.  So I delved a little deeper.

In this instance the source was a statement by someone who’s opinion was given weight. The comment was:

I could deliver ‘project x’ using waterfall if you gave me dedicated resources and we could lock ourselves away for 6-months.  

In waterfall the costs of planning are high, the costs of analysis is high, and the cost of change is very high. But by it’s nature waterfall has a clear scope(vision).   The result is that everyone is clear on the priority, the project is protected, no change and no disruption, the scope doesn’t change. Because everyone understands the cost of interruption.

In Agile the upfront cost of planning is low, the upfront cost of analysis is low and the cost of change is relatively low. The result in some cases is that ‘unnecessary’ direction change can be frequent, the project is unprotected because it can adjust, disruption can be frequent, and so the scope regularly changes for sometimes trivial reasons or low priority distractions.

In short we are not comparing apples with apples.  We are comparing focused vision-led waterfall, with an unfocused ad-hoc agile.

In the example above the team had a fairly vague goal to deliver ‘x’ but also support ‘project y’ and deliver small increments of ‘project z’, ‘project w’ and maybe even an update to ‘project v’ too. And that plan was likely to change next week when something else came along. Because of this ‘project x’ was taking far longer than anticipated. so this notion that delivery using waterfall would be quicker has arisen.

But, the problem for me is that it was not the ‘waterfall’ part of the plan that would ensure success, it was the dedicated resources and clear vision that were the crucial aspects.  Give me a clear vision and those same dedicated resources and I can be pretty sure that I would deliver what the customer wants, sooner, cheaper and more reliably using Scrum than someone else could using waterfall.

Agile is the victim of it’s own agility, it is like the free gift no one values.  Because there is less pain in changing direction in agile projects, and because the team can adjust and adapt, that doesn’t make it free and it doesn’t mean it isn’t disruptive.

Agile enables you to have flexibility in planning, it allows deferring decisions, it allows planning only small amounts, and allows changes in direction and content.  But just because you can do these things doesn’t mean you always should.

A single vision with dedicated resources is a powerful combination, Agile is a powerful tool, but as they say with great power comes great responsibility.

Agile enables you to vary the scope of your vision, to respond to change, it is not a licence to operate without a vision.

As the Japanese proverb goes:

Vision without action is a daydream.  Action without vision is a nightmare.

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.

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.

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.