SDN – Software Development Network SDN – Software Development Network – De SDN verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Microsoft en .NET.
In 1983 I bought my first computer. A Commodore 64. Soon, I wrote my first code. In BASIC. That was thirty-seven years ago. From there, it didn’t take long before I earned money from writing code. That was at the age of nineteen, during the first year of my computer science studies.
Column by Sander Hoogendoorn
However, it wasn’t until recently, during a conversation with my girlfriend Kim, who is just taking up programming, that I realized that when I wrote my first code, the field of software development had only existed for about forty years. It is a young field.
I learned how to code without automatically refactoring development tools, without being able to run code in the cloud, without unit testing, without automated pipelines, without continuous integration, and even without StackOverflow. We didn’t even have the internet. All of this simply didn’t exist thirty years ago.
The field of software development has evolved rigorously during its short existence. We went from the very first computers to a ubiquitous worldwide presence of software on a magnitude of devices in about seventy years.
And we have learned so much.
If you consider the methodologies and approaches for software development over the years a similar pattern emerges. Back in 1983, I didn’t know much about methodologies. Yes, the waterfall existed, but my projects weren’t large enough to apply it. It wasn’t until my first job at a consultancy, in 1994, that I first encountered waterfall projects. It wasn’t pretty. They went over budget, over time, and under-delivered. Project managers ruled relentlessly, processes were strict, and developers were mere resources.
But we learned. We started to realize that requirements change and feedback was useful, so we’d better take it into account. A new generation of methodologies emerged, such as the Unified Process and the Spiral Model, introducing increments and iterations, albeit usually in cycles of several months.
In the mid-1990s, I got acquainted with the Dynamic Systems Development Method (DSDM). DSDM has increments and iterations at heart and it introduced much shorter cycles. Along with improvements in languages, tools, and frameworks, we now delivered increments in iterations of six or eight weeks. And for the first time, these iterations included all activities necessary to deliver, such as design, coding, testing, integration, and releasing increments to the customer.
We learned again. The shorter the feedback loops, the higher the quality. And, the more rituals and ceremonies we could make redundant, the better and faster we became. Bye-bye big-upfront designs. Bye-bye Gantt charts. So long rigor project plans.
As a result, in 1998, my team and I developed the Smart approach that combined these learnings with again improved tooling, including code generation. It allowed us to shorten our iterations again, to lengths of three to four weeks. Not too long after that, my team and I learned about extreme programming (XP), and with it, we discovered the merits of refactoring, continuous integration, unit testing, and even autonomy, which shortened our iterations again.
Then in 2001, the Agile Manifesto was published.
It is needless to say, almost twenty later, that the Agile Manifesto made an unimaginably big impact on the world. It is a major driver in changing organizations in many different industries. For us, the Manifesto was a strong confirmation that we were on the right track. Smart was an agile approach, and its popularity piggybacked on the evangelization of agile.
Then, we bumped into Scrum, which soon became more popular than all of the other agile approaches together. Scrum almost became synonymous with agile. Due to its simplicity Scrum attracted people from many other fields to software development. At the same time, our tooling improved again. Git largely improved version control systems. JUnit made unit testing tangible. Refactoring finally got supported out-of-the-box. Clear many impediments from our paths, we again were able to move faster. Our iterations shortened again, to one to two weeks.
Moreover, we learned that the process of making rituals and ceremonies redundant to become better and faster never stops. It is continuous.
The ideas, values, and principles of the Agile Manifesto remain extremely valuable. But Scrum is not the end game. Moving forward continuously means that its rituals and ceremonies will become redundant as soon as we can move beyond them. Exactly following the most important part of the Agile Manifesto.
We are uncovering better ways of developing software by doing it and helping others do it.
Where does that leave us today? To cut a decade short. We now reap the benefits of continuous delivery, and being able to automatically test and deploy our code in the cloud. We leverage microservices architectures, DevOps, and infrastructure-as-code, allowing teams to prune even more overhead from their approaches.
For the last seven to eight years, I’ve helped organizations to move along these lines. Every time, the results were similar. Despite the resistance from traditional agile and Scrum representatives, we made more and more of the rituals and ceremonies redundant that we so happily introduced twenty years ago.
We now deliver individual features. Continuously. Therefore, there’s no need to plan and fit our work items into iterations or sprints. We stopped doing sprints but rather delivered features multiple times per day. Without having to fit work into sprints, there was no need anymore for low-level estimates. We dropped those too. And instead of organizing day-long refinement workshops at the start of sprints, we rather briefly discuss each work item on the day we pick it up.
Each of our work items only requires a small subset of the skills of the whole team. Therefore, each work item is picked up exactly when we need to deliver it, but also exactly by who can deliver it. Tiny teams of one to three people work on tiny work items, for maybe one or two days, deliver it, and then disband again, to reform new tiny teams, often in different compositions. I refer to these teams as microteams, as a reference to microservices.
Again we learned to deliver software better and faster. We made the rituals and ceremonies of the current generation of agile approaches redundant, without losing the good parts. So bye-bye sprint planning and refinements. Bye-bye story point estimation. So long sprints.
Still, we completely adhere to the Agile Manifesto, which clearly states that our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Today we just deliver even smaller features, in even shorter cycles, with even smaller teams, in smaller components.
As an example, my current team builds a microservices platform for an IoT company. We bring the platform one step further every day. We don’t have sprints. We don’t estimate our work items. Our testing and pipelines are fully automated, and our infrastructure is immutable. We have very few ceremonies left and simply answer one question every day: what small problem are we solving today? We operate in microteams of constantly varying compositions and deliver work items multiple times per day. And actually, it’s a breeze.
If there’s one thing I’ve learned from twenty years of agile and thirty-five years in this industry is that all methodologies are temporary, including agile approaches. We are continuously uncovering better ways of working.
I’m already curious about how we will fare in the next decade.
BIO Sander Hoogendoorn:
Sander is an independent dad, speaker, writer, and traveler. He has been writing code since 1984 and still codes every day. He is a serial CTO, currently at e-commerce iBOOD. Sander is a code philosopher, agilist, and operated as Capgemini’s global agile thought leader for a decade before going freelance in 2015.
Following his adagio that small steps are the fastest way forward, Sander helps to empower organizations, teams, and individuals, and to disrupt their ways of working, technology, architectures, and code. He has authored various books and published tons of articles.
Sander is a well-known and inspiring keynote speaker at international conferences on diverse topics such as disruption, culture, (beyond) agile, continuous delivery, microteams, monads, software architecture, microservices, and writing beautiful code.
Tools do not solve problems, thinking does.