“It must be done by this date, 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 for every time I heard it. I would be nowhere near retirement but I could buy myself something nice.

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 make a decision without all the information and get caught. Publicly announcing deadlines will definitely paint you into a corner.

It happens though and it should never be seen as a bad thing. Sometimes there are things at play that it has to be done by a specific time. Technology in Healthcare is a great example. There are compliance and codes that need to be in a system by a specific 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, it has to be done.

So for the two scenarios I listed above I will talk about the second one first, it’s easy. It has to be done. 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 it should be a cake walk.

With that said, “s*** happens” and a wrench could be thrown in just 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 team’s velocity a deadline can be identified without much issue. It is when one or more of those things are not done is when dates are at risk. Regardless of the SDLC methodology Testing  will feel the brunt of the stress to get it done. The trick is what can be done about it.

Work overtime? Yep, that can be done and it will burn out your resources. As well as not guarantee the work will be effectively done 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 it will be done faster. 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 actually going to add up to more work involved in coordination and ensuring there is no duplication of effort.

Re plan and scope change? This could work. Having a clear understanding 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). This is one of the basic advantages of Agile and use of Scrum. It can be used 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 very simple 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 to be done.

There are a couple of other things that it will give you.

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

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

2 – It gives the stakeholders transparency of what is going to be worked on for validation and what will not.

Here collaboration is key. Everyone needs to know what is going to be done so they can be prepared for potential customer calls on stuff that was not tested.

Then comes the worst case scenario: telling senior management it just cannot be done. I have had those conversations. They seem scary at first, yet in the end all you are doing is stating the facts that with all that has gone on and with the time that is left it is physically impossible to make it. 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 be given, because the team worked collaboratively and figured out the most efficient way to get the work done and are more confident in any new dates they provide.

The best thing that can be done in these situations is have things in place to track and measure. I’m not saying a Gantt chart, as stated in the above mentioned book, they don’t work. Tracking 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 wreck is going to happen, no matter what is done, 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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.