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.
Wikipedia
The Pareto principle
The Pareto principle (also known as the 80/20 rule, the law of the vital few, or the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes.
Concrete poetry
Concrete poetry is an arrangement of linguistic elements in which the typographical effect is more important in conveying meaning than verbal significance.
Pinkas Synagogue
Names of the Holocaust victims from Czech lands on the synagogue's inner wall.
During reconstruction in 1950–1954, the original floor-level as well as the appearance of the synagogue were restored. In following five years, the walls of the synagogue were covered with names of about 78,000 Bohemian and Moravian Jewish victims of Shoah. The names are arranged by communities where the victims came from and complemented with their birth and death date.
Saudade
Saudade is a deep emotional state of nostalgic or profound melancholic longing for an absent something or someone that one cares for and/or loves. Moreover, it often carries a repressed knowledge that the object of longing might never be had again.
Transclusion
In computer science, transclusion is the inclusion of part or all of an electronic document into one or more other documents by hypertext reference. Transclusion is usually performed when the referencing document is displayed, and is normally automatic and transparent to the end user. The result of transclusion is a single integrated document made of parts assembled dynamically from separate sources, possibly stored on different computers in disparate places.
Transclusion facilitates modular design: a resource is stored once and distributed for reuse in multiple documents. Updates or corrections to a resource are then reflected in any referencing documents. Ted Nelson coined the term for his 1980 nonlinear book Literary Machines, but the idea of master copy and occurrences was applied 17 years before, in Sketchpad.
Phonaesthetics
Phonaesthetics is the study of beauty and pleasantness associated with the sounds of certain words or parts of words. The term was first used in this sense, perhaps by J. R. R. Tolkien, during the mid-twentieth century and derives from the Greek: φωνή (phōnē, "voice-sound") plus the Greek: αἰσθητική (aisthētikē, "aesthetic").
Rage rooms
A rage room, also known as a smash room or anger room, is a business where people can vent their rage by destroying objects within a room.
Truchet Tiles
Truchet tiles are square tiles decorated with patterns that are not rotationally symmetric. When placed in a square tiling of the plane, they can form varied patterns, and the orientation of each tile can be used to visualize information associated with the tile's position within the tiling.
Wang tiles
Wang tiles (Hao Wang, 1961) are a class of formal systems. They are modelled visually by square tiles with a color on each side. A set of such tiles is selected, and copies of the tiles are arranged side by side with matching colors, without rotating or reflecting them.
The basic question about a set of Wang tiles is whether it can tile the plane or not, i.e., whether an entire infinite plane can be filled this way. The next question is whether this can be done in a periodic pattern.
In 1966, Wang's student Robert Berger solved the problem in the negative. He proved that no algorithm for the problem can exist, by showing how to translate any Turing machine into a set of Wang tiles that tiles the plane if and only if the Turing machine does not halt. The undecidability of the halting problem then implies the undecidability of Wang's tiling problem.
The linear city
The linear city was an urban plan for an elongated urban formation. The city would consist of a series of functionally specialized parallel sectors.
As the city expanded, additional sectors would be added to the end of each band, so that the city would become ever longer, without growing wider.
Tactical urbanism
Tactical urbanism includes low-cost, temporary changes to the built environment, usually in cities, intended to improve local neighborhoods and city gathering places. Tactical urbanism is also commonly referred to as guerrilla urbanism, pop-up urbanism, city repair, or D.I.Y. urbanism.
The Street Plans Collaborative defines "tactical urbanism" as an approach to urban change that features the following five characteristics:
- A deliberate, phased approach to instigating change;
- The offering of local solutions for local planning challenges;
- Short-term commitment and realistic expectations;
- Low-risks, with a possibly high reward; and
- The development of social capital between citizens and the building of organizational capacity between public-private institutions, non-profits, and their constituents.
Inglenook
An inglenook, or chimney corner, is a recess that adjoins a fireplace. The inglenook originated as a partially enclosed hearth area, appended to a larger room. The hearth was used for cooking, and its enclosing alcove became a natural place for people seeking warmth to gather. With changes in building design, kitchens became separate rooms, while inglenooks were retained in the living space as intimate warming places, subsidiary spaces within larger rooms.
Aedicula
Front of the Library of Celsus with aediculae in Ephesus.
In ancient Roman religion, an aedicula (plural aediculae) is a small shrine.
Many aediculae were household shrines that held small altars or statues of the Lares and Penates, household gods guarding the entire house.
Other aediculae were small shrines within larger temples, usually set on a base, surmounted by a pediment and surrounded by columns. In ancient Roman architecture the aedicula has this representative function in the society. They are installed in public buildings like the triumphal arch, city gate, and thermae.
From the 4th century Christianization of the Roman Empire onwards such shrines, or the framework enclosing them, are often called by the Biblical term tabernacle, which becomes extended to any elaborated framework for a niche, window or picture.
Caustic (optics)
Caustics made by the surface of water.
In optics, a caustic is the envelope of light rays reflected or refracted by a curved surface or object, or the projection of that envelope of rays on another surface. The caustic is a curve or surface to which each of the light rays is tangent, defining a boundary of an envelope of rays as a curve of concentrated light.
Terroir
Terroir is a French term used to describe the environmental factors that affect a crop's phenotype, including unique environment contexts, farming practices and a crop's specific growth habitat. Collectively, these contextual characteristics are said to have a character; terroir also refers to this character.
Mondegreen
A mondegreen is a mishearing or misinterpretation of a phrase in a way that gives it a new meaning. Mondegreens are most often created by a person listening to a poem or a song; the listener, being unable to clearly hear a lyric, substitutes words that sound similar and make some kind of sense.
American writer Sylvia Wright coined the term in 1954, writing that as a girl, when her mother read to her from Percy's Reliques, she had misheard the lyric "layd him on the green" in the fourth line of the Scottish ballad "The Bonny Earl of Murray" as "Lady Mondegreen".
Parkinson's Law
Work expands so as to fill the time available for its completion.
Eating your own dog food
Eating your own dog food or “dogfooding” is the practice of using one's own products or services. This can be a way for an organization to test its products in real-world usage using product management techniques. Hence dogfooding can act as quality control, and eventually a kind of testimonial advertising. Once in the market, dogfooding can demonstrate developers confidence in their own products.
Illa de la Discòrdia
A city block on Passeig de Gràcia in the Eixample district of Barcelona, Catalonia, Spain. The block is noted for having buildings by four of Barcelona's most important Modernista architects, Lluís Domènech i Montaner, Antoni Gaudí, Josep Puig i Cadafalch and Enric Sagnier, in close proximity. As the four architects' styles were very different, the buildings clash with each other and the neighboring buildings.
Baumol’s cost disease
Baumol's cost disease (or the Baumol effect) is the rise of salaries in jobs that have experienced no or low increase of labor productivity, in response to rising salaries in other jobs that have experienced higher labor productivity growth.
The rise of wages in jobs without productivity gains derives from the requirement to compete for employees with jobs that have experienced gains and so can naturally pay higher salaries, just as classical economics predicts. For instance, if the retail sector pays its managers 19th-century-style salaries, the managers may decide to quit to get a job at an automobile factory, where salaries are higher because of high labor productivity. Thus, managers' salaries are increased not by labor productivity increases in the retail sector but by productivity and corresponding wage increases in other industries.
ƒ/8 and be there
"f/8 and be there" is an expression popularly used by photographers to indicate the importance of taking the opportunity for a picture rather than being too concerned about using the best technique. Often attributed to the noir-style New York City photographer Weegee, it has come to represent a philosophy in which, on occasion, action is more important than reflection.
Betteridge's law of headlines
Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no."
It is named after Ian Betteridge, a British technology journalist who wrote about it in 2009, although the principle is much older. It is based on the assumption that if the publishers were confident that the answer was yes, they would have presented it as an assertion; by presenting it as a question, they are not accountable for whether it is correct or not.