Markus Gärtner interviewed Ron Jeffries, co-author of the Agile Manifesto and Coach of the first Extreme Programming team. Ron reflects back on the past 20-or-so-years of Agile Software Development and dares to look ahead on things to come.

Markus Gärtner interviewed Ron Jeffries, co-author of the Agile Manifesto and Coach of the first Extreme Programming team. Ron reflects back on the past 20-or-so-years of Agile Software Development and dares to look ahead on things to come.

(Markus) it-agile turns 20 years old this year. Given you have been around for a little while longer in the Agile community, what’s the one thing you wished you could tell your 20-years younger self - given what you know today?

(Ron:) First, take better care of your body, it has to last longer than you may expect.

Oh, you probably meant what would I tell myself that relates somehow to Agile. OK…

In all seriousness, I think there are two related subjects that I would like to have been aware of, although I don’t know, even today, what could have been done about them.

[First,] Scrum is going to become the default form of Agile. It does not now and will never contain technical practices, which are absolutely critical to maintaining the balance between the business side and the development side we refer to in the Manifesto. Try to find ways to keep the technical practices and other developer matters alive in the community.

Scrum, simple though it is, will be over-simplified and applied in name only, without regard to even its simple key principles. It will turn into Dark Scrum, a perverted version of its good ideas, and will be used as a whip over the development team. In Dark Scrum, the developers suffer and the business does not get the benefits they could have gained. Try to find something to do about that.

One more thing: Collaboration is key to the working of the Agile cycle. You, Ron, will prefer to deal with the technical side of Agile. That’s fine, but remember to focus on using running tested software as the subject matter around which the collaboration happens.

Reflecting back, in which ways do you think, did the publishing of the Agile Manifesto have an impact on the software development world in the past 20+ years? Was it successful? In which ways wasn’t it?

Many people have benefited from our initial ideas, and from the ideas and tools based on them, such as automated refactoring.

However, the uptake of the essential ideas was far less than I had hoped: I thought we were going to truly change the world for the better. I guess things are better, in some places, but certainly not everywhere.

If I recall correctly, the whole Craft movement stemmed from the upcoming focus on tools in the Agile community, even though the first value pair tries to remind us of the fact that people and their interactions are more important for the success of a software development effort than the right tools, yet, that discussing seems to have vanished from the public sphere. Where do you think are we, as an Agile community, on this?

Excellent topic. I think that the largest issue in the Agile world today is the lack of effective collaboration between the business and development. We said in the Manifesto that the business people and development people should work together every day. More commonly, with Scrum, requirements are passed down to an unempowered “Product Owner”, and pushed upon the dev team. All too often, the dev team just grinds out what they’re told, and the organization loses out on their creativity and the near certainty that they could get a better product with less effort if they collaborated effectively.

Just recently, I came across the rights of the various roles in XP you describe in XP Installed, and decided to read those to a group of Scrum students. In which way do you think something like the “rights of the Product Owner”, etc. is missing in the Scrum Guide?

Yes, and… I think that today I would not couch my ideas in terms of separate “rights”, but instead perhaps identify the subject matter of each right and then organize a document that described the part that each role plays regarding that topic. I would focus on the collaboration. I think the rights are more likely to lead to focus on the differences and conflicts.

What do you think was the biggest contribution Extreme Programming had to the way we develop software today?

Well, less than I had hoped, but still quite a lot. The practices of test-driven development and the focus on how to actually do interactive and incremental development, via continuous design and refactoring are the most fundamental.

A couple of years back I read a small book called “The Nature of Software Development” which captured many of the experiences I had when working on a software product. Since you wrote that book, with more and more products being considered “not only” software, yet, software remains a crucial part of those products’ experience to the end users, could we be hitting a turning point where the nature of software development and the nature of the other industries either have to melt together or find suitable interfaces between them? Which role did the whole agile movement play in this regard?

I don’t see a turning point, I see continued acceleration. Most large companies relied on software 20+ years ago. Now virtually every company does.

Probably the most important message of “Agile”, and the one most forgotten, is that the business people and technical people must work together daily! Many great organizations do follow this principle, but many more seem not to. It is as if people really do not want to collaborate.

Of course we see that problem in areas other than software, areas that are far more important. We’ll come back to that thought.

I think I saw you around the craft community, at least in the beginning back in 2008/2009. In retrospect, where do you see that movement fell into when it comes to coding practices, and the lesser focus that the Scrum community paid to those?

