Metrics

"There are lies, damn lies and metrics"

This article is the first of several that will take a look at and start a conversation around metrics in Agile. in particular, this article will look at estimating in Agile. 

What are Metrics?
Metrics are statistics. Metrics are a graphical or tabular representation of a real world  phenomena, typically over a period of time, showing ups and downs of whatever it is is being measured.

In the right hands:

• Metrics should help every stakeholder easily readily understand the health/trend of what's going on.
• Metrics act as the trigger to a chain of positive conversations about what to do next.
• Metrics act as the impetus for decisions that improve everyone's working lives, practices, productivity, business-value and ultimately our products for the better.
• Metrics are met with anticipation, not dread. People look forward to them! 
• Metrics underpin the driver behind continuous improvement

In the wrong hands:

• Metrics are used to measure the less important or even the wrong things
• Metrics may even measure the right thing but in the wrong way
• Metrics are used to apportion blame and as a stick to beat people/teams with.
• Metrics if presented in isolation of other relevant metrics, can present a skewed vision of the true reality of what is or should be measured
• Metrics can be used to advance a personal or political agenda as opposed to being a radiator of truth
• All the above can lead to the wrong decisions being made or the right decisions not being made. It's not necessary to describe the harm all the above can to do businesses, products, teams, morale, quality, profitability, corporate reputation and the individuals involved at all stages.

The Metrics that Matter

In Formula One racing, live telemetrics from every part of the car are monitored in real time which drive decisions to improve performance, ranging from the driver behaviour/activity during the race to how pit-stop activities are timed/conducted to car/engine design improvements for future races. 

Only the metrics that matter are used. Each metric is transmitted/presented to the right people at the right time who then use that data to make the right decisions that improve all aspects of the car and performance.

Such metrics serve to improve the product in the widest possible sense (the car, the performance, the team, the sport, the industry) and is the springboard for designers, mechanics, engineers and drivers to improve their skills and be part of an upward success story that they're all proud to be part off.

So why are metrics such a bone of contention in many domains in IT?

Measuring the Wrong Things - Not Measuring the Right Things
It's easy to measure mechanical performance of widgets and engines but not so much in the field of technological creativity and the less than tangible aspects of added business value.

This next article will focus on estimates & budgeting in Agile, probably most poorly understood and most poorly applied metric of them all.

What is your experience of metrics?
Who asks for them and why?
Have you experienced where they add value?
Have you experienced when they make not a jot of difference?
Are there metrics you'd recommend?
Have you see metrics being used to make decisions (good and bad)? If so, tell us your story!

Dependencies: Impact to Backlog Prioritisation and Delivery

Let me begin by saying that dependencies between Stories is not a bad thing when they all live within the same Product Backlog.

But what if we have dependencies on teams/people who are outside our Product teams where such work resides outside our Product Backlog?

Imagine we are preparing an elaborate meal (our product)  this evening for a special occasion and we've all the ingredients in our larders/store cupboards but we're missing a few things. So we go to the local store only to find they dont have it in stock. They may order it in but it wont arrive for another few days.

• Perhaps we didn't plan adequately ahead of time
• If the occasion was suddenly thrust upon us (an immediate business opportunity that arose today), then we had to act upon it only to find we dont have 100% of what we need to exploit that opportunity in full
• We need to rethink what we plan to prepare and cook only those courses we have ingredients for
• Perhaps we can prepare the entire email as planned but without the missing ingredients if they're not that vital to the dish (our Minimal Viable Product! MVP) 
• Improvise with what we have.
• Or in extreme circumstances, if the ingredients are so fundamental, then we may need to cancel the event or subcontract to a caterer (a vendor) who can fulfils our needs but at great cost

The same kind of thing happens in software delivery. When we have dependencies on external actors (be it vendors or teams/people outside our product teams) then we are at risk of the following:

