Hard deadlines

“This date must do it, no exceptions.”

Who has heard that before? Ok, you can put your hands down.

In over my 25 years in technology, I should have put a dollar away every time I heard it. I would be nowhere near retirement, but I could buy myself something beautiful.

I finished reading Jeff Sutherland’s book “Scrum: The art of doing twice the work in half the time.” The stories he has in there are amazing. Sometimes people will decide without all the information and get caught. Publicly announcing deadlines will paint you into a corner.

It happens, though, and it is not a bad thing. Sometimes there are things at play where there is no choice to avoid a specific time. Technology in Healthcare is a great example. There are compliance and codes that need to be in a system by a particular date. So here it isn’t someone in a company painting product, development and QA teams into a corner; it is an outside entity, and they don’t care about constraints.

So for the two scenarios I listed above, I will talk about the second one; first, it’s easy. Complete it by this date, no exceptions. Here the team should have enough time and planning done so that they are prepared to get to the finish line without issue. Unless you are new to the market, something like this is very predictable and knowing the team’s velocity and the amount of work needed from past updates, and it should be a cakewalk.

With that said, “s*** happens,” and a wrench could come in to keep things exciting. If and when it does happen, my best advice is to remain calm, assess and plan. We are in an age of Agility, so everyone getting together to meet the challenge will make them successful.

Now the big issue, self-imposed (company) deadlines. For the most part, with proper planning, estimating and understanding of a team’s velocity, creating a timeline without much issue is straightforward. It is when one or more of those things at risk is when dates are in jeopardy. Regardless of the SDLC methodology, Testing will feel the brunt of the stress to get it done. The trick is getting past this obstacle.

Work overtime? Yes, and it will burn out your resources. As well as not guarantee the work will effectively complete since they will be close to, if not already burnt out.

Throw more resources at it? Have you read The Mythical Man-Month? Putting more resources on a project does not mean increased speed. The best example is a pregnancy; adding more pregnant women will not produce a child faster.  That is not to say it will work, adding resources to the testing effort, not the pregnancy, it is going to add up to more work involved in coordination and ensuring there is no duplication of effort.

Replan and scope change? Having a clear understanding of what is needed and in an iterative environment look at all the work that is left and clearly define what needs to be done to meet expectations and what is a nice to have (or next release). Helping with that is one of the primary advantages of using Scrum. It can work in other methodologies; it is going to be a little more painful in going through all the work that has been done and not done as well as any interdependence between half-done code.

Risk-based testing? Yay, I finally said it. I know you were all waiting for it. Yes, Risk-Based testing has been around for a while, and it is a straightforward concept. Identify what areas have a high probability and high impact of failure or calls to support if it were to fail, then test that. From there, you start to limit the amount of testing that is needed.

There are a couple of other things.

1 – A ranked set of test cases based on importance.

An example would be test cases involving financial transactions that should take higher priority to how a GUI button.

2 – It gives the stakeholders transparency for validation and not.

Here collaboration is key. Everyone needs to know what is going, so preparation for potential customer calls on stuff that not validated.

Then comes the worst-case scenario: telling senior management it just cannot be done. I have had those conversations. In the end, all you are doing is stating the facts. Notifying of all that has gone on and with the time that is left, expectations need to change. To me, as long as you provide the right data with the message, it should be understood that the efforts are there, it just cannot be done.

Yeah, the leadership will be upset, same with any other stakeholder. In the end, it will pass. New dates will come up because the team worked collaboratively and figured out the most efficient way to get the work done and are more confident in any modern times they provide.

The best thing in these situations is to have things in place to track and measure. I’m not saying a Gantt chart, as stated in the book mentioned above, they don’t work. Remaining velocity, amount of work left, burn down, stuff like that can give you a good idea of where you are going to end up. With this information, you should be able to see potential train wrecks well in advance, and the team can work together to avoid it. If the debris is going to happen, no matter what, don’t hide the issue. Better to let people know as soon as you know so they can be prepared and work on making informed decisions.