Since Agile is flexible and adaptable, long-term deadlines don’t immediately fit into Agile and it was once said to me by a Product Owner that 'in agile there are no deadlines'. Baffled by this I thought 'of course there is, Sprints are time boxed and the Sprint Plan has a set amount of time dedicated to it'.

Bearing in mind that the product owned by this PO had frequent issues I found it no surprise by what I was hearing but I should have reminded myself that in agile, the focus is on short-term pace. It’s not about delivery by a certain date far in the future to meet a long term goal, it’s about achieving a certain outcome.

Long term goals also have midterm goals and these are the outcomes we work toward, looking to eventually get to where we want to be in the long term, but also equally happy to be somewhere else as long it is the 'right thing'.

This does not preclude the possibility of long term planning though in order to achieve a particular outcome. Estimation of tasks, pace sustainability and predictability of velocity are what allow us to predict completion and to meet known, long term objectives, or at least to adapt an approach in order to try and meet a date and most salient feature set passed down from above.

We even have Burn Up charts to help predict when we will finish. The blue line shows total work to be done and the red is the 'burn up' as work is completed. If it looks like work can't be completed by a certain date then it's time to  negotiate the scope.

Is agile failing long term business planning or is top down planning failing the business?

We are all accustomed to the diktats that come from above and we are all equally accustomed to projects not quite being delivered on the date that was set 12 months earlier.

Agile development works but there is a worry that it is failing to meet expectations in larger organisations, and is often failing because long term planning conflicts with the notion of lean, and that planning so far in the future is wasteful because the business climate will often change.

Major capital outlays are decided typically six to twelve months in advance and a business case may have been built in the previous financial year. Planning for up to a year in the future is not a time frame that fits the agile approach.

If a plan is built for the following year, who is to say that what was relevant in May will still be relevant when the new year begins? A static environment does not exist.

So how do you get the benefit from strategic planning while maintaining agility?

Planning should be more dynamic, at least quarterly, and is often seen monthly in steering committees. One way to be dynamic is through looking at various options. If option A is not successful, then ensure that option B is executed.

Planning should be framed by the project or organisation's vision and every thing that is planned, every change in the business climate, every new opportunity, should be referenced to the vision. I do not believe this to be unusual. Change is handed down all the time.

Away from the grand strategic planning at C-suite though, at the actual delivery level of writing software, changing tack always happens either by design, or to try and meet a date. This is where the the conflict between strategic planning and software delivery occurs.

By being agile, we need to understanding what is actually important in what we want to build at any point in the delivery i.e. reference to the vision, and by understanding velocity, change can happen incrementally while still building towards the vision or date. This is what the strategic planners need to accept.

How can we implement an Agile process when the project is either fixed bid and/or fixed schedule, with a set list of user stories to implement?

It's fantasy to think that a project can be completed in a fixed time with a fixed set of stories to deliver. We often try to do this but realise that something has to give.

By understanding the vision, what is important in what we want to build, and how fast we are building, we can always build what is most valuable. We will also know whether or not the deadlines will be met - hence why a Burnup Chart is so useful. If they can't be met, then the team should negotiate what the team or product needs to be successful.

However, if the Product Owner has been continually ordering the user stories according business importance, the team will have been working on the most valuable items first. According to the 80/20 rule (Pareto principle that 80% of a certain piece of software can be written in 20% of the total time allocated), there may be no need to work on the remaining 20% anyway. Late delivery? Actually it may be an early delivery if the least valuable work is no longer regarded as being needed.

In Scrum, three attributes are fixed:

• Time is set by sprint length.
• Cost is set by the Scrum Team
• Quality is set by complying with the Definition of Done

The last attribute is variable:

• Scope is based upon the velocity and business value of the Product Backlog Items. This will decide what will actually be delivered. By changing the scope of a sprint we can move towards the most important elements that bring us closer to the strategic objectives.