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.
Introduction to Permaculture
The conscious design and maintenance of agriculturally productive systems which have the diversity, stability, and resilience of natural ecosystems. It is the harmonious integration of the landscape with people providing their food, energy, shelter and other material and non-material needs in a sustainable way.
About Permaculture
The word Permaculture is taken from the Latin Permanens–meaning to endure of persist through time and cultura–referring to cultures–coming together. Permaculture is an interdisciplinary design science in the field of sustainable system design, with sustainable defined as:
a system which over its lifetime produces energy equivalent to or in excess of what it consumes.
Permaculture ethics
Permaculture operates on three:
- Care of Earth
- Care of Species
- Return of Surplus to the first two
Using akido on the landscape
I have spoken, on a more mundane level, of using akido on the landscape, of rolling with the blows, turning adversity into strength, and using everything positively. The other approach is to karate the landscape, to try to make it yield by using our strength, and striking many hard blows. But if we attack nature we attack (and ultimately destroy) ourselves.
Permaculture principles
There are two basic steps to good permaculture design. The first deals with laws and principles, while the second is more closely associated with practical techniques.
The principles are inherent in any permaculture design, in any climate, and at any scale. They are, briefly:
- Relative location: every element is placed in relationship to another so that they assist each other
- Each element performs many functions.
- Each important function is supported by many elements.
- Efficient energy planning for house and settlement.
- Emphasis on the use of biological resources over fossil fuel resources.
- Energy recycling on site.
- Using and accelerating natural plant succession to establish favourable sites and soils.
- Polyculture and diversity of beneficial species for a productive, interactive system.
- Use of edge and natural patterns for best effect.
Design is a connection between things
The core of permaculture is design. Design is a connection between things. It's not water, or a chicken, or the tree. It is how the water, the chicken and the tree are connected. It's the very opposite of what we are taught in school. Education takes everything and pulls it apart and makes no connections at all. Permaculture makes the connection, because as soon as you've got the connection you can feed the chicken from the tree.
To enable a design component to function efficiently, we must put it in the right place.
Inputs and outputs
For things to work properly, we must remember that:
- The inputs needed by one element are supplied by other elements in the system; and
- The outputs needed by one element are used by other elements (including ourselves).
Each element performs many functions
Each element in the system should be chosen and placed so that it performs as many functions as possible.
Each important function is supported by many elements
Important basic needs such as water, food, energy, and fire protection should be served in two or more ways.
The wild energies
Sectors deal with the wild energies, the elements of sun, light, wind, rain, wildfire, and water flow. These all comes from outside our system and pass through it. For these, we arrange a sector diagram based on the real site, usually a wedge-shaped area that radiates from a centre of activity.
Elements are placed according to intensity of use, control of external energies, and efficient energy flow.
Turn them into cycles
Permaculture systems seek to stop the flow of nutrient and energy off the site and instead turn them into cycles, so that, for instance, kitchen wastes are recycles to compost; animal manures are directed to biogas production or to the soil; household greywater flows to the garden; green manures are turned into the earth; leaves are raked up around trees as mulch.
Time stacking
The British devised a system of farming in which pastures were broken up after the animals had been on them a few years. The pasture was plowed up and put into a high nutrient-demand crop, followed by a grain crop, followed by a root crop. One year it was left fallow to rest the soil. This was sustainable, but it took a long time to cycle.
Masanobu Fukuoka, that master strategist, deals with time stacking. He does not have to follow, because he never removes the main part of the crop from the soil. He starts the next crop before the last crop is finished.
The garden is a riot
In conventional agriculture, vegetation is kept at the weed or herb level using energy to keep it cut, weeded, tilled, fetilised, and even burnt; that is, we are constantly setting the system back and incurring work and energy-costs when we stop natural succession from occurring.
Instead of fighting this process, we can direct and accelerate it to build our own climax species in a shorter time.
There is no attempt to form the garden into strict neat rows; it is a riot of shrubs, vines, garden beds, flowers, herbs, a few small trees, and even a small pond. Paths are sinuous, and garden beds might be round, key-holed, raised, spiraled, or sunken.
We should not confuse order and tidiness
To the observer, this may seem like a very unordered and untidy system; however, we should not confuse order and tidiness. Tidiness separates species and creates work, whereas order integrates, reducing work and discouraging insect attack. European gardens, often extraordinarily tidy, result in functional disorder and low yield. Creativity is seldom tidy.
Perhaps we could say that tidiness is something that happens when compulsive activity replaces thoughtful creativity.
The number of ways in which things work
The importance of diversity is not so much the number of elements in a system; rather it is the number of functional connections between these elements. It is not the number of things, but the number of ways in which things work.
Species guilds
Guilds are made up of a close association of species clustered around a central element (plant or animal). This assembly acts in relation to the element to assist its health, aid in management, or buffer adverse environmental effects.
An edge is an interface
An edge is an interface between two mediums. Edges are places of varied ecology. There is hardly a sustainable traditional human settlement that is not sited on those critical junctions of two natural economies. Successful and permanent settlements have always been able to draw from the resources of at least two environments.
An edge is a sieve
The edge (boundary) acts as a net or sieve: energies or materials accumulate at edges, e.g. soil and debris are blown by wind against a fence; seashells form a line at the tide-marks on a beach; leaves accumulate at kerbsides in a city.
Everything works both ways
Disadvantages can be viewed as "problems" and we can take an energy-expensive approach to "get rid of the problem", or we can think of everything as being a positive resources: it us up to us to work out just how we can make use of it.
"Problems" can be intractable weeds, huge boulders lying on the perfect house site, and animals eating garden and orchard produce. How can we turn these into useful components of our system? Boulders on the perfect house site, for example, can be incorporated into the house itself, for beauty and as a heat storage system.
The quality of thought
It is the quality of thought and the information we use that determines yield, not the size or quality of the site.
Let the goals suggest themselves
There are several ways to start the design process, depending on your nature and needs. You can start out by defining your goals, as precisely as possible, and then look at the site with these goals in mind. Or you can take the site with all its characteristics (both good and bad), and let goals suggest themselves. Of the two questions—"What can I make this land do?"—or—"What does this land have to give me?"—the first may lead to exploitation of the land without regard to long-term consequences, while the second to a sustained ecology guided by our intelligent control.
Maps and observation
Maps are useful only when they are used in combination with observation. Never try to design a site by just looking at a map, even if it is thoroughly detailed with contour lines, vegetation, erosion gullies, and so on marked in.
Maps are never representative of the complex reality of nature. Remember, "The map is not the territory."
Reading the landscape
As we walk about a site and talk to people, we can note our observations. At this stage, we try to store the information we gain in some accurate way, carry a notebook, or a camera and tape-recorder, and make small sketches. The notes we end up with can later be used to devise design strategies.
We do not just see and hear, smell and taste, but we sense heat and cold, pressure, stress from efforts of hill-climbing or prickly plants, and find compatible or incompatible sites in the landscape. We note good views, outlooks, soil colours and textures. In face, we use (consciously) all our many senses and become aware of our bodies and responses.
Beyond this, we can sit for a time and notice patterns and processes: how some trees prefer to grow in rocks, some in valleys, others in grasslands or clumps. We see how water flows on the site, where fires have left scars, winds have bent branches or deformed the shape of trees, how the sun and shadows move, and where we find signs of animals resting, moving, or feeding. The site is full of information on every natural subject, and we must learn to read it well.
The group of blind mullahs
In a natural landscape, each element is part of the greater whole, a sophisticated and intricate web of connections and energy flows. If we attempt to create landscapes using a strictly objective viewpoint, we will produce awkward and dysfunctional designs because all living systems are more than just a sum of their parts. Our culture has tried to define the landscape scientifically, by collecting extensive data about its parts.
These methods are much like the group of blind mullahs in the Sufi tale, who try to describe an elephant.
If you have to do tedious work
If you have to stand somewhere doing tedious work, at least make it interesting.
The perverse arrangement of older houses
The main problem lies in the often perverse arrangement of older houses, which face the road rather than the sun, and in the mania for glass windows on all outside walls.
Always start at the doorstep
If you are having trouble knowing where to start, always start at the doorstep.
The American lawn
The American lawn uses more resources than any other agricultural industry in the world. The American lawn could feed continents if people had more social responsibility.
Why should it be indecent to have anything useful in the front half of your property or around the house where people can see it? Why is it low-status to make that area productive? The condition is peculiar to the British landscaping ethic; what we are really looking at here is a miniature British country estate, designed for people who had servants. It has become a cultural status symbol to present a non-productive facade. The lawn and its shrubbery is a forcing of nature and landscape into a salute to wealth and power, and has not other purpose or function.
The only thing that such designs demonstrate is that power can force men and women to waste their energies in controlled, menial, and meaningless toil.
From consumption to production
I see no other solution (political, economic) to the problems of mankind than the formation of small responsible communities involved in permaculture and appropriate technology. I believe that the days of centralised power are numbered, and that a re-tribalisation of society is an inevitable, if sometimes painful, process.
The greatest change we need to make is from consumption to production, even if on a small scale, in our own gardens.
People who force nature force themselves
People who force nature force themselves. When we grow only wheat, we become dough. If we seek only money, we become brass; and if we stay in the childhood of team sports, we become a stuffed leather ball.
To become a complete person, we must travel many paths, and to truly own anything, we must first of all give it away.
Eaves and sun