I can’t for the life of me remember where I saw it. I think the when is a bit more distinct, it was within the last year and a half.

I can’t remember the format either. Was it a blog post? Or a LinkedIn article? I do remember it being brief.

The essence was as follows:

Software Engineering is not an engineering practice. It is a discovery process. And as such, you don’t necessarily know where you’re going, you discover it along the way.

And that creates learning. So, along your discovery path, you learn. You learn what works and what doesn’t. You learn to fail and recover. And you learn how to build the thing you’ve been asked to build.

Not by estimating or planning or predicting, but by taking the journey, discovering things and learning.

While we like to envision that we can PLAN software projects and products, we essentially LEARN to deliver what’s needed.

That’s the essence. And it has profoundly stuck with me since I read it.

And if you “buy” the learning part of software development, then we need to be focusing on creating learning organizations where we experiment, fail, discover and learn as we build and deliver software.

The Learning Organization

is an incredibly thoughtful member of our agile community. Not that long ago he interviewed, , who is one of the pillars of software development practice over the past 40+ years.

I thought I’d share a quick interview Markus held with Jerry not that long ago from Markus’ blog here:

And here’s a meaningful “snippet” related to this topic:

Markus:
A current trend we see in the industry appears to evolve around new ways of working, and different forms to run an organization. One piece of it appears to be the learning organization. This deeply connects to Systems Thinking for me. Recognizing you published your first book on Systems Thinking in 1975, what have you seen being crucial for organizations to establish a learning culture?

Jerry:
First of all, management must avoid building or encouraging a blaming culture. Blame kills learning.

Second, allow plenty of time and other resources for individual learning. That’s not just classes, but includes time for reflecting on what happens, visiting other organizations, and reading.

Third, design projects so there’s time and money to correct mistakes, because if you’re going to try new things, you will make mistakes.

Fourth, there’s no such thing as “quick and dirty.” If you want to be quick, be clean. Be sure each project has sufficient slack time to process and socialize lessons learned.

Finally, provide some change artists to ensure that the organization actually applies what it learns.

Wrapping Up

The primary purpose of this post it to make you think about the essence of software development. And of course, the alignment that has with agile principles and practices.

Stay agile my friends,

Bob.