Welcome changing requirements
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Now, I understand deadlines. I understand that the plane will take off whether or not I’m on it, or the importance of beating the holiday retail rush, or that "the show must go on". It is perfectly clear to me how people use timekeeping technology to coordinate social activity. It’s actually quite remarkable when you step back and look at it. But, over the years, I have observed that there is a difference between those examples and the ones around the delivery of Things, which tend to be completely arbitrary. When you wrap an arbitrarily complex endeavor up in a neat launch date, the goal seems to be more about coercing the people beneath you to absorb the overhead of all the details you left out—that or sweating it yourself. As a tool for coordinating human activity, I have come to believe that the Thing-deadline calculus is, considering more sophisticated alternatives, unnecessarily crude.
It is rarely possible – or even particularly fruitful – to look too far ahead. A plan can usually cover no more than 18 months and still be reasonably clear and specific. So the question is most cases should be, Where and how can I achieve results that will make a difference within the next year and a half?
A planner may find that his beautiful plans fail because he does not follow through on them. Like so many brilliant people, he believes that ideas move mountains. But bulldozers move mountains; ideas show where the bulldozers should go to work.
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.
Modernist planning was obsessed with absolute numbers, including the minimum dimensions of rooms, open space per capita, and the one-size-fits-all head counts of neighborhood units. This was often pegged at five to seven thousand and was used as a formula for determining the distribution of schools, shops, sports fields, and other facilities. The failure of such planning is not in its effort to be comprehensive or to equalize access to necessary facilities. It is, rather, the attempt to rationalize choice on the basis of a homogeneous set of subjects, a fixed grammar of opportunities, a remorseless segregation of uses, and a scientistic faith in technical analysis and organization that simply excludes diversity, eccentricity, nonconforming beauty, and choice. The utopian nightmare.
It is always necessary to check tactics against the specific needs that become evident in specific places. We should always be asking, “Does this device do the job needed here? And if not, what would?” Deliberate, periodic changes in tactics of subsidy would afford opportunity to meet new needs that become apparent over time, but that nobody can foresee in advance. This observation is, obliquely, a warning against the limitations of my own prescriptions in this book. I think they make sense for things as they are, which is the only place ever possible to begin. But that does not mean that they would make the best sense, or even good sense, after our cities had undergone substantial improvement and great increase in vitality.
Ebenezer Howard set spinning powerful and city-destroying ideas: He conceived that the way to deal with the city’s functions was to sort and sift out of the whole certain simple uses, and to arrange each of these in relative self-containment.
And he conceived of good planning as a series of static acts; in each case the plan must anticipate all that is needed and be protected, after it is built, against any but the most minor subsequent changes.
I want you to consider instead the possibility that Waterfall came to exist, and continues to exist, for the convenience of managers: people whose methods are inherited from military and civil engineering, and who, more than anything else, need you to promise them something specific, and then deliver exactly what you promised them, when you promised you’d deliver it. There exists many a corner office whose occupant, if forced to choose, will take an absence of surprises over a substantive outcome.
One of the most common mistakes I see people make when looking at data is incorrectly using an overly simplified model. A specific variant of this that has derailed the majority of work roadmaps I've looked at is treating people as interchangeable, as if it doesn't matter who is doing what, as if individuals don't matter.
Individuals matter.
What 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.
The 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™.
It always takes longer than you expect, even when you take into account Hofstadter's Law.
My 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.
Yagni 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".