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.
- ââSteve Jobsââ
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.
Understanding Understanding
A dot went for a walk
A dot went for a walk and turned into a line.
The dot, the line, the dance, the story, and the painting had found connections. Memory became learning, learning became understanding.Learning is remembering what one is interested in. Learning, interest, and memory are the tango of understanding.
Creating a map of meaning between data and understanding is the transformation of big data into big understanding.
The dot had embraced understanding.
Understanding precedes action.
Each of us is a dot on a journey.Admitting ignorance
The most essential prerequisite to understanding is to be able to admit when you don't know something. Striving to be the dumbest person in the room.
When you donât have to filter your inquisitiveness through a smoke screen of intellectual posturing, you can genuinely receive or listen to new information. If you are always trying to disguise your ignorance of a subject, you will be distracted from understanding it.
Information imposters
Information imposters: This is nonsense that masquerades as information because it is postured in the form of information. We automatically give a certain weight to data based on the form in which it is delivered to us. Because we donât take the time to question this, we assume that we have received some information.
My favorite example of this is in cookbook recipes that call for you to âcook until done.â This doesnât tell you very much. Why bother? Information imposters are fodder for administravitis.
Michaelangelo's hammer
A young man named Michelangelo stands in front of a huge granite monolith. He stands there at a time in history before the technologies that brought us the hammer and chisel have occurred. He gazes at the rock. He dreams his dream and the best that he is able to say is, What a wonderful stone you are.
âŚ
Michaelangelo now stands in front of the same rock. Thrust into his hands are a hammer in one and a chisel in the other. He looks at his hands, at the technological tools that they hold, and gazing at the same stone, with epiphanic zeal, says I must let Moses out.
I won't get
If I don't ask, I won't get.
Talking with Clinton
When you are talking with Clinton, he is not looking over your shoulder to see who else is in the room. You can tell he is not thinking about how he is going to respond to you. He is there, present and listening.
By the way, when you scramble the letters in the word listen, it becomes a new word: silent. Weâre so often wrapped up in our own self-talk, we forget to listen and learn the information in the first placeâŚand you canât remember or understand something you never observed.
Scales of change
To understand revolutionary change in its full complexity â not just what happened, but why it happened â we need a model that works across multiple scales, and the disciplines that traverse them.
The method
Well no, see, thatâs the tricky part. I always try to come up with things that when they find out the method, the method is as interesting as the effect itself. â David Blaine
Selling your own ignorance
When you sell your expertise - and what I mean by sell is to move ahead in a corporation, or sell an idea to a publisher, or sell an ability to a client - by definition, youâre selling from a limited repertoire.
However, when you sell your ignorance to move ahead, when you sell your desire to create and explore and navigate paths to knowledge, when you sell your curiosity - you sell from a bucket with an infinitely deep bottom that represents an unlimited repertoire. And, you sell in a way thatâs not intimidating, in a way that joins the explanation to the fascination that comes with understanding.
You only understand something relative to something you already understand
A good question is better than a brilliant answer
The eyes of a traveler
Weâve all heard that travel broadens the mind. But beneath this clichĂŠ lies a deep truth. Things stand out because theyâre different, so we notice every detail, from street signs to mailboxes to two you pay at a restaurant. We learn a lot when we travel, not because we are any smarter on the road but because we pay such close attention. On a trip, we become our own version of Sherlock Holmes, intensely observing the environment around us. We are continuously trying to figure out a world that is foreign and new.
Too often, we go through our day-to-day life on cruise control, oblivious to huge swaths of our surroundings. To notice friction points â and therefore opportunities to do things better â it helps to see the world with fresh eyes. When you meet creative people with lots of ideas constantly bubbling to the surface, you often come away feeling that they are operating on a different frequency. And they are, most of the time. They have all their receptors on â and frequently turned up to eleven. But the fact is, we are all capable of this mode. Try to engage a beginnerâs mind. For kids, everything is novel, so they ask lots of questions, and look at the world wide-eyed, soaking it all in. Everywhere they turn, they tend to think, Isnât that interesting? rather than, I already know that.
By adopting the eyes of a traveler and a beginnerâs mindset, you will notice a lot of details that you might normally have overlook. You put aside assumptions and are fully immersed in the world around you. In this receptive mode, youâre ready to start actively searching out inspiration.
Cart before the horse
It seemed to him that in pursuit of an all-purpose, all-serving health care plan, the country was designing an ocean liner before it even understood why boats float.
The What and the How
How many aspects of problem solving and design solutions are there? Many, many might answer.
But there are actually just two: What to do and how to do it.
Before anything else, before you consider how youâre going to get it done or how much youâll have to pay for it or how youâll get permission to do it â before anything else, you have to decide what you want. You have to decide what kind of place you want to live in, what kind of community, what kind of city.
We donât pay enough attention to the old adage: Be careful what you wish for, because you just may get it.
Thinking with the hand
The idea of thinking with your hands is not the exclusive domain of sculptors or engineers. In healthcare, for exams, surgeons have a powerful link between the head and the hands. Of course, like all healthcare professionals, their work involves a lot of deep knowledge and understanding. But itâs not all in their brain. If you were in medical school, learning to be a surgeon, for example, would you want your professor to be someone who writes about surgery or would you rather be taught by a surgeon? Many surgeons donât publish scholarly articles. They spent time perfecting their skill with their hands. In some ways, the relationship between surgery and the larger field of medicine is analogous to the relationship between design and the larger field of engineering. Designers â and design thinkers âoften think with their hands.
A pattern of understandings
The clock has no finished design and it has been made without any careful drawings or mathematical calculations. The pieces are only made if I can hold their details in my head as I make them, without reference to any set of external measures. I do make rough sketches of some parts as a path to understanding them, but never use these during the making of the parts. The clock gradually grows through trial and error and lots of physical work with metal, but out of this has come a set of principles of making that were not clear to me before doing the clock. I have finally realized that what I am actually making is a pattern of understandings of the process of making rather than the things that are actually being made. â Richard Benson
#15
How different am I, making clock number 15, from the process of natural selection laboring under changing conditions to generate the biological constructs? That ancient evolutionary system works on the basis of trial and error repeated in huge numbers over immense spans of time, with the failures discarded and the successes retained. At times it seems to me that my clock making is quite similar, as my mind, just barely thinking, sorts through huge numbers of possibilities and discards them as failures before even trying them, so the few that are made have a pretty good chance of success. Is this foresight some form of understanding? I think not. No revelation here, just enough thinking to spur the maker on to cut some piece of metal which, once made, might fail or succeed. Yet â in either case â the thing made and its creation remains the sole root of any real understanding that takes place. The clock is crude but gets built, and even in its base simplicity teaches its maker how to understand what must be understood for something to be made. â Richard Benson
A classroom without walls
The city is education â and the architecture of education rarely has much to do with the building of schools. The city is a schoolhouse, and its ground floor is both bulletin board and library. The graffiti of the city are its window displays announcing themselves, telling about what theyâre doing and why and where theyâre doing it. Everything we do â if described, made clear, and made observable â is education: the Show and Tell, the city itself. It is a classroom without walls, an open university for people of all ages offering a boundless curriculum with unlimited expertise. If we can make our urban environment comprehensible and observable, we will have created classrooms with endless windows on the world.