So I am probably going to get a lot of gripes for this one, as we all know that agile is about reducing process and bureaucracy. But for all you cynics out there bare with me…

We do all need some kinds of processes to ensure a project works well, whether it is as simple as having a userstory signed off by the Product Owner, to having items fully tested and going through the correct CI and deployment processes. These steps are key and if you start to get slack on them then you very quickly get into a bit of a muddle.

The whole point of project managers and scrum masters is to ensure delivery of a product through the methods and processes they have at their disposal. Why is it then that I have seen time and time again, people from all areas of a business, come to the same conclusion…

“We need this project done quickly so we’ll not worry about following our usual rules”

or my favourite…

“We don’t have time for a retrospective because the project is running over, we just need more time at our desks”

Why do people chuck away the rule book if they are on a tight deadline?

Firstly this tends to be human nature. We cut corners, reduce quality and ignore some of the ‘nice to haves’ that we think we can live without. Unfortunately, in the project world, the rules and activities that hold the project together are often seen as nice to haves.

But why is this? In a lot of circumstances this may be a sign that the processes aren’t completely necessary and in this case the team need to get together and agree a new set of rules that are not so overbearing. But in a lot of cases these things are essential – without sign-off from the PO we may start producing work that has no value, without retrospectives we can’t look at what’s going wrong and improve. The list goes on.

Fundamentally, we need a change in thinking towards the agile framework when it comes to business stakeholders and team members. The idea may be that it is light-weight but it is there deliberately. The rules, meetings and processes we have in place should only be there to allow for the most efficient delivery of a product. If they are necessary when the project is going well, then they are definitely necessary when the project isn’t. If they aren’t needed when the project is going badly then ask the question – why are you using them at all?