How often have you seen an organisation push teams to deliver software by an impossible deadline? For example, I worked on a programme of work with an 18-month deadline that everyone knew was impossible to meet. However, when I spoke to those in management, they were confident they would be able to negotiate what they needed regarding extensions and other such things.
Management was so confident they only needed to be close to the deadline that they decided to put the programme forward as an early agile adoption candidate. They weren’t going to meet the deadline by doing things in a poor quality way or by avoiding the learning curve of how to work differently, so why not try to do it as well as possible, even if that meant the added pain of learning how to do it differently?
I thought this to be an incredibly courageous decision. So often, I’ve seen people argue they have too much to do to be able to slow down now, even if it meant they’d be faster in six months and, therefore, ahead in a year. I’m too busy to slow down is such a disappointment to hear as a change agent. I’ve lost count of how many offices I’ve sat in, watching people push the necessary pain of change off for a year because, somehow, the pain of working in their current methodology is better. They would instead create something of poor quality that will cost them more time and the business more money to repair, maintain, and ultimately replace.
I wonder how to engage with more managers and support them in exhibiting this courage. The knowledge that a deadline can’t be made is not uncommon, but the acceptance that a deadline can’t be met and so the quality of the work should suffer in some vein, and hopeless attempt to bring it in by the deadline has been far more common in my life than I would have liked.
I’m so glad to have seen the right thing done once.
I have always encountered so much resistance to any suggestion of slowing down. It might even be the MOST resistance. Stop. Take a breath. If you write the Epic or the Story following a proper format, it will reward you down the road. It is the old chestnut, "measure twice, cut once." Taking the time to write good stories will most likely shine a light on those areas the Product Owner or the stakeholders did not anticipate.