Unlocking high software engineering pace: Build less, ship frequently, learn faster – Jim Grey on software management

The article argues that two-week sprints often hide a waterfall pattern when teams keep working on a larger feature until it is finished, with no working software for users to touch. It contrasts that with shipping a small useful version during the sprint so teams can validate assumptions, create value sooner, and learn from real feedback.

Reading notes

#

• Teams can spend several sprints on a feature and still have no user-visible software, only a burndown chart.
• Shipping something small in the sprint lets a team model core data, build basic services, create a simple UX, and put it in front of real users.
• The client example shows supplier management reduced to adding, editing, and inactivating suppliers, then deployed to production after two sprints.
• Customers used the feature immediately, then asked for one specific follow-up enhancement: linking quality problems to suppliers.
• Starting small reduced wasted effort, lowered risk, sped up value delivery, and freed engineering capacity for other priorities.
• The main difficulty is cultural: teams want to build things the “right way,” while stakeholders may worry about looking unsophisticated.
• The article says the smallest version should solve a real problem for a real user today, and leaders need to keep teams focused on that.
• The closing point is that the team that learns fastest wins, and learning depends on shipping.