Ho ho ho merry book club day - I'm sending this one out a bit early; tomorrow I'm headed on vacation and won't be back until the new year. Preemptively thinking about the new year and resolutions, I'm thinking about changes in workflow and process. How can we develop software on our own, on our teams, and in our organizations?

Several years ago a group of smart engineers drafted the Agile Manifesto to take a stab at figuring out the best way to develop software. I've yet to see a better summation of best practices than the 12 Agile Principles, however they end up being kind of vague and non-clear, almost like a fortune cookie or today's horoscope.

A lot of folks since have tried to come up with more concrete principles built on top of Agile. The most famous (or perhaps infamous) one is Scrum. That one is so common that today "Agile" is used interchangeably with "Scrum". However, I challenge you to read the Agile manifesto and principles and the Scrum guide and tell me that these look like they're actually trying to do the same thing. They're not. Scrum, at it's best, is a horrible corruption of Agile to try to shoehorn a better quality of life for software engineers into big corporate environments. At it's worst Scrum is a malicious attempt to keep a whole cadre of "scrum masters", "agile coaches", and other similar folks employed in cushy corporate jobs.

Agile, in spite of its generality, is the best starting point I know of to try to solve how to develop software, and Scrum ain't it. At the core, what I've always tried to stick to from the Agile thinking is to deliver value early and often, change the actual process itself as the team and product evolve, and eliminate any blockers to being able to do those two. While I think highest of Agile, I have several other bits and pieces in my toolbelt here. I like a lot of things about the Kanban process, and I start my day with a Grug quote, among other smaller bullet points I've picked up in my days.

What I've taken away from my readings this month are two new tools I'm going to add to my belt: #NoEstimates and "hypothesis over requirements", two concepts explained in the Allen Holub videos I share. Individually, either might be fine, but I think the real value of these are when used together. I doubt that these practices could just be adopted willy nilly by a regular scrum team tomorrow - these describe a way for business to work, as much as they describe a way for engineering teams to work. If all the stakeholders can be aligned on this though, and if the constraints on the project allow it, there's a potential for a huge benefit here.

But what is there for those of us stuck in regular Scrum teams that might not be able to adopt these right away, or ever? I've become very interested in this question, and I think I've found a few practices that could meaningfully help any engineering team. I'm certainly going to be bringing these practices up at my day job, and in future I may write on their success.

Videos

• War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile - Allen Holub
• #NoEstimates - Allen Holub
• How to Build Products Users Love - Kevin Hale
• Agile Software Architecture - Ian Cooper
• TDD, Where did it all go Wrong - Ian Cooper

Articles to Ponder

• The True Capacity of Your Engineering Team - Ant Weiss
• How to replace estimations and guesses with a Monte Carlo simulation - Lucas F Costa
• Actually, read just about anything from Lucas F Costa: lucasfcosta.com
• Science and Software Development - Dave Farley

Things you can do Today

• The Complete Guide to Organizing a Successful Hackathon - Hackerearth
• Start With No - Dylan Paulus
• Share Demos Every Friday - taylor.town
• Being On-Call Sucks - Bobbie Chen

And to close out, I wrote a few articles recently that are on-topic:

• Reclaim Your Agile: The One Clever Trick Agile Coaches Don't Want You to Know
• Clean Meetings: A Software Engineer's Guide
• My (Continuing) Descent Into Madness
• A Scrum Odyssey (Okay that one's a lot of GPT but it was translating my writing)