In software development organizations, what are the common things shared in the discussion of managers? In Agile/Scrum conferences, what are they discussing? Processes, people management, autonomy, … but rarely mentioned technical details.

In one Agile conference, they talked about adapt to changes. I asked: "But how?". A hole bunch of Agile theory came out. None of them actually solved the problem. None of them talked about architecture, the design that allows the team to adapt changes quickly and less expensive.

I did not understand why back then. I just did not like the answer and the way they understood and presented the Agile. It might work for them.

"Clients change their mind often"–it all started from there. If everyone knows what they want and do not change their mind, there is no problem, no job in the world. The software developer job is less interesting, less challenging. I heard they said about "educate clients", "educate other parties". Oh really? How does it work? How many percent of success in that?

The way I see it is that we shift the blame to the clients. We shift our focus to the things we have so little control over. And we ignore the most important part: Build the software, write the code.

Put aside all the contractual agreement, the cost, the time, change requests are eventually changing the code to adapt the new requests.

"How easy is it to change?" – That should be the most important question, IMO.

Most of the time we deal with the problems we created. Why? Because the bad architecture, it is extremely hard to change something in the code.

MVP, Minimum Viable Product, sounds cool than dangerous without careful design and architecture. How hard is it to add new feature after the first MVP? Is it possible to append or rewrite? It all depends on how well the MVP is defined, scope and implemented.

Eventually, regardless of methodologies, what matters most is the code. It is the fundamental block of a software. I really do not want to ignore it in my discussions.