“Not Really Agile” - Planning and Velocity Management in Enterprises

If you haven’t read my previous post on Directionless Agile and can spare 5 mins, I would suggest having a quick read, as this section is going to build a lot on the previous ideas. For those of you who don’t have time… here is the 20 second catch up:

Large Enterprises tend to not fully follow Agile practices to take place, and can sometimes fail to prioritise effectively with the use of a Product Owner role. This can be caused by lack of organisational buy-in or lack of authorisation given to that Product Owner.

What I want to deal with in this blog is another symptom of Directionless Agile:  lack of skill with Velocity management. In cases where enterprises reprioritise regularly or where senior stakeholders come in with late requests, I have had to adapt an Agile way of working into a more hybrid approach, in order to ensure I protected the benefits of Agile without falling back into the traditional methodologies.

Another reason for creating this hybrid approach was through my experience working in Agile programmes or teams that are dependent on other non-Agile teams and projects. This can really scupper your development timelines. For example, if your iteration is 2 weeks long and the dependent team either has to raise changes or has preexisting processes that can take 4-6 weeks to complete, the result is a feature being deferred up to 4 sprints down the line.

In order to solve these problems I came up with the four following techniques: which I will expand upon in this blog:

  1. Understand your velocity
  2. Leave breathing space
  3. Under-promise, over-deliver
  4. Have a backup plan for blockers

*caveat: I know this is not best practice, but is a practical example of how I have overcome problems with Agile adoption in order to keep momentum going. I believe that some adoption and forward movement is better than none. I advise you follow this if your find these problems, but always have a future plan to get Agile coaches into the organisation, aiming to move away from these hybrid practices as soon as possible.


Understand Your Velocity

When working in an Agile manner it is important to understand the number of story points that both individuals and the team as a whole are delivering, as it allows you to plan with more confidence when features will be delivered. Knowing that on average every Sprint or Iteration you close 130 points and the maximum you closed in the past was 170 and the minimum was 100, gives you the confidence to know how many stories you should plan for each sprint iteration. It can also aid with prioritising what goes into a sprint backlog prior to the development team doing sprint planning. There is no point putting 1000 points in one sprint to be discussed if your team could only ever get through ⅕ of it. It is far more efficient to plan only 200 points, and a far better use of time.


Leave Breathing Space

When managing sprints in an agile enterprise environment you’ll inevitably face last minute requests that cause disruption. I’ve found that sometimes it is better to put less into the Sprint Backlog, and instead leave velocity breathing space for last minute requests. (Yes I know this is an anti-pattern but bear with me!). Previously I have worked on a rough 80:20 rule where we only allocated 80% of the capacity of the team and allowed 20% to remain free for last minute ad hoc requests. Although this is not really following Agile, I have found this very effective if you’re struggling to prioritise and you need to protect the sprint goal and the majority of the sprint development. This 20% buffer allowed the team to respond in a more task-driven or Kanban nature, closing high priority items that occur at the last minute with little distraction from the core goal. This links closely with the next topic …


Under-promise, Over-deliver

By only allocating 80% of the sprint backlog and leaving 20% free, you have space to over-deliver. Without this in our back pocket, the lack of direction on the programme could mean that the team continually failed to meet expectations. Although I do not recommend you do this all the time, it can be a useful trick for a team that is running in an environment where there is a  lack of prioritisation. If this is not the case, then I’d usually always advise being fully transparent and forecasting as close to 100% as possible – of course, this will tend to come with time and experience. I also want to note that I am not proposing you hide or are non-transparent if you adopt this approach. In the case where this worked successfully for me, the customer and wider stakeholders were all aware that we only planned up to 80% of our sprint backlog, but they always knew we would work to our best – be that through adding additional value to existing stories or closing last minute requests, and they completely bought into this approach. This is also particularly helpful in a devops environment when you are also responsible for the operational run of the product (I feel another blog post coming on … ).


Have a backup plan for Blockers

Lastly, a point I elluded to at the beginning of this post, sometimes when you are dependent on other non-Agile teams your iteration of development can be delayed massively. In my experience this normally comes down to one of a few areas, but in Cloud Development it’s normally either networks or access that tend to be blockers. They take time and require approvals that can take longer than the development iteration. In this case having backup plans can be highly advantageous.

I will walk you through a standard situation where developer X is given a story, starts their development locally, gets 20% through the story, pushes it to test in a new environment. They then find out either that the test fails because of a lack of privilege to the environment or, often, that this development requires to communicate on a new port or different network address than the one it has been allowed on before. If the access or network is not controlled by the programme, then these blockers can take more than a day to resolve and sometimes weeks once the correct paperwork is submitted.

Here the developer is blocked for the lifetime of the development iteration and cannot close this goal. As a result, to ensure that the team is still adding value, having a list of pre-refined lower business value stories which can be pulled into the sprint ensures that the team is still working efficiently. Obviously the team member should focus on ensuring the rest of the work agreed in the sprint is closed first but, if this occurs across a few team members, having a backup plan and list of stories can be very effective.

So, in conclusion, if your Agile programme is struggling to work in an Agile manner and you’re thinking of giving up and going back to traditional delivery, then why not try these 4 points to keep the momentum going? They could mean you release some value whilst you work with Agile coaches in your organisation to remove the larger impediments. 

All of these suggestions came as retrospective suggestions from the team to help improve the ways of working, and I thought I would share them with you. Whilst this is not a purist view of Agile, its practicalities allow you to blur delivery to ensure success and value are achieved.