What's the Point?

Anyone who has worked in an agile team will be familiar with the concept of agile pointing, seeing everyone in the team holding up cards and declaring an item of work to be 5 points, 8 points, 13 points....

But why do we estimate like this? Wouldn't it give more certainty to the business if we gave an estimate based on time?

Well we do have our reasons, there is a point to pointing.

I'm Almost Done

People are generally bad at giving absolute estimates, developers will often be overly optimistic about how long something is going to take to code.

We are however much better at relative estimation, we can identify that one piece will require more effort than another and we may even be able to apply some kind of scale, its half as difficult or twice as complicated.

Moving towards this unit-less relative approach concentrates the mind on blockers or issues that are causing this increase in points.

This relative measure will also carry more historical significance, knowing that a similar task took 5 days to complete six months ago has very context in the here and now as the team may have been operating under very different conditions.    

Velocity towards Success

Using points based estimation forces all planning to be based on measuring the teams past performance, what we usually deem their velocity.

This focuses the mind on how the teams performance can be improved and the longer the team work together the more accurate this measure of their performance will become.

Two week sprints always contain two weeks worth of effort from the team, the focus should be on how the amount the team can deliver in that period can be optimised.

Estimating in days can very quickly lead to the flawed mathematics of man days.

A scrum team should be viewed as a team and not a collection of individuals, the team achieve things and this can be made to add up to more than just the number of hours they spend in the office.  

Playing as a Team

A scrum team will very often be made up of a mix of individuals with differing experience, ability and skill sets.

Given this mix the amount of time a task takes an individual in the team may vary but team members are more likely to agree on the relative complexity between different work items.

This focus on relativism helps turn planning sessions into opportunities for education and debate and allow the team to come up with an estimate every member is comfortable with.

Once again adoption of agile requires a certain amount of truth to be swallowed.

Ideally a team would be able to give a precise time based estimate to aid business planning but this will simply never be the case, there are too many variables.

Agile is also about continual improvement, not just of the code but also of the team.

Pointing provokes debate and provides a metric to be optimised, it recognises the fact that individuals can run into problems or miscalculate but a team is stronger and can flourish into an effective code producing machine.   

Scaling the Heights

The production of software is increasingly becoming viewed like any other commodity with unfortunately little inherent value being placed on the code itself.

What this means is that unless your doing something very clever the only way to generate income from a technology business is scale, if your able to offer a service to the masses you can start to leverage some profit from your developers efforts.

Scaleability is a property of a code base in its own right and as such needs its own consideration, it won't just happen you have to anticipate what will happen when this system is getting intensively used and what problems only arise when your product is being used at scale.

Delivering on Your Promises

The first piece of software you drop into the market is only the first step, you can't even see the mountain at this stage let alone start to climb it.

From then on you most deliver consistently on an increasing cadence, not only new features but fixing defects, plugging holes and increasing performance.

The only way to achieve this pipeline is via automation, the days of a prolonged development cycle followed by protracted regression testing are over, someone else will fill the void your leaving before your ready to ship.

If your organisation is putting large amounts of conscious effort into deployment you run the risk of solving yesterdays problem when your software does eventually drop, instead deployment needs to become such a regular occurrence as to become mudane.

Diagnosing the Patient

When you've deployed a system at scale you can't afford to be reactive, you have to proactively monitors its health, by the time users start reporting a problem it has already become detrimental.

Careful thought should be put into what data, statistics and indicators can be drawn from a system.

This process should be entirely data driven, no presumptions should be made about what the data will show or what we want it to show, collect the data and learn the lessons it teaches don't try and force it in a particular direction.

When this data tells us about potential problems or possible improvements we need to factor this into our plans as no matter what we may think is happening that data represents reality. 

Securing the Castle

As your user base grows so does the level of trust those users are putting in your service, and unfortunately your success will bring attention from those that wish to break that trust and separate you from the data you hold.

Its important to realise that this is about more than just securing the data pertaining to the service your offering but protecting the user in general.

Many of your users will being using the same passwords and credentials across multiple services and they won't forgive you being the weak link in the chain that exposes it all.

Security and users privacy must be a consideration in everything you do and its even more important in this aspect that you are proactive and not reactive, waiting until there is a breach is too late.

Many of the things you need to consider when scaling your system are the same as when you first built it they simply scale in proportion to your business. But some problems are unique to a system with an increasing user base.

These are problems we are all striving to have as we aim for success but we do still need to supply answers and anticipate them rather than being caught out by users actually liking what where doing.

The Agile Truth

The adoption of agile can be a difficult experience, I think some of these difficulties come from a reluctance to accept some of the uncomfortable truths agile is trying to teach.

Traditional methodologies, such as waterfall, are built on a premise that the world is slow moving, we can make long term plans, cover every eventuality and anticipate what our users want.

Agile is built for a new world, one that is moving far to fast for us to have any hope that we can keep up. Once we accept this as reality it becomes clear that we need an effective strategy for dealing with failure and change.

The truth of agile is that we must learn to let go of our pretence of control.

The Plan Won't Come Together

A common un-truth spoken about agile is that it doesn't involve planning, this isn't true. The truth is that agile places limits on how long we can realistically expect our plan to hold together.

We've all worked on long waterfall projects where success is often measured on whether we delivered ahead of schedule or under budget, note how these things are often mutually exclusive and have very little to do with the user.

An agile plan is one designed to have a short shelf life with a new revised incarnation on the horizon that will adapt to changing circumstances, the agile truth is that we can't predict the future or control events.

Be First Not Best

In almost any arena of digital products once a vacuum is identified its very often filled with staggering speed and becomes saturated extremely quickly.

While no-one would suggest it's acceptable to ship rubbish, there is a lot to be said for gaining a foothold in a market early and using the real-world experience you gain from your users to drag yourself up the mountain.

Even if initially your only meeting some minimal need your users have becoming part of there existence gives you much more opportunity to learn than trying to second-guess or calculate what their bigger desires may be.

The agile truth is that you probably only have a partial understanding of what your users want, you don't define that they do and you shouldn't believe what they say you should believe what they do.

Failure is the Only Option

What all this should be adding up to is that failure is inevitable, whether we like it or not change we didn't anticipate is coming.

Our only effective strategy is to attempt to limit the scale of the failure and ensure we draw enough information from it to formulate an effective comeback, its better to be in the real world failing then on the drawing board apparently succeeding.

Once we accept that the agile truth is that we will fail its a logical step that we should want to fail fast, redefine failure as an opportunity to learn and re-cast our users as teachers.

The majority of people who are reluctant to accept agile will cling to rose tinted memories of waterfall where they thought they had control over there destiny.

Sometimes its possible to be failing so slowly its almost imperceptible right up to the crushing realisation that things aren't the way you thought they were.

Waterfall is a very tempting narrative that we would all want to be true, that we are in control and we can shape the world around us. The agile truth is that this is a lie, the only element of control we have is in the short term and that our job is to effectively manage failure so out next iteration moves us two steps forward.