The craft community did have my attention and support early on. It was founded by a Manifesto author, and was surely based on XP practices, with other valuable engineering practices added in. What I do not like about the craft movement as it evolved is that it has often taken on a very authoritarian focus, and almost a blame culture - “you can’t call yourself a craftsman unless you do this”.

Despite my distaste for what I consider serious flaws in style, I suspect that the movement has supported a good number of Scrum developers in sustaining good practices under the all too common pressure of Scrum.

Back in 2016 you posted a public apology for the Connextra format (“As a… I want… so that…”) for user stories. Can you elaborate on why you felt you had to apologize?

Was it an apology? I’d like to see a citation on that. Anyway, the Connextra format is a source of a fundamental mistake in process. The thing that makes Agile work is for the people with the need for the software, and the people who can write the software, to work together. Connextra, and its offspring, fall back to the old waterfall practice of writing down the requirements. The point is to come together and discuss needs and solutions.

In addition, it’s a naive if not downright stupid format, and I hope I had nothing to do with its creation. If nothing else, it should have put the “so that” part first, since it is the most important aspect of any story: what do you want to accomplish?

You were part of a group of 17 people that wrote the Agile manifesto back in 2001. I once heard you say that you think that has been about the only time those 17 individuals were able to agree on something. Why do you think so?

I think so because a) we met from time to time and did not agree on a lot of key topics, and b) I worked with a number of them over the years and there were important disagreements. We all remain friends and colleagues. As far as I know there have been no duels or fisticuffs.

I think that the main cause of the disagreements was competition. The authors were primarily consultants and were in some ways in competition with each other. They were also primarily the kind of person who thinks they are right. There were competing approaches, including but not limited to Scrum and XP, with different proponents among the authors.

Back in 2013, I recall attending a session on SAFe at one of the conferences. I also recall thinking to myself that people too easily might end up mis-applying what they read or heard, and eventually have the whole business world lose faith in the whole agile movement after all. Jumping ten years ahead I get the sense I wasn’t too wrong back then. Over the years I saw you being critical about it as well. What’s your perspective on how we ended where we are right now?

First of all, despite its name, SAFe is in almost no way consistent with the Agile values and principles. The training gives lip service to those values and principles, but in practice, they seem generally to get lost. (I would like to be wrong about this, but my money’s on what I just said.)

We ended up here through the interaction of many forces, beginning with the lucrative but mostly ineffective Scrum Certifications, and yes, I have been complicit in that, trying to work from “inside the tent”.

I think the real reason is that the “system”, including but not limited to extractive capitalism, is very very hard to change.

I think that over the long term, humanity has a tendency to improve, but it’s slow and there are many setbacks. We seem to be threatened by some serious setbacks right now, but I am hopeful that wiser heads will prevail.

The matters on the table today go far beyond software or “Agile”, but the difficulties that “Agile” faces are in large part those facing all of society, including capitalism, authoritarianism, and the massive divide between rich and poor.

Agile, as I see it, is essentially humanistic, and we need to better value all humans, and work to make every life better.

Some time has passed by since the manifesto. Given some authors moved on, some unfortunately died, others stuck to their field of experience, what do you think could have been possible with less competition, and more collaboration? How could the Agile community have been developing with less competition?

Honestly, I do not know. In some imaginary world where all of us had less ego in the game, yet were somehow still full of drive and ideas, one might imagine a single jointly-created process, somehow combining the best of Scrum, XP, and Crystal. (And DSDM? And so on?)

I think that the ideas behind Cockburn’s Crystal are valuable, in that he envisioned simple processes for smaller and simpler products, with more process added in as needed. With those ideas, we might have incorporated “scaling” earlier, and might have avoided the abomination that is SAFe.

The Scrum-XP combination is more problematical. Scrum took over the mindshare because it seems easy. It seems easy because you don’t have development-side process elements, the XP technical practices etc.

Furthermore the invention of the “Certified ScrumMaster” was a brilliant marketing move. However, on a given day, I could make a good case that it destroyed Agile. To this day there are tens of certified scrum masters for every certified scrum developer. The ratio, if you were going to have certifications, should be the other way around: there should be ten certified developers per scrum master or product owner.

But in the end, I think we’d wind up near where we are. When Agile was a hot idea, it was joined by collaboration experts, testing experts, people from the lean community, all kinds of folks with valuable ideas. I see no way that all those wonderful ideas could be kept coherent and I’m not sure that if we could control them, we should.

It’s probably better to have a complex uncontrollable ecosystem of ideas than a single scalable giant coherent process. It’s just that when that happens, people will pick and choose what parts to use, and since Cockburn was right when he said “People mean well, but they are lazy”, people will pick the easy parts and the hard parts, like collaboration and actual development, will be left behind.

