DEV Community

loading...

Discussion on: Frequent delivery - how?

Collapse
bgadrian profile image
Adrian B.G.

For a while (few years) I worked in several teams that did weekly sprints, with minimal amount of agile/scrum techniques and delivering daily releases.

It was fun for me, but there were consequences. Code quality and documentation often lacked, but in a fast moving industry you don't notice it, sometimes the projects were buried so we actually saved time and money but not doing tests and docs.

I was a dev so I didn't thought much on the management part, but some of the blockers were external dependencies and new comers that were not used to this speed. Any small rock (a delay of a half a day) can change the outcome of a sprint.

Collapse
bertilmuth profile image
Bertil Muth Author

Not implying you said that, but do you think daily releases necessarily lead to bad quality?

Collapse
bgadrian profile image
Adrian B.G.

No, big companies does that well.

But daily releases with 1 or 2 devs surely do, there is no time in 1day to make a feature, test it, write tests, doc, QA and release it few hours before closing time, time to react if something goes bad.

I also want to point out that bad quality code is not related to the product and company success, I found the oposite to be true in several cases, as in bad code but made millions.