“Deliver a stable product. With shiny new features. In half the time."

  • “How do we deliver this before our competitor?”

  • “Good project plan. Can you just deliver it three months earlier?”

  • “Can’t you make your team five times faster/more efficient?”

How many times has a manager or stakeholder asked you one of these questions? Personally, I have lost count. Now, how do you answer them? Well, I tend to come back to the “Quality, Cost, Time” triangle:

I find myself thinking, pick two and I will tell you what the third will be. This sounds so simple in project management textbooks or discussions in the pub. The only problem is stakeholders and toddlers share a trait of being irrational in their demands, so we are still asked to deliver all three.

The solution when I started my career (more years ago than I care to admit) was very straightforward. Projects were long (think one to two years). This meant you could predict that one or two months a year would have a big crunch and the team would be asked to work evenings and weekends with the promise of time off in lieu, bonuses, etc.

If we consider the effort the team needs to put in over a two-year period, it looks something like this, with ‘Time’ on the x-axis and ‘Effort’ on the y-axis:

IMG_1118.jpg

Enter Agile, Continuous Integration and Continuous Delivery. As businesses shifted away from long projects with long release cycles to more agile project management techniques, the stakeholders expected releases more often, e.g. once a month. Now, we can’t ask our team to work extra hours every time there is a release—they will burn out. The effort graph for this scenario looks something like this:

IMG_1119.jpg

Of course, many of the agile methodologies talk about the team working at a continuous, sustainable throughput. So burnout shouldn’t happen. But here is the secret so few seem willing to admit: companies tend not to implement all of the agile principles!

So the time is fixed; the cost is fixed—what do we do next? We start to compromise on quality. We don’t do as much automation as we would like. We cut out low-priority testing (maybe this is exploratory testing, security testing, or non-functional testing). This is what happens when you take your great software engineering team and don’t give them enough time to focus on quality.

So far, I have painted a pretty bleak picture about how we have tried working harder to allow our stakeholders to ignore the fact that they can only have two out of Quality, Cost and Time. But it can be possible to meet all three—quite simply, we need to work smarter. Automation in testing has been designed to allow us to work smarter and let the humans focus on the work that requires their unique skills, like exploratory testing, while the computers do the repetitive testing.

There have been many developments to support running tests, measuring results and understanding how failures are introduced. However, none has reduced the cost of creating the automated tests—at least until now. Diffblue Cover will automatically generate the unit tests for you. This means that you can generate a suite of unit tests more cheaply and quicker than traditional methods. Don’t believe me? Then check out our Playground, or request a demo. You can also ask questions of your own at our CrowdChat with Diffblue’s CEO, Professor Daniel Kroening, this May 15th. Click here to add it to your calendar.

But, ssshhh—don’t tell your stakeholders your secret. Take a break, finish that training course you’ve been wanting to do, or focus on your more interesting work. Remember, if you tell your stakeholder, the punishment for doing good work is to be given more!