Given the current trajectory, what do you think might happen to the Agile community in the next 20 years?

I think that the true core of Agile is collaboration and cooperation, despite the focus on process and the like.

I think that in the next 20 years there are so many possible transforming events that we can’t possibly know what things will look like. I’ll name a few, and we can remove them in post processing.

Our national leaders, in many countries, seem to have forgotten how to collaborate and cooperate, and focus only on destroying their competition and getting to stay in office.

We could easily see democracy fail, at least in some places, and perhaps even in its most central bastions.

We will certainly see serious climate impact, and that is likely to have a powerful effect on the economy and therefore on our business.

The impact of “AI”, which is Artificial and is not Intelligence, is likely to damage software development process as people try to use hallucinating LLMs to develop software.

We appear to be moving into a period of greater warfare, in more than one location, which will at a minimum affect us economically and perhaps in much more profound ways.

Technically, we will see much faster and much smaller computers, which will make things practical that are out of reach today.

And through it all, there will be people, most of whom mean well, but who are faced, always, with problems larger than they are, calling upon them to collaborate to solve harder and harder problems.

I would hope for some kind of renaissance of human values and cooperation. If we do, that will be where the agile ideas fit in. I fear that we may see the opposite.

Imagine, your grandkid nowadays comes to you and tells you about their future plan to become a software developer. Of course, you try to talk them out of it, but they are convinced to follow in your footsteps. What career advice would you give them to stay sane and true to themselves and those around them?

Fortunately, that has not happened. It’s almost an impossible question.

My own career in software has been filled with good fortune, and also filled with many failures and disappointments. Everything good, I often feel, came down to luck. I was invited to take on a summer internship decades ago, that introduced me to computing with a focus on the most advanced future-oriented aspects of software, not just the sort of programming job a junior programmer should expect. And I was able to maintain that focus, through many more lucky incidents, such as being invited to work in an engineering psychology lab while I was in grad school, and then invited to join a company engaged in the then-new notion of time-sharing. I got into Agile because Kent Beck fell into the Chrysler C3 project and happened to know me and to know that I lived near Detroit.

I think that a career in software today, and perhaps for the past couple of decades, and for the foreseeable future, starts with a junior developer taking a job in a shop where work is pushed onto them and they have to grind it out. It’s too often true that there will be no effort made by the company to enhance that developer’s skills. If the company needs new skills, they’ll hire people that they think already have those skills. The developer who has been around a while will be kept working on the old stuff until one day they can retire the old stuff and let the developers go. They just cycle new young developers into old tired ones.

No, that doesn’t always happen. But it seems to happen often enough that if we picked a young developer out of a hat and had to predict their future, that’s what we should predict. I would like to be wrong about this, but I think I’m not.

Anyway, faced with this young person who nonetheless wants to get into software, I would try to provide things like this:

There are a few training programs in the world that try to prepare developers. I’d try to find one that they could enter that would help them learn skills and values like mine. I know there is one such program, and that they couldn’t get into it. Maybe there’s another. Maybe my friends and I should create one.

I would train them myself, working with them to share what I do, why I do it, and what happens.

I would try to get them jobs apprenticing with people I know, and groups that I know of, that are working in the style I favor, or training others to do so.

I would try to immerse them in the things that have brought me joy and (some) success, for as long as possible before they had to actually find a job.

By then, they might be qualified to find work with one of the few organizations that treats software the way it should be treated. If we could find one that’s hiring.

Oh, and two things that I would steer them away from: “AI”, and crypto. The current “AI” fad is going to be harmful to programmers — it is already responsible for many lost jobs — and it is going to harm the Internet and result in a lot of software that doesn’t work. Crypto is fundamentally a pyramid scheme that happens to destroy the environment. But all that is probably for another interview!

I certainly look forward to that one, but am also reminded about your reply when I met you in person and decided to shake your hand a couple of years ago, when I said “Hi Ron, nice to meet you.”: “We’ll see about that.”

About Ron Jeffries

Ron Jeffries is one of the authors of the Agile Manifesto, coached the first Extreme Programming team and is a Certified Scrum Trainer. He is the owner/operator of two of Agile’s most prolific web sites, RonJeffries.com and XProgramming.com. His most recent book is The Nature of Software Development, released early in 2015. He is an outspoken supporter of technical improvement and excellence in Agile Software Development. Despite his sometimes gruff demeanor he is often thought to be a teddy bear at heart. We can neither confirm nor deny this belief.