Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.
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!