Reducing the Cycle Time

Question

Reducing the Cycle Time

Steve Jones - SSC Editor

SSC Guru

Points: 736297
More actions
December 4, 2024 at 12:00 am

#4487950

Comments posted to this topic are about the item Reducing the Cycle Time

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply

David.Poole SSC Guru Points: 76024 More actions · Answer 1

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.

Quality of deliverables improves
Job satisfaction increases for all involved
Change becomes less problematic
Cycle time begins to come down

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.

LinkedIn Profile

Steve Jones - SSC Editor SSC Guru Points: 736297 More actions · Answer 2

David.Poole wrote:

... The cynic in me thinks much of the world works despite efforts to manage it, not because of it...

I somewhat live by this. The world is very chaotic and that fact that things work shows us just how much slop/leeway we have in building and managing it.

Doctor Who 2 SSCrazy Eights Points: 8195 More actions · Answer 3

WOW, I thought I had responded to this earlier this morning. I guess I failed to respond and some of my thoughts are now lost. So, here goes a shorten version. Maybe that's better.

I agree with you, Steve, in that I prefer loose coupling and accepting uncertainty. However, both my coworkers and managers are dead set against both. The coupling MUST always be tight, and uncertainty is never allowed. One of the most frustrating times for me was about 8 years ago, when upper management at that time, wanted to test the idea of Agile and DevOps. However, my supervisor and coworkers all had an extreme HATRED of Agile and DevOps. So, they all agreed to not do what upper management wanted, by not doing the pilot project we were told to do. My supervisor and coworkers all agreed to lie to upper management, telling them that we had tried to do the pilot project, and failed. They proudly said that DevOps was a total failure. The only thing we could do was go back to waterfall.

So, basically that's what we've done ever since. There are changes coming, bring brought by contractors who are writing applications using a DevOps approach. Because there's about a half dozen or so of them, working together, it's having a positive impact. My coworkers aren't happy, because their cozy little world of waterfall for all time, is challenged. And that supervisor who hated Agile and DevOps so extremely, has retired.

Rod