December 4, 2024 at 12:00 am
Comments posted to this topic are about the item Reducing the Cycle Time
December 4, 2024 at 5:25 pm
One under-appreciated characteristic of a long standing IT team is that they tend to have a good grasp of the business domain for which their work is used. In some cases, a better grasp than the so called business experts.
I think this is true for other disciplines and across other industries. The cynic in me thinks much of the world works despite efforts to manage it, not because of it.
There are disciplines from the Agile world whose benefits are universal. Things like TDD (Test Driven Development) and getting testers involved at the requirements gathering phase. This means that a testers role becomes telling people how to succeed rather than telling them how they failed.
The team I worked with put a lot of thought into how agile ways of working could apply to databases. That included how to break down work into smaller deliverables. This alone made deliverables so much more reliable. The more things are delivered in one block the greater the number of interactions the greater the risk that one of them will go wrong.
In the old days we'd have a monthly deployment of deliverable containing many changes and if it failed, roll the whole thing back out. That would mean that the benefit of 99 changes could be lost because 1 change failed. Quite possibly a failure would result in going around a test cycle again and a delay trying to get a delivery slot. That balloons the cycle time. Amping up the QA/testing isn't a successful strategy as the extra QA time adds to the time requirement and my experience is that it doesn't reduce the failure rate by that much.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply