Archives

Do you have a real deadline?

Do not cross the lineThe first written record on the use of the word “deadline” was in 1864.  It was a the term to describe the line over which prisoners were forbidden to go –
Along the interior of the stockade, 19 feet from the stockade wall, was a line of small wooden posts with a wood rail on top. This was the “deadline”. Any prisoner who crossed the deadline could be shot by guards stationed in the sentry boxes. [1]
The words are quite literal – a line where it will make you dead.
Not all deadlines are bad.  But we must be careful on how often we impose them and for what purpose.  Many deadlines are largely unwarranted and generally harmful.
Deadlines can provide a sense of urgency and focus.  Goals without deadlines are dreams, so deadlines can reduce the amount of procrastination and avoid Parkinson’s Law.  And when deadlines are self-imposed, it can challenge us to get stuff done – there is a sense of achievement on getting a job done in record time.  Deadlines used with the right mindset can help teams really focus on what is important and what isn’t.  With the right mindset, it facilitates bias towards action and help us prioritise so we are doing the important things for the customer and help identify wasteful (corporate) activities so we can improve and eliminate.
When used judiciously, deadlines can get an important piece of work over the line as it focus teams on production.  However, if this is forcing the pace of work that causes burnout, bad things start to happen.  Agile processes promote sustainable development
“The sponsors, developers, and users should be able to maintain a constant pace indefinitely” – Agile Manifesto.
Deadlines used as an extrinsic motivator and holding a threat for unclear purposes is dangerous to our modern way of working as it imposes fear.
In a complex environment we do not know and cannot predict what will happen when we do action ‘ABC’ and there are many possible actions that we could do.  So when promises of dates are made early on, it causes a ripple effect as people will start setting deadlines off your deadline and it becomes self-reinforcing.  As a result of this you remove a lot of options for adaptation and unexpected events.
There are deadlines that have a “real” business impact or have an actual business consequence for failing to meet the deadline.  For instance, meeting an regulatory reporting requirement (eg APRA in the Australian Financial Industry, or Sarbanes-Oxley)  or studying for an exam.  There is little value in finishing something for an event (eg trade show) or holiday special (Mother’s Day) after the event.  The “Y2K Bug” is also another example of a real deadline.  Anything where the value of completing the work drops significantly or disappears altogether is a real deadline.  If the work is still mostly valuable if you get it done after the deadline, you probably have an arbitrary or “perceived” deadline pretending to be a “real” deadline.
A genuine deadline tells you “If we don’t get done by the deadline, there’s not much reason to get it done at all and we should stop”.  These type of deadlines, whilst are valid, they are actually not that common.
“Perceived” deadlines are actually the most common. There is a very significant difference between real deadlines and perceived deadlines.  Perceived deadlines tend to arise from questions like “How long do you think this will take?” or “Do you think we could have this by [date]?”.  They exist to keep work (eg a project) from going on indefinitely and create an arbitrary line in the sand where people can expect delivery.
Often these deadlines are a result of setting expectations, often very early on based on long-term or coarse grained estimates, and estimates of that sort are never accurate.  We are bad estimating – experience and scientifically it has been repeatedly shown that getting accurate estimates is extremely difficult, if not impossible.
The real problem with deadlines, is that any deadline longer than a day or two you are asking people to fail.  What you are really measuring with deadlines is the ability to estimate. If you are trying to convince people to get something by a deadline, the only way they could get something done by a deadline is by getting better and better at estimating.  This is something you cannot do, even with experience.  [2]
In a complex world where you can’t predict the future of doing ‘ABC’ you are constantly punishing people for something they can’t get better at.
Deadlines based on annual budgeting and financial cycles is also a type of perceived deadline.  Teams working towards nominal end date (or start date) that aligns with the financial year is also nonsensical as customers do not operate (and don’t really care) when you make your investments and how you fund and capitalise work.
The best way to determine if you have a perceived deadline is to ask the question, “What will happen if we miss this deadline?”  If the answer is mainly, “people will be disappointed”, “someone promised that date to the market” or “we already announced that date” then you probably have an arbitrary deadline with no actual business impact on it.  Many of these deadlines are actually wishful thinking or commitments made on behalf of others doing the work based on theoretical plans and no evidence of actual production work.  There is little surprise why we have missed expectations and the ensuing conflict and confusion on why things never get done “on time”, why the quality of the product isn’t better and why we don’t have time to improve.
These perceived deadlines tend to cause undue stress on teams for no particularly good reason.  This creates short-term thinking and approaches aimed at getting across a finish line with little sense of what comes afterwards.  Heroics are often required to get things done and the product is sub-optimised as quality is sacrificed as hidden technical debt is accumulated which are rarely quantified or explained.
Jim Benson, author of Personal Kanban, has been credited with the diagram attached – deadlines as influencers of ‘crap’.  Simply put – as your deadline approaches your options are reduced and you choose options to fit the deadline rather than satisfy your customer.
DeadlinesAndCrap
In the novel, The Phoenix Project this common situation was aptly portrayed –
I’ve seen this movie before.  The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers.  Them you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment.  And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.
A much better way to get a predictable timeline is to make projections based off the team’s actual metrics of progress and constantly adapt based on new information.  That’s why agile promote working solution/product (ie shippable state) as a measure of progress.  We need to act our way to the future, rather than plan or guess our way to the future.  We should only commit at the last responsible moment.  Never commit early unless you know why (ie have you got a real deadline such as an “AFL Grand Final moment”).
Not all deadlines are bad but next time before setting a deadline please consider why you are imposing the deadline and what is the real need for that deadline.  Be on the look out for a perceived deadline acting as a real deadline as these will undermine teams with a constant push towards an illusory goal resulting in sub-optimal results, poor customer and business outcomes.  And along the way, hopefully we will reduce the number of times people crossing the deadline being shot.
[1] Reading 1: Andersonville Prison, https://www.nps.gov/nr/twhp/wwwlps/lessons/11andersonville/11facts1.htm
[2] Jabe Bloom, Beyond Deadlines, https://vimeo.com/52255565

