Do you deliver quality software frequently (< 2 weeks)?
What’s the process you’re using, Scrum, Kanban, or something different?
What makes you successful? What are obstacles?
For further actions, you may consider blocking this person and/or reporting abuse
I've worked with several iterative/agile processes. It all comes down to iteration and feedback. To get a bit higher level than any specific process or method, I think achieving this kind of regular delivery can be done with the help of two basic ideas: Evolutionary prototyping and pipelining.
By evolutionary prototype, I mean that we start with a very simple implementation of some feature, and we gradually build on it until it becomes the solid production version. To release something into production, we do want it to be ready, but we try to make it as simple as possible, so that we're not expending a lot of effort underwater, where no one but the developers can see what's happening. Once it's in the hands of users or testers, we can take that feedback to plan how that feature will evolve in the next cycle.
By pipelining, I mean that we stack features in parallel across members of the team: It typically takes 4 years to graduate from college, but there are still new graduates every year. For example, if we have a Kanban board with 4 stages, and we have two team members at each stage, we can expect roughly two team members at a time delivering some piece of completed work. I don't think it has to be so regimented in practice, but I'd expect some kind of pipeline effect to be an emergent property.
It some cases, delivering on a fast schedule like every few weeks to actual end users doesn't make sense. For example, I don't think that would work for an online banking application. But even in that case, it should be possible to deliver to teams that do QA and acceptance. Then we can bundle some number of such iterations into a real production release.
Interesting point: in theory, Scrum demands a „potentially shippable product increment“ at the end of each sprint. That would include QA/testing to be completed.
On the other hand: if the market doesn’t demand it, what‘s the damage done?
This sounds reasonable to me. I think there is a bit of nuance to consider though:
Assuming there is a separation of responsibility where we have a team, say developers, handing off work to another team, like QA, then there will always be some delay.
One way to deal with this ambiguity in Scrum is to define separate sprints for the developer and QA teams. The sprints of the last team in the chain are the ones we use when we apply this "shippable" rule.
The protocol may look something like this:
The idea would be similar in Kanban, except there aren't discrete sprints, just tasks that are transferred from one stage to another.
From a dogmatic perspective, Scrum requires the team to be able to deliver without depending on outside teams (that’s what the Scrum guide says).
From a pragmatic perspective, your scenario may work if demand for frequent delivery isn’t that high. :)
There should be no hands off to QA team. QA should be part of development team and be involved in in the development process from beginning, by for example discussing possible testing scenarios and edge cases or test automation strategies with the dev before it starts working on the feature.
Also from my experience, if the development team doesn't own all the product development lifecyle from design to deployemnt and its dependent on other teams like Ops, those other teams will end up becoming a bottleneck and slowing the team down.
I really like the way Spotify and Netflix work.
Of course, this is the ideal scenario IMO. Sometimes its not possible and might depend a lot of the context of your organization.
I support the idea of cross-functional teams. However, I don't agree that one never needs to hand off a given piece of work for it to be thoroughly tested. That really depends on the nature of the software. For cases like financial software, medical software, military software, I believe it can make sense to test that software in a way that the developer alone cannot, even if the developer has worked with QA and Acceptance to carefully produce something they have confidence in.
Assuming the quality of software handed over is high, much of this additional testing work may end up not revealing any new problems, but there are cases where that extra due diligence is required. Another example is when software has to be supported in a lot of different environments such as different browsers, different operating systems, different hardware.
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.
Not implying you said that, but do you think daily releases necessarily lead to bad quality?
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.
The key to delivering software as quickly as possibly is to have as little process as possible but place value on things that actually give you confidence.
Ask your engineers, if we deployed every commit to live; what would it take for you to not be scared?
Scrum, kanban, etc are all distractions honestly.
Do you currently work that way? How are business priorities reflected in your way of working?
Yes I do, it's very nice and teams I have worked on have always been less stressed, more productive and happier compared to teams that release weekly/monthly
Re the business
It's important to distinguish between business requirements and technical activities.
Files moving from one server to the other (i.e deploying) is not a business concern. Just like how creating functions is not a business concern.
Depending on the business it is better to ship features when they're ready even in an MVP state. But if the business wants/needs control, use feature flags.
edit-
Due to the fast feedback, iterative nature of continuous delivery business requirements are generally more based on actual real feedback rather than guesses. In addition because we can ship things easier they are more open to trying different ideas. So CD is not only a technical win but a business one too. It changes the way the business works for the better.