Software Delivery in Small Batches

You’re listening to this podcast because you want to improve. You want to become a better developer, manager, or leader. This podcast is a great start, but now I have something to help you find excellence. This is the official Small Batches Way study guide!
The study guide charts a path to software delivery excellency from the best books, ideas, and practices. The path is four parts: Understanding of TDD, Understanding of software architecture, understanding of production operations, and understanding continuous delivery.
Get it for FREE at TheSmallBatchesWay.com.

Hello and welcome to Small Batches with me Adam Hawkins. In each episode, I share a small batch of the theory and practices behind software delivery excellency.
Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.

I have mentee. Our last session centered around a stalled project. The challenge was getting an engineer to stop building unnecessary complex solutions. The conversation turned to how communicate this to the engineer. I suggested to focus on delivering working software.
The comment piqued their interest. They asked why phrase it like that? We talked about how why delivering working software software is why we’re paid, how it’s the ultimate measure of progress, and the constant collaboration with stakeholders.
This line of thinking is not new. In fact, it’s over twenty years old. It’s straight out the agile manifesto.
Main Content
The agile manifesto was signed in 2001 by a diverse group of software professionals looking for an alternative to the documentation driven and heavyweight software development status -quo at the time.
The manifesto is concise. I’ll read it now:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
This concise manifesto fundamentally changed the industry. The phase shift occurred by using change as a high-value feature instead of a bug. This opened the door to fast feedback and optimizing for learning.
So, how does that happen? We don’t have to guess. The authors published a list of principles behind the manifesto. This is the first one:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Key words: early, continuous, and valuable. Early and continuous point to iterative development. Hell, “continuous delivery” is straight up in the text. Valuable points to business value defined by stakeholders such as the end user or customer.
This was another phase shift in software because business outcomes, in the from of working valuable software, became front and center. That required collaboration which turned software development a team sport. Primary working software measured progress.
Collaboration was not one off. It was continuous. Listen to this principle:
Business people and developers must work together daily throughout the project.
The signatories were not simply focused on process and collaboration. They also deeply understood the relationship between the craft of software development and success. Listen to this principle:
Continuous attention to technical excellence and good design enhanced agility.
Great software is easily changeable software. Easily changeable software means it’s easier to react to change. Change is not a bug, it’s a feature. Listen to the second principle:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
I won’t read off all the principles in this episode. That’s for you and your self-study. Let’s close out this episode with a short reflection.
Closing Thoughts
I think there are two reactions upon hearing “agile manifesto” at this point.
One is a feeling of “ugh, this played out crap?”. The other is the opposite: “Huh? What’s the agile manifesto?”.
There are new software developers who simply don’t know the history. Perhaps they got into development with a bootcamp or just as a hobby. These development are not aware how deeply the the agile manifesto penetrated the software development milieu.
On the other hand they’re jaded developers about “agile” for a laundry list of reasons. Two immediately come to me. One, the co-opting of the term by a cottage industry of consultants spouting ready-made solutions for so-called “agile transformations”; Two, the focus on “doing” agile rather than “being” agile.
If you’re in the first camp, then studying the agile manifesto is chance to learn the history of software development.
If you’re in the second cap, then let’s cut through the jaded bullshit around “agile” to focus on the manifesto’s message. All the principles still applies today, perhaps even more so.
One of the principles calls for delivering a couple of weeks to months. That is slow by today’s standard. Now, we have the technology and tools to deploy hundreds of times a day. We can take these principles and turn them up to 11.
And for all of us, you’ll see that whatever the flavor of the day is, it’s still agile at the end of the day.
We may call it “DevOps”, “Flow” or “Lean” but the underlying goal is still the same: optimize for the continuous delivery of working software.
Follow this and you’ll end in a good place.

All right that’s all for this batch. Head over to https://SmallBatches.fm/92 for links for recommended self-study on the agile manifesto and ways to support the show.
Also, I do have a slot for a new mentoring client. So email me if you’re interested in direct one-on-one software development mentoring and coaching.
I hope to have you back again for next episode. So until then, happy shipping!