We Ship Every Week

I've worked at a few medium sized organizations and the cognitive dissonance around modern development practices has been astounding. Many claimed to practice 'agile' development. We'd have daily scrums, stand-ups, and kanban boards with tasks broken down and estimates to the hour. Yet it was so obvious the entire process was "waterfall in disguise".

First PMs would write laughably incomplete requirements. Then developers would be asked to create tasks and estimate how many hours it was going to take. Then developers would implement the features and maybe write some half baked test cases, as PMs watched their burndown chart and constantly asked why the project is behind schedule. Then the QA department would manually test the product for a couple weeks. After a few cycles of back and forth between QA and the dev team, the performance team would deploy to a staging environment and run their analysis, resulting in a few more back and forth cycles. Finally the devops team would deploy the latest code - at midnight with a bunch of developers present to monitor for unexpected bad outcomes.

I wrote features that didn't get deployed for months and in some cases years. If you find yourself at a place like Pitch, be grateful because shipping every week is a blessing.

I've never worked with Clojure and the article does a poor job explaining how it contributes to feature shipping speed. Functional programming? REPL?

I've personally experienced being part of teams that have a "rhythm" and it does make work seem more fun. It usually happens around a big release, after the hard/time-consuming parts are done and the teams are focusing on polishing up the system. I'd be more interested to know how problems are decomposed to support this velocity of features. How do they maintain quality and spend time on refactoring with this pace?

We used to ship twice a week, but customers don't like that much change. They prefer predictable schedules and time to digest change.

We switched to a quarterly release schedule and we ended up getting much happier customers.

We do build all the time and the main branch is always shippable, but we just don't make customers adjust all the time.

I've worked places that ship weekly and fortnightly, and both have been okay. For a few years, however, I was the lead dev at a place where we shipped when stuff was (a) complete, (b) tested, and (c) demoed to/approved by stakeholders.

It didn't matter how many days had elapsed since the last release; if something was ready then release it.

Depending upon complexity that may mean no releases for a week, but it also sometimes meant multiple releases (of separate streams of work in the same applications) on a single day. It's the only time I've ever felt the release schedule was as truly agile as the development one, and easily the simplest and most satisfying way I've ever worked.

I don't think shipping every week is a good idea or sustainable. At what point do you take away features that are no longer useful or don't work out? Or does the ball of mud accumulate forever?