3 ms·

This sounds a lot like Scrum with longer-than-average sprints. Or maybe its Kanban? I've lost the patience to pay attention to the intricacies of them all. The

This sounds a lot like Scrum with longer-than-average sprints. Or maybe its Kanban? I've lost the patience to pay attention to the intricacies of them all. The length of the cycle is going to vary based on your product and your customer. There's a lot to be gained by delivering rapidly if you can do it, with feature flags to hide what you want to keep hidden. 6 weeks for a release is a pretty long time to wait for most projects. Personally, this is my favorite approach, and maybe you'd agree to a point: 1. Team that is focused on the one "big feature" at a time. Maintainers operate on a different team. 2. Big feature should have a planned duration that spans multiple iterations, but not too long. 6 weeks sounds reasonable. 3. Test and deliver as rapidly as you can based on your capabilities. If all your testing is automated, consider Continuous Integration at the very least. If you rely on a team of testers then come up with an iteration length that gives testers enough time to regression test a snapshot of the code to prepare a release candidate, while still allowing enough time in-between for testing new changes. The reason 3 is important is because, whenever possible, you want to avoid the terrifying mountain of risk that comes with releasing code that has not seen the light of day for months on end. Typically the longer you spend preparing a release, the longer you have everyone panicking when the deadline is approaching and this massive release has a massive backlog of bugs.

CharlieDigital 3y ago
The book is very approachable and free in digital form. I strongly recommend anyone that has an interest in this space skim it and decide on your own. Even if you end up disagreeing with or finding faults, it adds perspective and perhaps there are a few ideas that can be applied. On point 3, that really depends on how rigorous the testing process is. One of my favorite essays on the topic of software engineering is "They Write the Right Stuff" [0] which describes how NASA writes their software and why/how they achieve incredibly low defect rates. NOVA has two documentaries: "Pluto and Beyond" and "Chasing Pluto" that puts this into perspective. The New Horizons team was formed in 2000, the satellite launched in 2006, and 15 years after the kickoff reached Pluto. In the documentary, some of the folks had sent off their kids to college by the time New Horizons reached its primary mission objective; truly a life's work. The stakes aren't that high in life sciences and most programs, but in processes that involve GxP, there's generally a risk of injury so it is still higher than say something like Notion or Reddit. True: even with the most rigorous process, there will be outliers in the real world (for example, we would once in a while run into unprocessable PDFs which had embedded entities). But the software I wrote in this span had an incredibly low defect rate. By the time it had reached production, it went through several cycles of informal testing, formal internal testing and validation, and then customer testing and validation. Also true: this doesn't work for all types of software. For consumer software, I'd release that last stage incrementally instead. Incorporation of automation is absolutely critical; in my quest to speed up this process, I ended up spending a lot of time experimenting with E2E test automation[1] to focus our test and documentation efforts. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff [1] https://youtu.be/RGu0ta6MN1k https://youtu.be/RGu0ta6MN1k, https://youtu.be/qYkphCJjD_k https://youtu.be/qYkphCJjD_k, https://youtu.be/i-sMXPV547s https://youtu.be/i-sMXPV547s, https://www.linkedin.com/pulse/v-word-how-technology-decisions-can-streamline-validation-chen https://www.linkedin.com/pulse/v-word-how-technology-decisio...

CharlieDigital 3y ago

The book is very approachable and free in digital form. I strongly recommend anyone that has an interest in this space skim it and decide on your own. Even if you end up disagreeing with or finding faults, it adds perspective and perhaps there are a few ideas that can be applied. On point 3, that really depends on how rigorous the testing process is. One of my favorite essays on the topic of software engineering is "They Write the Right Stuff" [0] which describes how NASA writes their software and why/how they achieve incredibly low defect rates. NOVA has two documentaries: "Pluto and Beyond" and "Chasing Pluto" that puts this into perspective. The New Horizons team was formed in 2000, the satellite launched in 2006, and 15 years after the kickoff reached Pluto. In the documentary, some of the folks had sent off their kids to college by the time New Horizons reached its primary mission objective; truly a life's work. The stakes aren't that high in life sciences and most programs, but in processes that involve GxP, there's generally a risk of injury so it is still higher than say something like Notion or Reddit. True: even with the most rigorous process, there will be outliers in the real world (for example, we would once in a while run into unprocessable PDFs which had embedded entities). But the software I wrote in this span had an incredibly low defect rate. By the time it had reached production, it went through several cycles of informal testing, formal internal testing and validation, and then customer testing and validation. Also true: this doesn't work for all types of software. For consumer software, I'd release that last stage incrementally instead. Incorporation of automation is absolutely critical; in my quest to speed up this process, I ended up spending a lot of time experimenting with E2E test automation[1] to focus our test and documentation efforts. [0] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff [1] https://youtu.be/RGu0ta6MN1k https://youtu.be/RGu0ta6MN1k, https://youtu.be/qYkphCJjD_k https://youtu.be/qYkphCJjD_k, https://youtu.be/i-sMXPV547s https://youtu.be/i-sMXPV547s, https://www.linkedin.com/pulse/v-word-how-technology-decisions-can-streamline-validation-chen https://www.linkedin.com/pulse/v-word-how-technology-decisio...