Then and now

In a recent email, Martin Alaimo asks:

There's a very interesting discussion on the latin america agile community going on. It's about the meaning of the Agile Manifesto Principle: "The best architectures, requirements, and designs emerge from self-organizing teams."

What is currently under discussion is the meaning of "emerge", basically, what does it mean that the "architecture emerge".

So, I would like to reach up to you to share your impressions as a Manifesto signer. Here are two questions, but feel free to add whatever you feel is needed:

1) Back in 2001, at the time of signing the manifesto: what was the sense in which the word "emerge" was used in regards to the architectures?

2) After 13 years, is there anything you'd change/adapt/add in regards to "architecture" in the agile world?

I can't speak about what everyone was thinking. I'm not sure what I was thinking. Here's what I, and we, may have had in mind. Or maybe what I have in mind now.

Historically, the heavier approaches to software development have included a separation of architecture and design from "mere coding". We felt that was far from ideal. Programming is the process of expressing design in some language. Just as our thoughts shape our words, our words shape our thoughts. The end of the sentence is conditioned not just by what we thought we wanted to say, but by how we begin to say it. And sometimes we go back and rewrite the beginning, because of what we find at the end.

The paragraph above is an example, because I didn't go back to revise it. It's an example of something that needs refactoring. It starts out being about software and turns into something about language and thought influencing each other. This part of the article might be better designed with the language bit first and then a segue into the software analogy. But I'm not going to do that, to show how a text can call out, or at least whisper, to be changed. That's part of what we were concerned about.

However, where I thought I was really headed with that paragraph was to the people. In software, it's the people. Maybe I'll get there ... but not yet.

We perceived, back at Snowbird, that the code needed to influence the design. It wasn't a one-way street. No matter how much design we did on its own, as soon as we began to express it in code, the design needed to change. We expressed it as the code telling us what the design wanted to be. Very anthropomorphic. Very metaphorical. We knew that. Almost none of us really heard the code talking to us. (That one guy: You know who you are.)

These design discoveries continue to come, throughout the life of the project, if you stay open to them. To stay open to them, you have to keep the code alive: thus refactoring. However, to stay open to them, you also need strong designers in the room, listening, when the code speaks.

And voila! There are the people. I was sure they'd turn up. The people need to be self-organizing. And they need to have the ability, not just the right, to improve the design. They improve the design over time. It changes. It emerges.

If the program is to stay alive, design must change, it must emerge. If this is to happen, the team must do it. If the team is to do it, they must be organized to do it. The best way to organize is in response to the moment. To respond in the moment, you need to be in the moment.

A self-organizing team is the best way to keep the team in the moment, the best way to respond to the moment, the best way to improve the design in the moment it needs it.

The best results emerge from self-organizing teams.