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.
Seeing With Fresh Eyes
Meaning
Space
Data
Truth
The problem with trees
Many systems are organized hierarchically. The CERNDOC documentation system is an example, as is the Unix file system, and the VMS/HELP system. A tree has the practical advantage of giving every node a unique name. However, it does not allow the system to model the real world. For example, in a hierarchical HELP system such as VMS/HELP, one often gets to a lead on a tree such as:
HELP COMPILER SOURCE_FORMAT PRAGMAS DEFAULTS
only to find a reference to another leaf: Please see
HELP COMPILER COMMAND OPTIONS DEFAULTS PRAGMAS
and it is necessary to leave the system and re-enter it. What was needed was a link from one node to another, because in this case the information was not naturally organized into a tree.
Content-responsive space
Content-responsive spaces in text can be as meaningful as spaces and line breaks in computer code, poetry, math, dialogues, cartoons.
For 1500 years, printed text has used grids indifferent/hostile to meaning. Content-responsive grids are better than imperious grid-possessed layouts. To clarify and intensity meaning, authors and editors can remodel relations between spaces and words...insisting on control of line breaks by authors (who, after all, know the content).
Personal annotations
Yehudi Menuhin, a great violinist, marked up a score for Bach's Sonata No. 2 for Solo Violin. Penciled annotations show real-time performance strategies. To outsiders, insider markups appear chaotic and cryptic, but these personal annotations are for Menuhin's eyes, the only eyes that matter. All can learn from this useful workaday grid strategy: a relevant and intense data layer can become a coherent substrate scaffold upon which to overlay additional information. Maps do this all day long.
What excellence is
Learn what excellence is, how to identify it...This is not a big reading assignment – excellence is scarce, lognormal, long-tailed. Acting on this knowledge is liberating, freeing oneself from vast piles of triviality, knock-offs, petty connoisseurship, over-publishing, and the short-sighted, trendy, greedy. Excellence is long-term knowledge, even forever knowledge.
Excellence, like good taste, is perhaps a universal quality. Analytical thinking is about the relationship between evidence and conclusions, and is fundamental to all empirical work, regardless of field, discipline, specialty. Thus it is possible at times to assess credibility of nonfiction work without being a content expert. Thinking eyes may well have an eye for excellence, regardless of field or discipline.
Sentences and words do not exist by themselves
Sentences and words do not exist by themselves, but have natural, inevitable, unavoidable interactions with their surrounding spaces, words, and other sentences. Sentences are not independent of their spatial context, and interactions can create meanings and harms. Sentences survive content-indifferent and content-hostile spacings, but surviving is not thriving. Text space should not be owned and governed by generic productions grids, which make for convenient production but inconvenient meaning. Space can and should be content-responsive, actively contributing to meaning – forever practices in poetry, maps, math, computer code, comics, theater/movie scrips, posters. Subtle visual spacing differentiates and clarifies sentences, and meaning becomes more consequential, memorable, retrievable.
Central-axis text
Central-axis provides a clear signal of the next line, so that readers and speakers don't have to search on the left margin, sometimes accidentally skipping down a line. Ragged-left typography is used for dialogue in novels and scripts. In central-axis, each line is activated at both left and right margins – unlike squared-off conventional text. Readers/speakers are aware of the length of the next line at both its beginning and end. That knowledge may also help readers detect the pace and rhythm of the words, as in reading poetry aloud.
Idiosyncratic paragraphs
Text-only paragraphs differ from one another only in their words. All the words are typographically the same – typeface, spacings, line-lengths piled up into long deep columns. Systematic regularity of text paragraphs is universally inconvenient for readers, who are unable to find and read once against a specific string of words in previously-read paragraphs. All readers have encountered this problem in essays, articles, novels, news reports. Idiosyncratic paragraphs assist memory and retrieval by readers, by uniquely activating the relevant neural substrates for retaining visual memories. Nearly every paragraph in this book is deliberately unique.
No more LittleDataGraphics
Small data sets should be shown directly...LittleDataGraphics (pie charts, bar charts) translate and encode data into areas and colors. Viewers must then mentally translate codes back into numbers. These codes are unique to the local sets of data graphics, and do not repay learning. Instead, just directly show numbers as numbers. No more LittleDataGraphics. Data visualizations are at their best when there is so much data that the only way to see it...is to see it.
An immense wordy diagram
In ~1560 Ettore Ausonia, a polymath with interests from mathematics to mirror-making, constructed an immense wordy diagram depicting reflections from concave spherical mirrors. Then, between 1592 and 1601, while teaching at the University of Padua, Galileo made this handwritten copy of the diagram, which was fortunate since Ausonio's original has since gone missing. Three helpful architectures for the off-the-grid sentences are deployed – word trees, stacklists, annotated linking lines.
Stacklists
Stacklists organize and clarify complex material in 2-space. Readers read more slowly, and that's good: to think, look again, and connect words vertically within each stack and horizontally between stacks. Instead of polyphony, conventional inline lists are a freight train of words along a one-way narrow track, making it difficult to identify which words belong to which list and to link and compare elements within and between lists.
Observe data collection at the moment of measurement
See, observe, learn how data are collected at moment and place of measurement. "You never learn more about a process than when you directly observe how data are actually measured," said Cuthbert Daniel, a superb applied statistician. See with fresh eyes. Walk around what you want to learn about. Talk to those who do measurements. See how numbers came to be.
Do those measuring know the desired answer? Are those measuring skilled, alert, honest, biased, incompetent, sloppy, tired and emotional?...Artifacts and errors in measurements measured? How are outliers adjudicated?
46 data quality issues in spreadsheets
Outcomes decide
High levels of U.S. patient satisfaction are mainly associated with hospitality (greeters at the door, empathetic staff, comfortable rooms) – but also with more treatments, high costs, and substantially higher mortality even after adjusting for baseline health and comorbidities. Several plausible stories explain these big n and replicated observational findings. Whatever the case, post-treatment patient satisfaction/gratitude does not measure whether a treatment works or not. Patient outcomes decide.
Which half?
One day when I was a junior medical student, a very important Boston surgeon visited the school and delivered a great treatise on a large number of patients who had undergone successful operations for vascular reconstruction. At the end of the lecture, a young student at the back of the room timidly asked, "Do you have any controls?" Well the great surgeon drew himself up to his full height, hit the desk, and said, "Do you mean did I not operate on half of the patients?" The hall grew very quiet then. The voice at the back of the room hesitantly replied, "Yes, that's what I had in mind." Then the visitor's fist really came down as he thundered, "Of course not. That would have doomed half of them to their death!" God, it was quiet then, and one could scarcely hear the small voice ask, "Which half?"
Good annotation
Information displays should be annotated, combining words, images, graphics, whatever it takes to describe and explain something. Annotation calls out and explains information and, at the same time, explains to viewers how to read data displays. Good annotation is like a knowledgeable expert/teacher at the viewer's side pointing and saying, "Now see how this works with that, how this might explain that..."
Signs seen and unseen
Direct instructions at point of need may encourage writers and programmers to divert diversions. Or not, because signs are seen only a few times before becoming unseen.
What is the strongest visual element?
Preparing to write the novel Catch 22, Joseph Heller composed a storyboard, a 2-dimensional list with 3,650 words arrayed in 34 × 21 = 714 interacting cells. Rows are ordered in time, and each row records when each character does what. Some cell entries are erased. It took 7 years to complete the novel's 758-page typescript.
The Catch 22 plotchart works better upon replacing optically noisy grids with ghost grids. Lightness of framing lines creates soft boundaries to maintain order and also allows words to spill across cells naturally...More generally, ask of information displays and interfaces, "What is the strongest visual element?" The correct answer is not "grid lines".
Your only language is vision
To see with fresh, uninstructed eyes and an open mind requires a deliberate, self-aware act by the observer. Abstract artworks represent themselves and should be first viewed for themselves. When looking at outdoor abstract pieces, concentrate initially on the unique optical experience produced by the artworks. See as the artist saw when making the piece.
A focus on optical experience does not deny stories, it postpones them. Viewing an artwork may evoke interesting narratives – or just tedious artchat recalling similar art or artists, concocting playful tales, realizing how scrap metal was repurposed into art, making judgments about the artist's intentions or character, or contemplating an artwork's provenance, price, politics. Let the artwork stand on its own. Walk around fast and slow, be still, look and see from
up down sideways close afar above below
, enjoy the multiplicity ofsilhouettes shadows dapples clouds airspaces sun earth glowing
. Your only language is vision.Lists consist of whatever it takes
Lists consist of whatever it takes – nouns, proper nouns, verbs, graphics, images, numbers.
...In lists, spaces have meaning, locating elements in relation to other elements. Lists are often free and independent from conventional rules of stylesheets / grammar / typography / punctuation. Lists also help us escape from the personal internalized mash-up stylesheets of every writer and reader – a continuous low-level background buzz checking to see if word usage, spelling, punctuation, grammar are 'correct'. Lists are all content – about the substance contained, not the container. An empirical theory here for reasoning about lists includes
selection of list items
list quality and completeness
comparing list models
comparing list architecturesNo wonder you think it's complicated
We were very proud of our user interface and the fact that we had a way to browse 16,000 (!!) pages of documentation on a CD-ROM. But browsing the hierarchy felt a little complicated to us.
So we asked Tufte to come in and have a look, and were hoping perhaps for a pat on the head or some free advice. He played with our AnswerBook for 90 seconds, turned around, pronounced his review:
"Dr. Spock's Baby and Child Care is a best-selling owner's manual for the most complicated 'product' imaginable – and it has only 2 levels of headings. You have 8 levels of hierarchy and I haven't stopped counting yet. No wonder you think it's complicated."
Verb List
Documents vs. decks
Decks are easier to prepare than documents, however. Documents require coherence, thinking, sentences. But convenience in preparing decks harms the content and the audience. Optimizing presenter convenience is selfish, lazy, and worst of all, replaces thinking.
Books are meant to be used
During most of the course students have their books open, either to read or to follow along. Students are encouraged to annotate the books: "Books are meant to be used. Dog-ear the pages, mark them up, put notes in the spacious margins."
Learning via teaching
The course material changes 15% each year, as the book currently in progress becomes part of the course years before it is finally published. I detect incoherencies and mistakes in the new material while teaching. This leads to refinements or even throwing stuff out from the forthcoming book. A good way to learn about something is to teach it.
Self-publishing, self-exemplifying
I sought to design [my first book] so as to make it self-exemplifying – that is, the physical object itself would reflect the intellectual principles advanced in the book. Publishers seemed appalled at the prospect that an author might govern design. Consequently I decided to self-publish the book.
...[Howard Gralla and I] spent the summer in his studio laying out the book, page by page. We integrated graphics into the text, sometimes in the middle of sentences, eliminating the usual segregation of text and image – one of the ideas Visual Display advocated.
My view on self-publishing was to go all out, to make the best and most elegant and wonderful book possible, without compromise. Otherwise, why do it? The next 4 books were financed by the previous books. I have never written a grant application.
A history of content and sources
Not all that many readers go to the back matter and look up the source for a single sentence. But the back matter can also be read as ordinary text, revealing a history of content and sources. And images and illustrations from the book in the back matter create a lovely visual/verbal summary quilt of the entire book, enjoyed by all.