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 Timeless Way of Building
- Mind of no mind
- The quality without a name
- An objective matter
- Bitterness
- The most precious thing we ever have
Mind of no mind
To you, mind of no mind, in whom the timeless way was born.
The quality without a name
There is a central quality which is the root criterion of life and spirit in a man, a town, a building, or a wilderness. This quality is objective and precise, but it cannot be named.
There are words we use to describe this quality:
alive
whole
comfortable
free
exact
egoless
eternalBut in spite of every effort to give this quality a name, there is no single name which captures it.
An objective matter
We have been taught that there is no objective difference between good buildings and bad, good towns and bad.
The fact is that the difference between a good building and a bad building, between a good town and a bad town, is an objective matter. It is the difference between health and sickness, wholeness and divided ness, self-maintenance and self-destruction. In a world which is healthy, whole, alive, and self-maintaining, people themselves can be alive and self-creating. In a world which is unwholesome and self-destroying, people cannot be alive: they will inevitably themselves be self-destroying, and miserable.
Bitterness
The quality which has no name includes these simpler, sweeter qualities. But it is so ordinary as well, that it somehow reminds us of the passing of our own life.
It is a slightly bitter quality.
The most precious thing we ever have
In our lives, this quality without a name is the most precious thing we ever have.
And I am free to the extent I have this quality in me.
When our forces are resolved
When a person’s forces are resolved, it makes us feel at home, because we know, by some sixth sense, that there are not other unexpected forces lurking underground. He acts according to the nature of the situations he is in, without distorting them. There are no guiding images in his behavior, no hidden forces; he is simply free. And so, we feel relaxed and peaceful in his company.
Each of us knows from experience the feeling which this quality creates in us.
And for this reason, each one of us can also recognize this quality when it occurs in buildings.
Patterns of life
If I consider my life honestly, I see that it is governed by a certain very small number of patterns of events which I take part in over and over again.
Being in bed, having a shower, having breakfast in the kitchen, sitting in my study writing, walking in the garden, cooking and eating our common lunch at my office with my friends, going to the movies, taking my family to eat at a restaurant, having a drink at a friend’s house, driving on the freeway, going to bed again. There are a few more.
There are surprisingly few of these patterns of events in any one person’s way of life, perhaps no more than a dozen.
When I see how few of them there are, I begin to understand what huge effect these few patterns have on my life, on my capacity to live. If these few patterns are good for me, I can live well. If they are bad for me, I can’t.
Fabric
And finally, the things which seem like elements dissolve, and leave a fabric of relationships behind, which is the stuff that actually repeats itself, and gives the structure to a building or a town.
They are the atoms of our man-made universe
Further, each pattern in the space has a pattern of events associated with it. We realize then that it is just the patterns of events in space which are repeating, and nothing else. Nothing of any importance happens in a building or a town except what is defined within the patterns which repeat themselves.
Each building gets its character from just the patterns which keep on repeating there.
Each neighborhood is defined, too, in everything that matters, by the patterns which keep on repeating there.
Forces of conflict
A pattern which prevents us from resolving our conflicting forces leaves us almost perpetually in a state of tension.
For, if we live in a world where work is separated from family life, or where courtyards turn us away, or where windows are merely holes in the wall, we experience the stress of these inner and conflicting forces constantly. We can never come to rest. We are living then, in a world so made, so patterned, that we cannot, by any stratagem, defeat the tension, solve the problem, or resolve the conflict. In this kind of world the conflicts do not go away. They stay within us, nagging, tense…The build-up of stress, however minor, stays within us. We live in a state of heightened alertness, higher stress, more adrenaline, all the time.
The multiplicity of living patterns
The more living patterns there are in a thing—a room, a building, or a town—the more it comes to life as an entirety, the more it glows, the more it has this self-maintaining fire, which is the quality without a name.
To fly past each other
In our own lives, we have the quality without a name when we are most intense, most happy, most wholehearted.
This comes about when we allow the forces we experience to run freely in us, to fly past each other, when we are able to allow our forces to escape the locked-in conflict which oppresses us.
But this freedom, this limpidity, occurs in us most easily when we are in a world whose patterns also let their forces loose. Just as we are free when our own forces run most freely within us, so the places we are in are also free when their own forces themselves run free, and are themselves resolved.
The quality without a name in us, our liveliness, our thirst for life, depends directly on the patterns in the world, and the extent to which they have this quality themselves.
Patterns which live, release this quality in us.
But they release this quality in us, essentially because they have it in themselves.When a building has this fire
And when a building has this fire, then it becomes a part of nature. Like ocean waves, or blades of grass, its parts are governed by the endless play of repetition and variety, created in the presence of the fact that all things pass. This is the quality itself.
Modularity
One of the most pervasive features of these buildings is the fact that they are “modular.” They are full of identical concrete blocks, identical rooms, identical houses, identical apartments in identical apartment buildings. The idea that a building can - and ought - to be made of modular units is one of the most pervasive assumptions of twentieth-century architecture.
Nature is never modular. Nature is full of almost similar units (waves, raindrops, blades of grass) - but though the units of one kind are all alike in their broad structure, no two are ever alike in detail.
The same broad features keep recurring over and over again. And yet, in their detailed appearance these broad features are never twice the same.
It is going to pass
The character of nature can’t arise without the presence and the consciousness of death.
When we make our own attempt to create nature in the world around us, and succeed, we cannot escape the fact that we are going to die. This quality, when it is reached, in human things, is always sad; it makes us sad; and we can even say that any place where a man tries to make the quality, and be like nature, cannot be true, unless we can feel the slight presence of this haunting sadness there, because we know at the same time we enjoy it, that it is going to pass.
The gate
To reach the quality without a name we must build a living pattern language as a gate.
The patience of a craftsman
Here there is no mastery of unnameable creative processes, only the patience of a craftsman, chipping away slowly; the mastery of what is made does not lie in the depths of some impenetrable ego; it lies, instead, in the simple mastery of the steps in the process, and in the definition of these steps.
An infinite variety
The people can shape buildings for themselves, and have done it for centuries, by using languages which I call pattern languages. A pattern language gives each person who uses it, the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences.
Each pattern is a rule
Each pattern is a rule which describes what you have to do to generate the entity which it defines. It is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.
There is an imperative aspect to the pattern. The pattern solves a problem. It is not merely “a” pattern, which one might or might not use on a hillside. It is a desirable pattern; and for a person who wants to farm a hillside, and prevent it from erosion, he must create this pattern, in order to maintain a stable and healthy world. In this sense, the pattern not only tells him how to create the pattern of terracing, if he wants to; it also tells him that it is essential for him to do so, in certain particular contexts, and that he must create this pattern there.
It is in this sense that the system of patterns forms a language.
The network of connections
Each pattern depends both on the smaller patterns it contains, and on the larger patterns within which is is contained. Each pattern sits at the center of a network of connections which connect it to certain other patterns that help to complete it. It is the network of these connections between patterns which creates the language.
The grammar of the language
An ordinary language like English is a system which allows us to create an infinite variety of one-dimensional combinations of words, called sentences. A pattern language is a system which allows its users to create an infinite variety of those three-dimensional combinations of patterns which we call buildings, gardens, towns.
It tells us which arrangements of words are legitimate sentences, in a given situation, and which are not. And, furthermore, which arrangements of words make sense in any given situation, and which ones don’t. It narrows down the total possible arrangements of words which would make sense in any given situation.
Second, it actually gives us a system which allows us to produce these sentences which make sense. So, it not only defined the sentences which make sense in a given situation; it also gives us the apparatus we need to create these sentences. It is, in other words, a generative system, which allows us to generate sentences that are appropriate to any given situation.
Rules of thumb
Of course, these patterns do not come only from the work of architects or planners.
Architects are responsible for no more than perhaps 5 percent of all the buildings in the world. Most buildings, streets, shops, offices, rooms, kitchens, cafes, factories, gas stations, freeways, bridges… which give the world its form, come from an entirely different source.
They come from the work of thousands of different people. Each of them builds by following some rules of thumb. And all these rules of thumb - or patterns - are part of larger systems which are languages. Every person has a pattern language in his mind. This is true of any great creative artist, as of the humblest builder.
At the moment when a person is faced with an act of design, he does not have time to think about it from scratch. Even when a person seems to “go back to the basic problem,” he is still always combining patterns that are already in his mind.
It is only because a person has a pattern language in his mind, that he can be creative when he builds. The rules of English make you creative because they save you from having to bother with meaningless combinations of words. A pattern language does the same.
Ordinariness
We have a habit of thinking that the deepest insights, the most mystical, and spiritual insights, are somehow less ordinary than most things - that they are extraordinary.
In fact, the opposite is true: the most mystical, most religious, most wonderful – these are not less ordinary than most things – they are more ordinary than most things. And it is because they are so ordinary, indeed, that they strike to the core.
A genetic process
The mere use of pattern languages alone does not ensure that people can make places live.
The fact is, that the creation of a town, and the creation of the individual buildings in a town, is fundamentally a genetic process. So long as the people of society are separated from the language which is being used to shape their buildings, the buildings cannot be alive.
Discovering patterns
In order to discover patterns which are alive we must always start with observation.
Try to discover some property which is common to all the solutions which feel good, and missing from all the ones which don’t feel good.
Knowledge of the problem then helps shed light on the invariant which solves the problem.
Sometimes we find our way to this invariant by starting with a set of positive examples.
At other times, we may discover the invariant by starting from the negative examples, and resolving them.
Occasionally, we do not start from concrete observation at all, but build up the invariant by purely abstract argument.How things ought to be
It is hard to give up preconceptions of what things “ought to be,” and recognize things as they really are.
You must make the language first
It is the structure and content of the language which determine the design. The individual buildings which you make will live, or not, according to the depth and wholeness of the language which you use to make them with.
One you have it, this language is general. If it has the power to make a single building which lives, it can be used a thousand times, to make a thousand buildings live.
It must constantly be re-created
A language is a living language only when each person in society, or in the town, has his own version of this language.
To reach this deeper state, in which each person has a pattern language in his mind as an expression of his attitude to life, we cannot expect people just to copy patterns from a book. A living language must constantly be re-created in each person’s mind. As he modifies his language, and improves it, depends it, throughout his life - he does it, always, by creating, and improving rules which he invents.
Once people share a language in this way, the language will begin evolving of its own accord. The language will evolve, because it can evolve piecemeal, one pattern at a time. As people exchange ideas about the environment, and exchange patterns, the overall inventory of patterns in the pattern pool keeps changing.
Of course, this evolution will never end.
Repair
Within the larger language, it is impossible for any act not to help repair the larger whole. It is impossible for any act of building to remain an isolated act: it always becomes a portion of the flux of acts which is helping to maintain the whole.
Even the laying of a brick, to mend a wall, will not only be used to mend that wall, but will be used to help repair the seat, the terrace, or the fireplace which that wall helps to form.
The process of unfolding
The sequence of the patterns for a design - as generated by the language - is therefore the key to that design.
The process of unfolding goes step by step, one pattern at a time.
Chopped and disfigured
The details of a building cannot be made alive when they are made from modular parts
If the builder wants to build the room from modular four-foot panels, he must change the size of the rooms, and change their shape, to fit his panels.
In such a building system, it is impossible for a person to create a plan which reflects the larger subtleties of site or plan. Each plan will always be chopped and disfigured to make it fit the building details.
To make the building live, its patterns must be generated on the site, so that each one takes its own shape according to its context.
Until we leave the gate behind
And yet the timeless way is not complete, and will not fully generate the quality without a name, until we leave the gate behind.
Indeed this ageless character has nothing, in the end, to do with languages. The language, and the processes which stem from it, merely release the fundamental order which is native to us. They do not teach us, they only remind us of what we know already, and of what we shall discover time and time again, when we give up our ideas and opinions, and do exactly what emerges from ourselves.
At this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real. It is the gate which leads you to the state of mind, in which you live so close to your own heart that you no longer need a language.
This is the final lesson of the timeless way.