Avoid Fires and Stop Meaningless Process Destroying your Intent

Published in

Serious Scrum

5 min readMay 9, 2019

The frameworks and processes we use should support the work we do and help us reach our goals. Sometimes they get out of hand and actually hinder us. The good news is there are ways to stop this.

Have you seen this poster before?

It highlights a well defined low level process which goes against the greater good. It’s powerful in its simplicity but also in its misdirection. Losing code is bad. Messing about with your computer when the building is on fire and risking your life is a lot worse!

Luckily real fires are extremely rare, but having to fire fight project problems is extremely common. When you’re under pressure you need the right frameworks and processes to support you. Where is your focus when customers are demanding last minute changes and there are technical bugs? On the real issues or on a technicality of a process?

Both of these examples provide humour but I also see them as an extreme example of a danger lurking in our daily work. The question we should be asking ourselves often is: “Is this process supporting our goal?”

Having processes can aid communication, help provide structure to avoid short term thinking and avoid us constantly reinventing the wheel.

We can reuse knowledge from best practices, saving us time and improving quality. However, we should be careful we don’t get dragged into a meaningless process which doesn’t add value. We should not implement best practice in the wrong context. Instead depending on context we should adapt it as required for the specific needs.

Agile to the rescue

Providing context and focus there’s often a split between the high-level mindset needed and the lower level implementation. The original aims of Agile were summarised in the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
— The Agile Manifesto

This was knowingly written at a high level and abstractly. It has been made concrete and more specific in different forms eg Scrum. As teams scale, there is even more complexity which has resulted in yet more approaches. Serious Scrum has a great overview of 6 of the leading scaled agile approaches here.

I recently completed the two day SAFe (Scaled Agile Framework) course. This requires two days and going through 300+ pages of course material. There is strict version control and the trainer is required to go through all of the specified slides, no changes or variations are allowed. This is good for consistency and I’m fully behind most of the concepts that were discussed.

Over the top?

On the other hand that’s a lot of processes and structure to create. Is it really adding value?

Cameron Hendy sums it up in his article “Agile and the Software Industry’s Ideology Problem”:

The great irony of this perversion is that Agile was intended as a means to free the average software employee from the tyranny of micromanagement and unnecessary bureaucratic oversight — instead, the very essence of the ideology itself has been co-opted and become something unrecognizable to those who conceived it.

The foundation of Scrum is based on Transparency, Inspect and Adaption. This has been extended and formalised by various certifications programs. While training is critical for the foundation, I think real world project experience is far more important.

It would be very easy to be overawed with the SAFe’s 300+ pages. But given the complexity of large enterprises the details can be extremely helpful. To avoid getting lost in the detail, a strength of SAFe is the way they explain their mindset through their “House of Lean”

SAFe’s House of Lean and Scrum’s “Transparency, Inspect and Adaption” are great reminders. They provide you with a shortcut. A few key words to remind you what your mindset should be when you’re following these frameworks.

Recommendations

Don’t mess about in the details when the building is on fire
Don’t forget, many companies and individuals have been through these problems before, reusing their ideas will save you time and stop you re-inventing the wheel. Adapt the best practice for your specific situation.
Frameworks can add bureaucracy but the standardisation helps bring a shared understanding, alignment and consistency.
Cut unnecessary bureaucracy
My advice is go back to the mindset that summarises these frameworks. If you keep this at the forefront then you should be able to get the benefits without unnecessary bureaucracy

The question you need to be asking is “Is this process supporting the greater good?”

Originally published by Chris Rowe at leadtechie.com on May 9, 2019.