DevOps and Continuous Delivery

Last week I attended the Agile Australia Conference. I will post a conference report soon, but thought I would share the 2 main takeaways I had from the conference. One is the DevOps movement and the second is Continuous Delivery.

DevOps is a new movement seeking to achieve the business need for rapid delivery of software products while maintaining the stability of live environments. It uses two approaches: first, promoting closer collaboration between development and operations; second, applying practices shared with agile (collaboration, automation, simplicity, etc) to operations processes such as provisioning, change management, and production monitoring. It encompasses culture, processes, and tools – all supporting better communication, faster feedback and delivery, and more predictable outcomes.

With continuous development of working software, we need to get the changes into Production as quick as possible through Continuous Delivery so we can shorten the feedback cycle and so the business can maximize the ROI.

Managing Defects on Agile Projects

This recent Dilbert comic strip reminded me of a situation when a client was raising cosmetic defect as severity 2.

It is often not clear what a defect is and at what level to raise it at (despite agreed severity descriptions) as my example above shows.  And some defects are raised without being related to a requirement. Or defects raised because of a feature being “not user friendly”.

Regardless of the reason and how you label the ‘defect’, I treat all defects the same – it is a piece of work required by the client that needs to be prioritized with other work. So the approach is to put all work (defect, enhancement, new feature etc) into the product backlog. As part of the planning process, the Product Owner will prioritize the items on the backlog for the next iteration and/or release. So if a cosmetic defect is more important (has greater business value) than a new feature, then it should be placed higher so it gets completed first.

Keeping all work in the product backlog, makes planning simpler and helps manage the flow of work. It also ensures the client is in control and be the judge of what is important to their business.

Bridging IT and business

We sometimes hear that business is not getting value out of IT.  Technology and tools are constantly improving but we often have missed expectations.  The need to align business and IT is getting more important.

Incorrect assumptions of what the client needs often leads to incorrect actions resulting in wasted effort.

Next time you  speak to your customer, clarify what they mean and speak in their language.  Get the customer to provide real life examples and elicit feedback along the way.  That way you will move towards aligning IT with the business and deliver greater value.

%d bloggers like this: