Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am a long time agile advocated but one of the things that bothers me about Agile is that a lot of agile practitioners, especially the younger ones, have thrown out or are missing a whole lot of good (non Scrum, non XP) practices. Alistair Cockburn's style of writing Use Cases springs to mind; orthogonal arrays (pairwise testing) is another.
I read mostly Agile related books and articles and work with mostly Agile folk ... is there anything I'm missing?
It might be interesting in 5-10 years time to see how maintainable these systems are when nobody wrote down why a particular decision was made and all the people involved have left.
is there anything I'm missing?
Yes, I think a lot, but only if you are interested in Softawre Development Processes.
I like this paraphrase:
Each project should be as agile as possible but not more agile.
Not every project can be agile... but I think 80%+ can.
I see Agile as "car of the year". It is very well suited for most of the people, but if you need/want something special, for example car able to speed 300KM/H or car able to carry 20 tons of goods you need something else.
There is also so many cases when one may want something else than "car of the year" that requires a book to write them down :-) I recommend you Agility and Discipline Made Easy: Practices from OpenUP and RUP. In this book you'll find many "missing parts" very well illustrated. The key to understanding is that Agility is only a (requested) property of software development process which sometimes cannot be achieved. The book describes several Key Development Principles (which are basis for RUP) and explains which level of "ceremony" and "iterativeness" follows from using them on different levels of adoption.
An example
Practice: Automate change management and change propagation
In your project you may require very advanced and strict change management and decide to "Automate change management and change propagation" by implementing custom or re-configuring existing tools and by using Change and Control Board.
Effect: This most probably increase level of "ceremony" in your project.
(...) have thrown out or are missing a whole lot of good (non Scrum, non XP) practices.
Scrum is not prescriptive, it's up to you to choose how to do things. In other words, nothing forces you to use User Stories for example (even if User Stories work for lots of teams, there is no consensus) so feel free to use (light) use-cases if you think they are more appropriate in your context. To illustrate this, Jeff Sutherland reported he would never use User Stories again for PDA device projects (they use some kind of "light specifications" in his current company). And the same applies for testing, use whatever works for you. To summarize, if you find XP not flexible enough, use something else... and inspect and adapt.
Iterative development.
In practice, agile teams may do iterations (or anything for that matter, agile is a kind of "true scotsman"), but agile processes don't require or define iterative development sufficiently.
Take RUP, for example - clumsy and bloated, it does compile a few good methods for long-term development that agile misses.
On a general note, agile is a way to steer clear of problems: how to avoid long term planning, how to keep teams small, tasks short, customers involved, etc. It works more often than not, but sometimes you have to face and solve problems: how to reach strict deadline, make big team work, achieve distant and complex goals, make customer refine requirements. That's when one needs to look beyond agile.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Looking for work at the moment, I'm seeing a lot of places asking for Agile experience, but until I get a job with a team that is using Agile, I suspect I'll never get the experience.
Is it possible to adopt Agile methodologies with just one person?
Sort of answering my own question, there's similar questions at :-
https://stackoverflow.com/questions/1407189/can-agile-scrum-be-used-by-1-or-2-developers
(I guess I should get better at searching.)
You seem to be coming at this from a work experience point of view; if you are looking to build relevant experience to get you a job on an agile project I would probably think a little more laterally.
Firstly could you work with others, maybe on an open source project? That would be a good opportunity to try out agile methods with others who may have more experience.
Secondly, you could look at using some of the common techniques or tools, even if it's just to learn how the tools work - e.g. you could set up a continues integration server to run builds and unit tests when you check in code. If you are working on your own you won't gain much in terms of productivity by doing this but you would gain some skills and have something relevant to say to future employers which would indicate you are committed to the agile style.
Yes
Check out PXP or Personal Extreme Programming.
http://portal.acm.org/citation.cfm?id=1593127
Summary from the paper:
Personal Extreme Programming (PXP) is
a software development process for a
single person team. It is based on the
values of Extreme Programming (XP)
i.e. simplicity, communication,
feedback, and courage. It works by
keeping the important aspects of XP
and refining the values so that they
can fit in a lone programmer
situation. PXP can still be refined
and improved. It is in the tradition
of XP practitioners to vary XP to
encompass whatever works. We hope
that PXP inherits these pragmatic
roots, as well. Giving up XP tenets
like pair programming is not
necessarily a tragedy. We still
believe that following XP strictly is
a more effective way to pursue
multi-person projects. But we are also
convinced that many of the XP
practices and methods can be applied
to individual work. The PXP
approach tries to balance between the
"too heavy" and the "too light"
methodologies. PXP will inject the
right amount of rigor for the
situation without overburdening the
team with unnecessary bureaucracy.
Yes - it is possible to do many agile practices as an individual.
If you already know how to do these, you can do them as a sole developer:
test-driven development - great place to start
refactoring
continuous integration
doing the simplest thing that could possibly work (and evolving it through refactoring)
automated deployment
planning meetings (a team of one plus customer)
Things you can't do on your own:
pair programming
CRC/RRC workshops (... you'd have to talk to yourself quite a lot)
Pair programming would be hard this way :)
Let's check Agile Principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
You can do all of those things even while working on some personal project alone. You can use also GTD while working alone, you can develop your product through iterations, you can adopt timeboxing, you can ask some family members or friends to do usability tests with you (and this works really well).
As a conclusion, you can really get tons of Agile experiences alone. I strongly recommend you to read some books first tho, as some of principles can be easily misinterpreted.
Some aspects can be done alone: running a product backlog and using a task board come to mind. See what the secretGeek is doing.
Of course some cannot: pair programming, scrums etc...
I recently interrupted a big project. It was a medical software project. While working on it, I realized some patterns about solo programming. I want to share my experiences here:
Your software's working logic must always reflect the real world. You catch fish with fishing rod, not baseball bat; so forget it.
Always start building from the project element to which all other elements refer. That makes sense if you think that like the function in a software project which is called at most. That might be database modeling. It would be useless if you model data access layer first, before modeling database.
Never mind changing variable names. That's the most written entry in a programmer's diary; so no need to be ashamed.
Methodology changes the world. Make worth of it. Make every single logical process with a function or procedure. When project gets huge you will understand thats the best way.
If you're not designing a language compiler in assembly do not hesitate using huge procedure call chains in which one calls another and that calls another and so on. Use methods everywhere, nearly resemble every single entity with classes and be modular.
Modularity is everything. Set modularity your primary goal. Have i said it is everything meanwhile?
Last word for beginning the project. If you're building an apartment you install main entrance at last. But when using, you enter the building from entrance. Be aware.
These are some of my design principles I learned and learning day by day. I hope having been useful. Do your best.
While some Agile practices are directly targeted at more than one person teams, they are just practices, they are just a mean, not an end. I mean, Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context. So, back to the initial question, it's definitely possible to adopt Agile practices (that make sense in your context) to maximize the delivered value: continuous planning, limiting Work In Progress, Stop-the-Line culture, time boxing, high quality, just enough specifications, just enough and just in time documentation, etc, etc.
Definately. Agile is very flexible in terms of how many people are involved. Some methodologies, like Scrum, focus mostly on doing as much as possible in a limited time, like two weeks (sprints). That includes whatever you want it to. If your team requires QA, then that is part of it. As a loner, you decide what you want to include.
After the scrum sprint, you look at what you could have done differently to get more done, and move to the next one.
Some other methodologies focus more on getting features done in each iteration, say three small features developed, tested and refactored.
As you can see, there are tons of ways to apply agile to any project. You decide which aspects you want. Though obviously one integral part is doing things in small increments.
Yes
XP/TDD scales from one to one thousand. Pair programming is optional.
YES.
Agile is more of a state of mind than just a methodology of software development like waterfall.
Scrum is one of the very popular agile methodologies. You can study below aspects of scrum in detail:
Benefits of Scrum/Agile over Waterfall
How can you create better "products" with Scrum/Agile
What are the types of projects better suited for Scrum
Pros and Cons of Scrum
Scrum Rituals and why are they necessary (What advantage do they
bring)
Different roles in scrums and their responsibilities (Scrum Master,
Product Owner and Development Team)
After you have good understanding of working of scrum and its benefits, try to create a pet project.
You will have to play all the roles yourself. You can try to distinguish between what role you are playing currently by wearing different colored hats for each role.
Example:
Product owner : Think from product perspective, what should be the features in the product and why would they be important for your users etc. Then proceed with all the scrum practices.
Scrum Master: Keep checking if you are following all scrum rituals in the right sense and spirit and are you able to derive benefits out of it.
There will be limitations,example you cannot have Daily stand-up meeting, obviously because you are the only person in the project. But if you follow above, you should be good to secure a job and play your part well in the team.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have been looking at different programming methodologies: Scrum, waterfall, spiral but someone told about one called Object-Oriented. Now as far as I know that's a paradigm and not a methodology.
If it is a methodology can someone please explain how it differs from Agile or waterfall?
Well, Google found some traces of such a beast which is clearly describing a methodology-like thing:
This document aims at introducing briefly to the readers the Object Oriented Methodology (OOM). Information covered in the document includes a brief overview of the OOM, its benefits, the processes and some of the major techniques in OOM.
OOM is a new system development approach encouraging and facilitating re-use of software components. With this methodology, a computer system can be developed on a component basis which enables the effective re-use of existing components and facilitates the sharing of its components by other systems. Through the adoption of OOM, higher productivity, lower maintenance cost and better quality can be achieved.
This methodology employs international standard Unified Modeling Language (UML) from the Object Management Group (OMG). UML is a modeling standard for OO analysis and design which has been widely adopted in the IT industry.
The OOM life cycle consists of six stages. These stages are the business planning stage, the business architecture definition stage, the technical architecture definition stage, the incremental delivery planning stage, the incremental design and build stage, and the deployment stage.
But this thing didn't spread (likely) very far. Maybe you should ask your contact for some references.
Object Oriented programming is a programming technique used when writing code. This is something different from a methodology which is a way of planning, managing and implementing a software project.
see: http://en.wikipedia.org/wiki/Object-oriented_programming
Apples and oranges. OO is a way of designing code. Scrum/waterfall/spiral, etc... are about how you manage a project. They're independent of each other.
That said, you really should look into OO.
In the late 1980s and early 1990s, some authors published work (especially books) with titles and blurbs including the word "method" or "methodology" in them; these works focused on object-oriented modelling approaches, explaining in detail the modelling primitives (metamodel) that one should use to construct structural and dynamic models of systems. Their treatment of the process to follow, however, was minimal. Later, they were criticised by applying the term "methodology".
Nowadays, "methodology" is usually thought of including a process aspect, a modelling (or product) aspect, and a people aspect, at least. The modern methodologies that were built on the tradition of those 1980s-1990s works that I mentioned above are often called "object-oriented", because the modelling approaches that were used then were, in fact, object-oriented.
Actually, it is a debated topic in research circles whether the process aspect of a methodology is substantially different depending on the modelling aspect of said methodology. For example, is the process aspect of an object-oriented method very different from the process aspect of an agent-oriented one? If you think it isn't, then the term "object-oriented methodology" may make no sense to you.
Object-orientation is an entire iterative methodology, with each stage used to validate or expose holes in the previous. It covers everything from identifying ALL stakeholders, requirements elicitation from them all, documenting the requirements in Use Cases (not part of the original O-O methodology, but adopted when Jacobsen joined Booch & Rumbaugh at Rational & UML merged in his Objectory), Analysis of the requirements begins once they had been validated with text-based Use Case documents the stakeholders can understand. Analysis is still in the business problem space, not the software solution space. Architechure & System-level Design are the first steps in creating the solution space for the identified business needs. The tasks can then be broken up and Low-level Design and Programming, implementing the Design via the case hierarchy originally created during Analysis and refined in System Design in UML Case/Object diagrams is finally handed off to the coders. One hard-and-fast rule in OOADP is that the Analysis and Design artifacts are baselined BEFORE coding is allowed to begin. Any changes that the business or marketing departments want during coding MUST be submitted to a Change Control Committee, dominated by Development. They will prioritize requested changes, evaluate their effect on the canonical class hierarchy and distributed design, determine how much extra time, money, and resources each change will impose, and go back to the business & marketing people and say - "This is the cost in time, money, and resources. Are you willing to accept the cost?" If not, the change may be discarded or moved into the next release. When you design an enterprise-sized project, you only really get that one chance at creating its skeleton of the class hierarchies. The later you try to modify the systems and have to modify classes and dependencies, the more likely you are to incur extra expenses, time delays, requirement needs - and bugs. Often subtle bugs in areas you had formerly regression-tested to hell and gone.
Agile people used to refer contemptuously to the full OOADP methodology as "BDUF" (big design up front). Scrum is designed to be the antithesis of this, with 5 or 6 programmer teams working with only one Product owner who is responsible for business/customer needs, and knows only a keyhole view of all requirements, occasionally bringing in other SMEs as she identifies a need or gap. Tasks are written out as "stories" (that is a bit of a simplification - they can be any one of several forms of requirements or requirement changes) on 3x5 cards and are tackled a small group at a time, with the intention of finishing each group by the end of a 2 or 3 week "sprint." Undone tasks are put back in the backlog of stories, an analysis is done to determine the state of the piece of the project this team is responsible for, and some of the remaining stories are passed out for the next sprint. Business & marketing LOVE Agile as much as they HATED O-O because they can insert new or altered stories or Use Cases, or other forms of requirements almost to the end of the development stage. The final product keeps changing to meet what business & marketing see as quickly shifting needs and time windows (usually hysterically exaggerated). The various little stovepipes caused when you scale a project up to more than one Scrum Team are dealt with using periodic Scrums of Scrums, where the Scrum Masters of the teams get together and try to keep every team on the same tracks and determine if any teams have backlog items that block progress within another team. The bigger the project, the more bureaucracy is added to coordinating all these teams, each subtly changing their original mandate as stories are updated or new ones added.
I've worked with O-O since the original CRC cards and Wirf-Brock refinements all the way through today's iteration of UML. I even spent several years as part of a four-man team from Bell Labs, teaching O-O and C++ to AT&T development teams. I've also worked with Agile (mostly Scrum and ScrumBan, a merger of Scrum and Japanese Kanban). I have used Agile Scrum since 1998, before there was an official standard. Agile is only a partial methodology, so every project has to find other tools or methodologies to fill in the gaps. I've seen thing get REALLY ugly if the teams were not made up of 1st-level ScrumMasters and all expert developers, cross-trained in each others' skillsets. Corporations today have made rates so low, that most of the truly gifted programmers I worked with 15 or 20 years ago are doing something else for a living & getting their coding jollies working on mobile apps or open source projects. You rarely see a truly talented team. Companies hire people without the necessary 10x "rock star" skills for some of the roles, and Scrum teams can be erratically staffed. Also, the more you try to scale Scrum for larger projects, the more problematic the results and the more the department begins to shed canonical Scrum rules, looking for some hybrid that works better.
Agile is, as its early proponents first said, excellent for doing maintenance, enhancements, and smaller non-time-boxed projects and I've seen it used very effectively. However, for a corporate enterprise project that is not driven by the fickle winds of marketers and business people's hysteria about slight changes in an external market's needs or time windows, I'll take O-O every time.
Whenever I'm presented with a contract opportunity that has both Object Orientation and Agile in the same set of requirements, I run the other way.
Back in the day people believed that Object Oriented programming was going to solve world hunger. I suspect that now agile is going to do that, they've lumped them together :-)
Seriously though, although some people took object oriented design to the status of a design methodology - identify actors & behaviours in a formal way to develop the design, it is really a set of principles about how to design software. It certainly isn't a methodology for managing the development of software projects like Scrum and agile might be.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What are the myths or misconceptions related to Agile?
There are lot of misconceptions related to Agile that an average new comer may fall into. What are the misconceptions in the Agile world and how do you justify that it is truly a misconception?
Update: Summary of Agile Myths
Agile doesn't allow documentation
Agile methods do not scale
Agile means no plan
TDD covers all the unit testing needs
Pair programming always results in better code
Agile is a silver bullet solution to software engineering problems (There is a silver bullet solution)
Agile doesn't need up front design
We're doing scrum so we don't need to do TDD, Refactoring Pair Programming, etc.
One can learn Agile from a book
Agile only works for trivial projects
Agile always uses "User Stories"
Read the following answers for more information about above myths and for more myths.
"Working software over comprehensive documentation" means you do not need a functional spec...
Wrong!!! It just means that you can iron out the wrinkles iteratively with the users - speaking as a vendor, you still need good documentation to assist with the QA and sign-off phases...
"We're doing Scrum - so we don't need to (pair | refactor | do TDD | ...)" Actually the Scrum founders - Ken and Jeff have been saying that all the high-productivity scrum teams implement the full range of Extreme Programming practices.
Test-driven development won't find all the bugs / isn't easy to apply to everything - so we're not going to try! - Learning TDD isn't an "all or nothing deal" and you get better at judging what to test and how to do it efficiently. I've been doing it for ten years now and I'm still finding better ways to do it and new things to consider.
I can learn all I need to apply agile methods from a book. - You need to learn by doing and that often means coaching and meeting other people that can help. Lots of things go wrong when people just try to learn it from a book.
Hysterical (and quite real) "The candidate must take direction from, and support the scrum master" (From a job spec I was sent last week...) - The scrum master isn't supposed to tell people what to do. He/She is there to facilitate - i.e. to help the team learn to sort things out themselves. It's a massive failure mode - having a scrum master that "commands" people!
Talking about "the agile methodology" - big cluelessness indicator. Firstly, talking about "agile" like it's a specific thing whereas it's a very vague umbrella terms for many different things. Secondly, use of "the" agile methodology - there are loads of them, and loads of different ways of doing many of them! Thirdly, a lot of people in the agile community got here in the backlash against the big, heavy UML-laden methods of the nineties. These people don't tend to use the word "methodology"...
You need especially talented people to develop software the agile way. Jeff Sutherland says that they considered using the "chief programmer team" model for managing teams in banks - but found they didn't have anything like enough "chiefs". Scrum is designed to get best productivity out of a lot of moderately able programmers. In fact removing one, disproportionately productive team member that doesn't want to help the others can "unblock" the mediocre team members and bring their combined productivity up to more than compensate for the super-productive former team member... That's what Jeff says anyway...
There are quite a few other XP-related ones that we came up with in an open space workshop that I led recently: http://xpday-london.editme.com/WhereHasXpGone
Myth: using Agile development practices is a silver bullet solution to software engineering problems.
Myth: Test-first development forces your project to have adequate unit testing.
Fact: Many developers get lazy, and the unit tests they write before their code are often weak and inadequate.
Myth: Pair programming always results in better code.
Fact: Programmers tend to be slightly anti-social and to have significantly different thought processes from one another. Having someone breathing down your neck as you code is very unpleasant, and the result is often a tense work atmosphere with a reduction in both code quality and quantity.
Myth: Agile means no documentation
Fact: Agile value working software more than comprehensive documentation but this doesn't mean no documentation at all. Documentation should be written just in time, and just enough. And no, Agile doesn't say one should always using user stories. Use them if, and only, if they are appropriate!
Myth: Agile means no plan
Fact: Agile does not support development without planning. Agile uses continuous planning and estimating to maximize the ROI. Actually, Agile is about scope management.
Myth: Agile means no discipline
Fact: Agile developers must be more disciplined for success.
Myth: Agile only works for trivial projects
Fact: Agile (actually Scrum here) has been used for
FDA-approved, life-critical software for x-rays and MRIs,
Financial payment applications,
24x7 with 99.99999% uptime requirements,
Multi-terabyte database applications,
etc
Myth: Agile doesn't scale
Fact: Sutherland used Scrum in groups of 500+, Cohn used Scrum in groups of 100+
Myth: "No Big Design Up Front" means no design.
Myth: Waterfall always fails.
Reality: Most of the software you're using on your agile project was developed with waterfall. Even BDUF waterfall, in many cases.
There's no real myths - but anything taken to an extreme will be wrong. An Agile project that does zero design in the hopes of "designing as it goes" will likely fail. A Waterfall project that designs everything down to the last semicolon will likely fail due to budget, time or changed user requirements.
It has been repeatedly said "Agile design methods do not scale" whereas Agile development will effectively scale to any size if implemented and thought out properly.
Myth: You need to carefully plan and schedule each sprint.
This leads you to do lots and lots of up-front planning so that you can fully plan each sprint.
This leads you to defeat agility and create a waterfall called "Agile".
The biggest myth I have seen is that people think it is better than other development processes.
It is the usual silver-bullet snake-oil that we have been seeing in this industry for years.
https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060
Myth: Agile is always a better option when compared to other alternatives.
Fact: depending on project size, requirements (particularly flexibility of such), external schedule, and customer attitude, it may not always be more productive compared to orthodox methodology.
Myth: Agile means XP and Scrum
Fact: There are other practices like OpenUP, AMDD, etc.
It's easy to know what to charge your customer. This is alway the biggest problems for us, because we don't know the scope of the project we can't give the customer a fixed price, and most customers demands a fixed price.
Great thread. While I offer nothing new in my related blog post, I do illustrate the top two reasons why Agile fails when it does fail. 1) Lack of upfront requirements (taking the 'begin coding with incomplete requirements' to an extreme) and
2) Lack of adequate unit tests (because CHANGE will happen - and unit tests are the quickest way of catching all the breaking points resulting from the CHANGE).
http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx
You're completely right that there are a lot of myths around Agile, some coming from outside, and others from inside. Here are a few more I thought of to add to the list:
"You don't need project managers or business analysts any more"
Although we're not doing BDUF and teams are self-directing, as things scale up there is still a need for people whose job is coordinating what's going on. And if you have a very complex business scenario, you may well need someone to help you make sense of it. IME, a lot of the projects that really needed PMs and BAs still need them (and those that don't need them now, probably never needed them!). But, of course, the roles of the PMs and BAs tend to be different in the Agile world, and that can make people uneasy.
"Agile can't be used for fixed price projects"
It can, but it is quite a bit harder. Especially since we all know that "fixed price" really means "fixed price, scope and time"...
"We don't do BDUF, we do it all as we go along"
The only way to work is JEDUF (Just Enough Design Up Front). Sometimes you need more, sometimes you can get by with less, but you don't do more than you need at that point.
Myth: Agile is anti-thetical to security.
Fact: This is only true, if you try to force a full-blown waterfall-style SDL (security development lifecycle) onto supposedly Agile teams. In fact, I have designed and implemented Agile-SDL variants in numerous organizations, and I can say that putting the Agile into the Security, can actually afford a higher, more robust level of security. it just takes a change of security mindset - from control to visibility and guidance.
If you don't show real value with agile, it will fail. And fail miserably as in bankrupt a company miserably. Going to agile just because it is 'agile' makes you look as silly as the CIO in this video:
http://www.youtube.com/watch?v=nvks70PD0Rs
John
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
How do you prevent agile methodology with monthly sprints/iterations causing a fragmented design. For ex. take the case of design of Manhattan Streets vs Design of Boston streets. The blueprints for Manhattan Streets were designed as a whole resulting in easy manoeverability and driving. Boston streets were designed in a piece meal approach and its a nightmare getting around.
Streets are a bad analogy to use for software. Streets cannot be easily moved, rerouted, or changed without significant effort. Well-written software is an composition of orthogonal components that are easily reorganized and modified as needed.
The reason that agile development works is that both the developers and the software itself are agile. The developers respond quickly to change and the software they write is written in a manner that makes it responsive to change as well.
Refactor, refactor, refactor.
Agile development is not a mandate to throw away over-arching design. It makes a lot of sense to plan 'the big picture' - what the responsibilities of your major components are, and how they will interact, for example. In my own team, I find a reasonable compromise is to agree a broad public API up front, but defer detailed implementation decisions where possible. This allows individual developers the freedom to modify the design as the implementation evolves, while also gaining the benefit of hashing out different approaches at the design level, when changes are much cheaper. Modularity is also key - keep components specific in function and as decoupled from one another as possible. This minimises your overheads when you find you need to make changes to your implementation, and should increase the chances that individual components you write remain useful.
You can have a design phase that decides on the Streets. What buildings get built is determined in each phase.
I think that there is a tendency to do too little design/architecture in scrum projects. You can do constant refactoring but that can be alot of work, if something has not been designed. You can get into the same problem if there is an error in the design.
Use of SOLID principles would result in code which is loosely coupled & highly cohesive.
Remember design is the king.
IMHO analogies of software components with Buildings, Streets are just illogical. None of this is even remotely similar to software development or software design.
There is always a risk that Agile users will suggest adjusting the principals of agile to the situation at hand, however when this subsequently fails this leaves those who support the move to Agile open to criticism because Agile is not being adopted fully.
Fragmented design is a continuous risk with Agile because there is no value on architecture. What is needed is a methodology that uses the advantageous aspects of Agile such as Continuous Delivery but solves problems like the un-scalability of Agile. A possible approach is The Game of Thrones Methodology which does just this.
"Agile methodology" (and I assume you mean SCRUM, here) has little to do with the architecture of your design; the architecture being a property of the software or the system your creating (in the UML world you would maybe call it "artefacts").
"Agile" does not tell you anything about what kind of software you write, it can be used for any and all types of software or even easily for projects that have nothing to do with software at all.
So if you have the feeling that there is a bad software architecture in your agile project(s), then you should be looking around at what the actual cause is. Only because you are agile does not mean that everybody does what he wants without a plan, or that you need no documentation at all. While you won't specifiy every class down to the bit level before starting your work, you still will want a high-level architecture written down, even before the first sprint. Depending on your team size and constituency, you could imagine using your first sprint to even create your architecture.