Autonomy, architecture and agile

One of the things I love about agile is the autonomy given to the team. The team should not depend on anyone external to the project to effectively deliver the software within the quality standard and budget restrictions.

In small systems I do believe the team may have total autonomy, as for selecting the tools, programming languages and architecture they prefer. But what will happen as the company grows?

Let’s use the real world. If you put a small number of people working on an isolated problem, they tend to make an agreement on how to solve the problem. If you live in an apartment and the building has some bad conditions that are affecting the majority of the tenants, they will — probably — agree to solve the issue.

As the problem gets bigger and bigger and starts affecting different groups of people, the solutions may not come naturally.

Trying to solve global warming is not something that can be done by the entire population of the world. I’m no expert on this, but I believe one of the reasons is that the majority of the population doesn’t see the bigger picture. Some countries are still in a development stage and they need to be allowed to have a higher level of pollution than others. Some others, cutting their level of pollution will ruin their economy. Ruining their economy may start a domino effect that will affect the entire world. Etc. I understand pollution can ruin the world, but as can the war. And the number one reason for war to happen is resources scarcity. Trade-offs, trade-offs…

But back to the software industry

Software architecture has some major reasons to exist. An architect should deliver a working solution, on budget, that satisfies all the stakeholders’ needs. Stakeholders’ architects are everyone involved in the project: managers, software engineers, QA, support, project managers, business, product owners, etc. Lately, it’s seems that the software architect has not a good reputation… “they don’t do anything, just document things”, “they are too high level”, etc. “We are agile, we don’t need an architect”.

“Emerge design”

One of the things about agile is little upfront design. I like it. When you scale an organization and you try to get everyone involved on decisions — because people should be autonomous and we should not demotivate people by telling them what they need to do — you will probably end in a pattern that I like to call “design by committee”.

Design by committee is getting everyone together and start discussing or debating things related to your architecture. It seems an amazing idea and I used to like it, but it has one huge problem… the louder person will win.

“I have an experienced and smart team, they will make a wise choice”

And Hitler got elected... What I mean is, if you’re confronted with an intelligent and well-spoken person with seemingly good arguments, you may not choose so wisely after all. Every team needs leadership, coaching and mentoring. The leadership must come from someone that management sees that shares your vision for the company. Coaching and mentoring will come naturally. Eliminate as soon as possible leaders that are toxic for what you want to achieve. Forget what I just said. Eliminate as soon as possible any toxic person, a leader or not.

Remember that if you don’t choose your leadership someone will… and they may not share the same idea as yours.

“But don’t create monkeys”

So, all that said. You should have someone responsible for your architecture with the time and experience to share and improve your company. This is the easy part. Let’s talk about the hardest one.

The hard part is that you should not create monkeys. Everyone should be involved and ideas should always be welcome.

Architecture is all about people and communication.

And by being involved I don’t mean design by committee. Get feedback and soon as possible, evaluate, decide and communicate.

“I don’t see any difference”

An architect is not someone that is an expert in every field. An architect is the guy that knows a lot of things — a generalist -, understands the trade-offs, understands the cost, understands the team he has and makes decisions. The architect should be empowered to make decisions. As the product manager/product owner makes decisions about the product, an architect makes decisions about the technology.

The architect is someone that will be telling your development team about technology X or language Y, but at the same time will prevent them to jump right into it. He must understand and manage change. Changing tools and technology is expensive. You better have a good business case for that. The architect would have one.

“People are smart”

Yes! But they need experience to be smarter. If you get 20 Junior developers that think they know a lot and give them a voice, and an experienced software engineer that doesn’t really like to speak in public, and you go for a design by committee session, what do you think will happen? Juniors’ option will win if they can argue.

It’s nice to have a voice and I’ve learned a lot from less experienced people and I think I’ve taught something to a lot more experienced people. It’s is also nice to have a clear and good mentor to guide us. Giving the autonomy for them to choose doesn’t mean the company should lose money until they have learned. Invest in experienced people and put them in leadership positions. They should be able to guide the team towards what the company needs.

Guide! Not control!