Agile Design and Development
So that you can get feedback on it and make it better
The most rewarding iterations
Building is never a straight line
Product owner vs. product manager
A Product Owner is focused on output i.e. how quickly can we build these features?
Product Management, on the other hand, is focused on outcomes i.e. why are we building these features in the first place?
Good design is redesign
Good design is redesign. It's rare to get things right the first time. Experts expect to throw away some early work. They plan for plans to change.
It helps to have a medium that makes change easy. When oil paint replaced tempera in the fifteenth century, it helped painters to deal with difficult subjects like the human figure because, unlike tempera, oil can be blended and overpainted.
Finish designing as close to the end of a sprint as possible
The traditional process of delivering design, vs. delivering design just in time.
Designers are often working at least one sprint ahead of engineers. While one sprint might not seem like much of a lag, a typical product team learns a lot after the design hand-off. ...Instead of working ahead, we should finish designing as close to the end of a sprint as possible: just-in-time design.
We optimize what we measure
Scrum does not say “only focus on output”, but, unfortunately, humans will optimize for what they measure.
If you worry about story points & hitting your estimations, that’s what is going to consume your attention. That is what you and your team will optimize for.
And that is the core critique of Scrum as it is practiced: That it focuses a product team’s attention so heavily on delivery — on building lots of features quickly & efficiently — that teams fail to focus on spending time to discover what the right thing to build is.
How we can do better
It actually doesn't matter whether you actually have a formal retrospective. It doesn't matter whether you have four or five labels of things on your retro board, or exactly how you do the retro. What does matter is the notion of thinking about what we're doing and how we can do better, and it is the team that's doing the work that does this, that is the central thing.
The 'date scrum' anti-pattern
Date Scrum is an R&D pattern where developers are asked to estimate software project requirements upfront for the entirety of the project. After the project is green lighted and the budget is set based on the final estimates, the team then holds daily scrums to status and manage risk as they “iterate” the solution toward the release date. To some, this approach is described as doing Waterfall in sprints.
The fundamental problem with Date Scrum is that the team is de-focused from discovering the best solution. Instead they are heavily focused on delivering Something™ by the Date™. Engineers are problem solvers, and if the primary problem becomes delivering Something™ that will pass QA by the Date™, they will, with enough pressure, solve that exact problem.
That which requires caring
Today's real world of technology is characterized by the dominance of prescriptive technologies.
The temptation to design more or less everything according to prescriptive and broken-up technologies is so strong that it is even applied to those tasks that should be conducted in a holistic way. Any tasks that require caring, whether for people or nature, any tasks that require immediate feedback and adjustment, are best done holistically. Such tasks cannot be planed, coordinated, and controlled the way prescriptive tasks must be.
Prescriptive technologies eliminate the occasions for decision-making and judgment in general and especially for the making of principled decisions. Any goal of the technology is incorporated a priori in the design and is not negotiable.
Manifesto for Agile Software Development
A DefinitionWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile Scrum is not working
The Agile founders had it right, one size doesn't fit all. What the founders perhaps didn’t foresee, or couldn’t agree on, is that in order for the world to scale and consume their wisdom, it had to be packaged as concrete practices, not as abstract classes with virtual methods to be defined in context. And to the proponents of Agile Scrum, give them their due, for their part, they made it concrete – Agile Scrum has been packaged and delivered. Yet much work remains to realize the promise of Agile, which in summary is, the realization of wise use of lightweight development practices and workflows that flexibly adapt to the changing and evolving needs of customers.
Driving engineers to an arbitrary date is a value destroying mistake
An Article by Gandalf HudlowWhat happens when you apply date pressure to software engineers working on high value software projects? The engineers will focus on delivering Something™ by the Date™! This fatal flaw results in delivery of a Something™ full of chaos and features that nobody really wants or needs.
Beware SAFe, an Unholy Incarnation of Darkness
An Article by Sean DexterThe Lean Portfolio Management function that controls funding, are given sole authority to approve which Portfolio Epics move into each stream. Epics are not explanations about a problem that needs to be solved. They are pre-formed ideas about how best to solve those problems.
Right away we can see signs of the old-school mindset of viewing teams as a “delivery” function instead of a strategic one. The high level thinkers come up with ideas, and the low level doers execute on those ideas. Ignored is the possibility that those closest to the work might be best equipped to make decisions about it. Escaping from this misguided mindset is a core goal of Agile thinking that SAFe fails to remotely accomplish.
Why Scrum is killing your product
An Article by Henry LathamDesign Systems, Agile, and Industrialization
An Article by Brad FrostI’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.
In these structures, people are stripped of their humanity as they’re fed into the machine. It becomes “a developer resource is needed” rather than “Oh, Samantha would be a great fit for this project.” And the effect of all this on individuals is depressing. When people’s primary motivation is to move tickets over a column, their ability to be creative or serve a higher purpose are almost completely quashed. Interaction with other humans seems to be relegated to yelling at others to tell them they’re blocked.
Reading “AS PER THE REQUIREMENTS” in tickets makes me dry heave. How did such sterile, shitty language seep into my everyday work?
The value-destroying effect of arbitrary date pressure on code
An Article by Gandalf HudlowThe mandate from above is clear, just get it done! Avoid everything that's in the way: all advice, all expertise, all discovery efforts that detract from hitting the Date™!
What these organizations don't realize is that all software change can be modeled as three components: Value, Filler and Chaos. Chaos destroys Value and Filler is just functionality that nobody wants. When date pressure is applied to software projects, the work needed to remove Chaos is subtly placed on the chopping block. Work like error handling, clear logging, chaos & load testing and other quality work is quietly deferred in favor of hitting the Date™.
Agile is Dead (Long Live Agility)
An Article by Dave ThomasThe word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
…Let’s abandon the word agile to the people who don’t do things. Instead, let’s use a word that describes what we do. Let’s develop with agility.
- You aren’t an agile programmer—you’re a programmer who programs with agility.
- You don’t work on an agile team—your team exhibits agility.
- You don’t use agile tools—you use tools that enhance your agility.
/
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a PlanTraditional companies are losing because they mismanage software engineers
An Article by Emma WattersonInnovation is messy, and frankly Anti-Steve [Jobs] can’t figure out why you wouldn’t just tell people the right thing to build and skip all the trial and error that comes with innovation. Anti-Steve and his board of directors that keep him in place fundamentally believe that they know what needs to be built. Or at least that they can hire the messiah that will come down off the mountain and tell everyone what to build. There is no such messiah.
Why we stopped breaking down stories into tasks
An Article by Adam SilverThe Scrum process says to break down stories into tasks to make estimation easier, encourage collaboration and to be able to show more granular progress during a sprint.
But after a few sprints, we decided to do the next sprint without creating tasks. As a result we drastically increased our velocity and never went back. Here I'll jot down some of the reasons we decided to do this:
- Breaking down stories into tasks is time consuming
- The tasks we came up with invariably would change as we worked on the stories
- Tasks are repetitive
- Tasks were often carried out in parallel
- Our estimates didn't improve
- It decluttered our task board
- It encouraged collaboration throughout the sprint
While we started our process by following Scrum to the letter, we soon realised that breaking down stories into tasks was something that wasn’t worthwhile for us. In the end we realised that it was overplanning and poor use of our time. In the end we used that time to get on with the work and deliver at a significantly faster pace.
Why We Don't Do Daily Stand-Ups at Supercede
An Article by Jezen ThomasYesterday I worked on the widget.
Today I will work on the widget.
I have no blockers.Are you asleep yet? The developers are. You promise them an intellectually stimulating work environment and what they end up with is drudgery.
What value can be had from these meetings anyway? Using “alignment” for justification is so nebulous that it is essentially meaningless. Engineers align themselves. They talk. Especially if you hire good ones (which, you know, you’ll struggle to if you have a culture of coercing them into this kind of busywork). Where does the real discussion happen? It’s written down.
Software that nobody wants
An Article by Gandalf HudlowFinding value is the result of enabling individual and group-level discovery attempts. It's not the result of everyone following one leader's gut.
What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:
- Not wanted - Company specified a solution to a problem that customers don't actually have
- No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
- Incorrect Packaging - Customers need a website, but the company created an iOS app instead
- Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
Making sense of MVP
An ArticleHenrik Kniberg:
The top scenario (delivering a front tire) sucks because we keep delivering stuff that the customer can’t use at all. If you know what you’re doing – your product has very little complexity and risk, perhaps you’ve built that type of thing hundreds of times before – then go ahead and just do big bang. Build the thing and deliver it when done.
Doing It Right
An Article by Brad FrostDoing it right requires a different pace of working and a much broader thought process than “ok, let’s get this thing out the door.” Which is super tough because most workplaces place a huge emphasis on getting things out the door, and fast. Little agile tickets that are expected to be completed in micro sprints to me seem to be antithetical to doing it right.
Planning doesn't make for better software
A Fragment by Robin RendleMy own time in a Silicon Valley startup has proved this much to be true; planning doesn’t make for better software. In fact today our design systems team doesn’t have sprints, we don’t have tickets or a daily standup. Each day we come to work, figure out what’s the most important thing that we could be doing, and then we—gasp!—actually do it.
Watching so many other teams slowly flail about whilst they plan for quarter 3.2 of subplan A, whilst our team produces more work in a week than they all do combined in a quarter has been shocking to me.
After four years of working in a large startup, I know what I always assumed was true: you don’t need a plan to make a beautiful thing. You really don’t. In fact, there’s a point where overplanning can be a signal of inexperience and fear and bullshit. The scrum board and the sprints and the inane meetings each and every day are not how you build another Super Mario 64.
Instead all you have to do is hire smart people, trust them to do their best work, and then get the hell out of their way.
Agile as Trauma
An Essay by Dorian TaylorThe Agile Manifesto is an immune response on the part of programmers to bad management.
Yagni
A Definition by Martin FowlerYagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from Extreme Programming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".
The State of Agile Software in 2018
A Talk by Martin FowlerOn the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects).
Product vs. Feature Teams
An Article by Marty CaganThis article is certain to upset many people.
The Battle for the Life and Beauty of the Earth
- Two generating systems
- Two types of building production
- System A
- System B
- This has harmed modern society greatly
Two generating systems
Imagine a town of type "A" — a neighborhood, if you like, and allow yourself to consider that it has the quality of birds, moss-grown stones, waves breaking on a small shore, pools in which crabs and shells present themselves. Because of the depth and scope of its structure, this world is almost infinite in its richness.
Compare this imagined town with a more usual neighborhood of type "B", typical of modern property development, where there is a stale and ugly air of repetition. Even when variation is attempted, this variation does not flow from the reality of living. Rather it is manufactured variety — an attempt to create something interesting. But what we feel instead is something flat, without excitement, without the urgent joy of life.
These two kinds of places, then, A and B, are typically generated in two different ways. We may therefore call these two different generating systems A and B.
Two types of building production
There are, loosely speaking, two types of building production. Type A is a type of production which relies on feedback and correction, so that every step allows the elements to be perfected while they are being made. This is not unlike the way a good cook tastes a soup while cooking it, checking it, modifying it, until it tastes just right. Type B is a type of production that is organized by a fixed system of rigidly prefabricated elements, and the sequence of assembly is much more rigidly preprogrammed. This type became commonplace in the 20th century, and is still widely used.
System A
System A is concerned with the well-being of the land, its integrity, the well-being of the people and plants and animals who inhabit the land. This has very much to do with the integral nature of plants, animals, and water resources, and with the tailoring of each part of every part to its immediate context, with the result that the larger wholes, also, become harmonious and integral in their nature.
System B
System B is concerned with efficiency, with money, with power and control. Although these qualities are less attractive, and less noble than the concerns of System A, they are nevertheless important. They cannot be ignored. If we are traveling in an airplane, or a high-speed train, we shall often be very glad that this system is constructed under the guidance of some version of system B.
This has harmed modern society greatly
System A places emphasis on subtleties, finesse, on the structure of adaptation that makes each tiny part fit into the larger context. System B places emphasis on more gross aspects of size, speed, profit, efficiency, and numerical productivity.
However, during the last hundred and fifty years, because of choices that nations and states have made in modern times, System B has become the dominant production system for the environment (for land and towns and regions), largely to the exclusion of System A. This has harmed modern society greatly.
Arcade
Here is an interior street on the Eishin campus, with an arcade opening from the back of the classroom buildings. The arcade steps up as the street goes along the slope. Because the natural contours of the land are preserved, the arcade jumps up, in small increments, as it goes along. Steps are inserted where needed; and in plan, too, the arcade follows a gentle series of curves and bends, following the natural character of the land.
This aspect of a street is not usually present in large construction projects, which typically destroy the natural character of the land, and tend to start with a blank "page" that has been created by perfect grading and flattening.
Transmitted through drawings
Architecture is now only transmitted through drawings. The typical architect does not personally know how to make anything — not buildings, not windows, not floors or ceilings. He or she draws drawings. Some other organization then produces buildings from these drawings. We are, by now, so deeply enmeshed in this way of thinking, that it doesn't sound like idiocy.
The life-giving continuum
In System A, creation and production are organic in character, and are governed by human judgments that emanate from the underlying wholeness of situations, conditions, and surroundings.
In System B, the production process is thought of as mechanical. What matters are regulations, procedures, categories, money, efficiency, and profit: all the machinery designed to make society run smoothly, as if society was working as a great machine. The production process is rarely context-sensitive. Wholeness is left out.
Identifying these two categories helps us sharpen and clarify the range of differences among ways of creating the environment that exist in different societies. And the two categories serve to identify a dimension of great importance: the dimension that runs from more life-giving to less life-giving.
Blueprints
Blueprints lead to the making of things that are abstract, not always based on reality. Once something becomes abstract, it breeds disconnectedness — separation and the inability to connect with our surroundings. People buy houses from blueprints, but then don't like the actual house: "What on earth is this? I had no idea it was going to be like this...etc."
Hopes and dreams
The very first thing we did was spend two weeks just talking to different teachers and students, to get a feeling for their hopes and dreams. These talks were one-on-one and often lasted about an hour, for any one interview, during which we asked questions, talked, probed, explored dreams of an ideal campus, and tried to understand each person's deepest visions as a teacher, or as a student. We asked people about their longings, and their practical needs. We asked them to close their eyes and imagine themselves walking about in the most wonderful campus they could imagine.
Mixed use
Pattern 5.5 – Every sports field is always attached to some building which has nothing to do with the particular sports function. Thus, for instance, the tennis courts may be next to the art studio, and placed so that people entering the art studio are just at that place where the tennis court is most enjoyable to watch.
Secret garden
Pattern 7.7 – There is also one garden, so secret, that it does not appear on any map. The importance of the pattern is that it must never be publicly announced, and must not be in site plan. Except for a few, nobody should be able to find it.
In the mind's eye
In System A, it is always the wholeness of the place that matters. To intensify the wholeness of any place — whether it consists of existing buildings in a town, or of virgin land that is largely unbuilt — proposed construction and buildings must be decided, and that means "felt" and thought through on the site itself. It is really not possible to do it any other way, since the relationships which exist between the buildings and the world around them are complex and subtle.
On a drawing or a plan, one simply does not see enough. The drawn plan does not give enough information. So trying to make decisions by drawing on a plan is doomed to failure. To produce a plan that has reality, and to bring the actual place itself to life, decisions are made gradually, on the site itself, under circumstances where one visualizes the situation as the whole it really is. Step by step, this brings building positions to life in the mind's eye — and so, in imagination, one conceives the buildings literally, in their full size and volume as they are really going to be.
Simulacra and simulation
The situation of contemporary construction is more likely to be that a building still gets its character first as an image, drawn on paper, by an architect's fantasy, a simulacrum which is then physically built in cheap and flimsy studs and sheetrock, concrete panels, cardboard — or in whatever conventional system of construction the contractor has on hand.
Sadly, this is where the dull, lifeless, and stereotyped character of buildings in the 20th century mainly came from. It is also, at the same time, where the wild and fantastic egotistical shapes of the present era come from. They are conceived and carried out as images, or part-images, not as built, solid, made works. These papery, System B things are not conceived and made for the sake of their material reality. The feeling one gets in the presence of these buildings does not fill the onlooker with the beauty or the presence of the material substance.
Power law
Buildings which most profoundly communicate subtle harmony are composed of a complex mixture of materials, with the overall amounts of different materials jumping in a calibrated cascade — typically according to a power law. The relative proportions — the statistical distribution of materials by quantity of total visible area — is critical. It is this specific distribution, not just the mixture, which creates depth of feeling.
Elements of Eishin
Each of the elements in the following list were essential to the creation of every space and every building at Eishin:
- The way each building relates to its surroundings, as well as the ground on which it stands.
- The geometry directed by its position in the whole and its function.
- Working with people who will inhabit the spaces.
- The immensely detailed use of models and experiments.
- The search for beautiful materials and ways of making the buildings that should stand there.
- The careful use of money in a manner that reflects the values of the endeavor.
- Creation of positive space, at every turn, and every scale.
- Placing materials between other nearby materials that are similar, and wedging harmonious materials in-between.
- Interlocking spatial links forming a two-dimensional sheet of courtyards, buildings, and openings.
Our responsibility
As makers of buildings, we architects must start now,
with a fundamental change of direction.
For the last hundred years or so, we have understood
building to be an art in which an architect draws a building,
and a contractor then builds that building from the
architect's plans.
But a living environment cannot be built
successfully this way.To achieve a successful building — one that has life — we
must focus our attention on all the crafts and processes,
and then, as architects, ourselves take direct charge
of the making.
We must take full responsibility
for the entire building process, ourselves.
Unfolding
In short, the architect is responsible for building construction, is watching the building unfold continuously, and is making ongoing modifications as it becomes clear from each given stage, what modifications and changes should be made at each moment. And this is all to be done within a management framework that controls budget and cost very tightly.
Direct management
Direct Management does not include or permit the concept of profit to occur. The management is fee-based, or based as a fixed salary, and all construction costs are fixed ahead of time, and the building design is modified during construction, to make up any over-runs. The manager is not able to move money around at will, or put it in their pocket. At the same time, the design is approximately fixed, but with the understanding that it may be changed, during the evolution of the building, so that subtle adaptations can be included in the emerging building. In the Direct Management method it is the architect themselves and the direct manager who together manage the building works and all on-site construction for the owner.
The problem of schedule
We have emphasized, from the beginning, that in order to achieve really profound quality in this project, it is necessary to be able to modify it continuously, during the process of construction. This in turn requires that the Manager is alive to the fact that important decisions are being faced at every stage, and is aware that one of the most important things that is happening, is the evolution of the building designs, while they are being built.
We have a strong intuition that a general contractor will interfere with this process, no matter what is said in advance. The reason is this: All the large general contractors we have interviewed are strongly oriented to the problem of schedule. Of course, this is one of their strengths. However, we are convinced that they are so strongly oriented to this problem, that they will ultimately kill the life of the project, in order to achieve enough management control to be able to guarantee schedule.
We must get our hands dirty!
We must get our hands dirty!In every work of architecture, the construction details are the heart of the project, and the true makers of the project are the ones who make the details, who make the materials directly, and who are not afraid to get dirt
under their fingernails.
We feel it in our fingers
In System A, there is no architect separate from the contractor. We are builders, simply. As builders, we have a direct feeling about construction. We feel it in our fingers, so it is down to earth. One result of this down-to-earth quality is that everything is somewhat experimental. We make experiments all the time. Sometimes we place a piece of wood this way. Another time, we may like to try it that way. Any time something new comes up in the design of a building, we are very likely to try and invent the best way of building it. This is not a great big invention. Just a simple invention, the way we might invent a way of tying a piece of string, to hold a broken toy together. It is just practical.
Four principles
The essential purpose of Direct Management, as we understand the term, is to create buildings which are whole. This means that each part of the building is right in relation to the other parts, and to the part of the land that makes the buildings and the land more beautiful.
I will try to summarize the real meaning of Direct Management.
- The design evolves during construction. This means that the form of control over designs does not stop when drawings are finished, but goes on, continuously, before, during, and after construction. This cannot be done if architect and contractor are separate, or consider their jobs separately. It will only happen if the person who controls the design at the beginning actually controls the construction, too.
- Flexible cost control. Cost control requires continuous changing of ideas about what is built, in relation to money that is available, and in relation to what has been done already.
- Experience with one's hands. It is also impossible for an architect to have enough knowledge to control the process successfully, unless they have experienced almost every phase of construction with their own hands.
- Love of craft and the joy in the physical process of making. In the old days, making a building was clearly understood as a work of making. In this word, designing and physically building are inseparable. However, in the modern world, design has become separated from construction. Architects think of their work as designing, on paper, with the idea that the building process is a separate process. This is not what I call making at all. A good building can only be created, when it is deeply understood as something which is made, by a direct connection of the act of making, and the act of feeling, with your hands.
Guided by image
In our minds, the drawings we had originally made for the columns and capitals were no more than first approximations of the final shapes. We assumed that we would work out the real shapes during construction, and left the inaccurate approximations on our drawings, just for the sake of the building permit. Fujita, used to working with architects in System B, assumed that whatever was on our drawings must be what we wanted, and must be implemented as drawn.
Anybody who was making those column capitals, if they had seen this "double" capital, and had been free to make something harmonious, would have done it differently. But Fujita's people, in System B, did not know how to be guided by reality. They were guided by "image".
So Fujita, in this situation, was not free to respond in a natural way to what they saw. They were trapped by the image-making process they were used to. But because of this, they doomed their own carpenters to a pretentious kind of slavery, producing whatever silly images they were told to do, without being able to ask themselves whether they were beautiful, and unable to use their own sense of reality to make them better.
Invisible substance
We wanted wood, not only in many visible places, but also in the roof trusses of the homeroom buildings, where they are invisible. Fujita wanted to replace the invisible trusses with steel trusses. They could not understand the idea that it was the actual substance — even though not visible — which would control the feeling of the thing.
A practical and sacred act
The emotional energy of a building can be achieved, only if the artists who make and shape the building are genuinely responsible for the way the building gets its shape. To put this another way around, it means that if we fail to take the practical responsibility for the acts of shaping, the emotional energy of the building will almost certainly be false. If the emotional quality of the building is to be alive, and is to be seen, understood, and felt by the people who live there or work there, then this task must not be handed on to someone else. The life and magnificence of the buildings will come to fruition only if we architects, or master builders, or artists — or for that matter, lay people — any of us — take on the task of shaping as a practical and sacred act.
In the walls and mosses
If we reach such a very ordinary state of daily life, and then back it up with building and construction that comes from the depths in us, then that gradually accumulates our value in the world, all of us together as a whole. Later, then, perhaps hundreds of years later, people will look back at our stones and say to themselves, "My word, those people way back then — they certainly knew how to live," and they would say this because they could see the lingering whispers in the walls and mosses, and could read them, and could treasure them, and would learn from these traces how to live like that again.
Melt
In many late 20th century buildings, the architect focused attention on a few strongly defined elements. Usually, the way the building stood out in its surroundings was very sharp, and intentionally separated from the buildings that surround it.
Real architecture comes about in a different way. If the architecture is real, there will be thousands of living centers; many of them modest, all of them having direct impact on human beings. In this condition, there is an overall wholeness in the building and the zones nearby, but this quality is not aggressive nor too sharp. It rather creates a condition where the building melts into the town, or street, or garden where it is placed.
Umbrella
From the curator's visit to a place that captures all the beauty, depth, and wholeness it attempts.