Panic mode - early detection is key
Developing mindfulness for early signs of panic
Panic's never helped anyone
It’s kind of instinctive: you’re late for an important meeting, so you go about your business like a madmen, making it in time, only to find out you forgot your all-important notes. It happens all the time and never pays off. You may have saved a few minutes, but ended up with an end-result far worse: you propbably have to redo the whole thing.
Haste makes waste
In software or any work situation, this stuff happens. Outside pressure to deliver faster, can cause a panic mode to engage. Not always literal panic, but a feeling of stress or slight overburden. Wether it’s you personally or a project as a whole, it should be detected and stopped as early as possible. Why? Because it’s damaging.
- It’s bad for morale and personal wellbeing.
- It causes sub-optimal decision making: ‘we’ll document this later’ or ‘I’ll hack this part for now’
- Which leads to greater costs in the end. Having to meet again to finalize decisions, having to rewrite software which is made more difficult by accumulated technical debt.
This shouldn’t surprise anyone. However, that feeling still manages to rear it’s ugly head. It’s not full blown panic, but that uneasy feeling of inconstructive pressure, that fosters bad decisionmaking. That moment you let the quality just slide a little bit, just to ‘be done with it’.
But there's always pressure..
Yes there is! So, a different perspective is needed. Looking at Scrum:
- Quality is non-negotiable. When panic or pressure builds, negotiate scope.
- Teams should work in joyous steadfastness. The sports-team analogy works well once more: keep working together to reach the common goal, with a desire to win the game. Keep doing what you do, don’t send the goalie halfway up the field when the match has a quarter of time left.