Ok, so the Shakespeare reference is perhaps a little dramatic, but when projects head down the ‘Death March’ route, the cries from Stakeholders and Programme team resonate around the artificial message of togetherness as they demand and plead everyone to sign up to additional hours, weekend rotas and commitment to this “career making” opportunity.
As they circle the room, looking for volunteers to see the project over the line “et tu” the unnerving, collective sigh takes over… And reluctantly members from each team are cajoled into delivering to a timeline plucked (in most cases) from the air with no comprehension of whether it is achievable.
And so, we enter the infamous “Death March”
Next on the list is the “war room” where decisions are made on what can and must be delivered, this is also the place where constant updates to progress are made, showing the stakeholders the commitment and “willingness” (et tu) to see the project go live.
Developers are churning out code like there is no tomorrow… But at what cost? Have they understood the requirement? Have they met or understood all of the acceptance criteria? Have they maintained their unit coverage? Kept high standard around build quality?
Testers now have a backlog of stories to validate, “just get it done”, “we’ll do the automation later” …. The mantra driven by an “immovable” date. But at what cost?
Delivery in “Death March” land is like a modern day Russian roulette. You may be lucky that the code written does not crash the application, you may be lucky that users have not yet uncovered a transposed business rule… You achieve go-live…. Everyone is happy…. And then ‘Bang!’
A problem in production…. Service Desk ask for the logs…. There is no logging on the problem area. The Developer sits uncomfortably in their chair as they realise the short cut they took to deliver the code has now left the production support team in Limbo, not able to troubleshoot the root cause. The tester is equally as uncomfortable as they realise that the problem area is one where either they did not complete testing, did not create an automated regression test or they never updated the automation suite and just ignored them, all to get the code out of the door.
The Programme Team are called into a meeting with the Sponsors, they too sit uncomfortably as they realise the pressure applied to the project team had led to mistakes being made, budget approval is due for the next phase; that is at risk unless the exposure of the issue can be contained and rectified quickly.
The meeting starts, an uncomfortable report of the problem is delivered, when an email comes in announcing a workaround in Prod has been found to limit exposure. The vitriol starts with promises of a quick patch to secure the estate, more pressure applied, more pressure on quality process, more pressure on the team…. Et tu?
And so, the cycle continues, papering over the cracks to meet a timeline, reducing the rollout to ‘friendly’ ‘extended Beta Users’ until enough plasters are found to go to full rollout, all the while the ticking bomb of quality waits to pounce with the next Production issue.
So, what can be done to avoid these issues? I don’t pretend to suggest that timeline driven development won’t happen, but what I would suggest is that the power of the team is the key to delivering a robust solution. Rather than developers and testers working in isolation, daily pairing should reduce misunderstanding of the problem. Support for coding standards in unit land to ensure a fall back. Iterate through builds signing acceptance tests as you go, creating the basis of a functional automation test in line to provide another platform to build. Yes, at that point in time the process may take a little longer, but it avoids feedback being thrown back days after the developer last looked at the code, context is in place and a collective acceptance is provided. Rather than throwing over the wall, the team assure together. The production support team have a fully instrumented solution and a regression suite to help in times of trouble.
These processes were agreed and implemented for a reason, and that was for the reason of quality through repeatable objective tests.
Keeping true to the tools designed to help you will reduce the pressure as you have a foundation from which to build. Will you be able to answer the question should problems arise?
“Et tu Brute..et tu?”