• Business Value is at risk of not being delivered to market as soon as we'd like
• We are dependant on external-actors over whom we have no control or influence over (I'll come back to this later...)
• By the time the external-actors have delivered, are our Stories that depend on them still business-relevant? Has the lag time decayed their market/customer impact? We may have missed a strategic window of opportunity.
• Stories are de-prioritised while we waiting on the other teams to deliver their bit.
• Little control/influence over how the work we depend on is prioritised within those external teams.
• Little control/influence over the quality of the work that external actors deliver
• The risk of inter-team acrimony can arise where we set expectations that we need our external partners to deliver by a certain date only to be told that they can't deliver by that date due to their own priorities. If this is mishandled, it could sow baleful seeds of bad-blood and poor working relationships which in turn harms our common business and aims both in the short and long term.

Consequences of Reprioritisation
When we are forced to de-prioritise what should have been a high priority Story due to external dependencies, it means we have to give higher priority to a less business-value-adding Story just to keep our teams busy.

Ok, we still have work to be getting on with but it means that we are forced or tempted to release code to our customers which may be premature or not that value-adding to them or our business.

Root Causes
Why can't we do this work within our product teams?

Some common causes (there could well be others):

• Organisational Structure

• If organisations are not truly restructured along product lines, then the above situation will be run into time and time again.

• Organisations need to examine their departmental structures and seriously consider restructuring to minimising the exposure to inter-application/team dependences which only serve to slow business delivery down and lower morale of all concerned

• Lack of Cross-Functionality/Training

• Perhaps this is work we can do within our teams but we haven't considered retraining our people to be T-shaped so that when such work is needed, we can't do it internally within our teams. IF we did, we would have maximum control over the destiny of our product and what we deliver and when.

Transformational Opportunities

Transformation should always start from the top of an organisation. 

Often, the way orgs are structured are a legacy from the pre-Agile world and there's an onus and responsibility for us all to plan a considered and respectful case to those who are in charge of organisation structure where:

• We provide evidence and case studies where current organisation structures are acting against the interests of the business (slower time to market, time spent in coordinating initiatives across teams which could have been avoided etc)
• We provide alternative structures that will reduce or eliminate as much unnecessary dependencies as possible
• We provide a list of re-skilling/retraining opportunities across the org so as to help product teams be as technically self sufficient as possible

So, Fellow Agilist...

• Have you experienced any of the above?
• Have you helped bring about positive change?
• Do you agree, or disagree? If the latter, that's fine but tell us why?
• Are there any other ways this can be addressed?

We want to hear from you 

Post Zero

Welcome!

I've set up this blog as a space where we can discuss all aspects of Agile transformation, how to approach it,  involving case studies, personal experiences, examples of transformation in action (and examples of transformation inaction :-) , articles, knowledge sharing and general advice to help our community members with the chalelnges we all face on any sphere of Agile adoption, practice and transformation be it at the team level, Agile Release Train level or organisational.

We're all here to learn from one another. Even though I set up this blog, this blog belongs to all who visit it. Consider this a park bench where we all drop by, stay a while, sometimes  brief, sometimes longer and talk about the things on our minds so that we learn and grow on the never end journey that is Agile.

I know many other blogs exist out there and that's great but there's always room in the public square for another market stall.

Let me emphasise that I'm not an expert or a sage-on-a-stage or anything like that. I know a good bit yes but so do we all. I'm not going to use this blog as a personal vanity project or a finger-wagging forum for putting the world to rights.

Collaboration is the name of the game so let's start as we mean to go on!

Story Description
Setting up a positive blog experience for all who visit and read it

Acceptance Criteria
Given opening the blog
When you post an article
Then thank you for being a contributor

Given perusing the blog
When you read an article
Then you will have learned something useful

Given contributing to the blog
When engaging with one another
Than thank you for being collaborative

Given when someone is hot tempered
When they post abusive comments
Then they and their posts will be moderated or in extremis, removed

So Why is the Post named Sprint Zero?
It's a word play on the Sprint Zero concept. 
Sprint Zero is the preparatory time period where teams get ready for Agile delivery. This can last as long as the teams needs but typically, anywhere between 2-5 weeks. 

During Sprint Zero:

• Teams are formed
• Agile training is given
• Workshops are held
• Ceremonies are practiced
• Product Backlog is populated 
• Estimation technique is agreed
• Team agreement is formed
• Definition of Ready/Done are agreed
• Sprint length is agreed.
• Date for Sprint 1 to formally start is agreed

There is a lot of material online about Sprint Zero and the do's and don'ts but here's a good place as any to start: https://manifesto.co.uk/scrum-practice-sprint-zero/