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".
We are quietly replacing an open web that connects and empowers with one that restricts and commoditizes people. We need to stop it.
We're very good at talking about immersive experiences, personalized content, growth hacking, responsive strategy, user centered design, social media activation, retargeting, CMS and user experience. But behind all this jargon lurks the uncomfortable idea that we might be accomplices in the destruction of a platform that was meant to empower and bring people together; the possibility that we are instead building a machine that surveils, subverts, manipulates, overwhelms and exploits people.
It all comes down a simple but very dangerous shift: the major websites of today's web are not built for the visitor, but as means of using her. Our visitor has become a data point, a customer profile, a potential lead — a proverbial fly in the spider's web. In the guise of user-centered design, we're building an increasingly user-hostile web.
If you run a website and you put official share buttons on your website, use intrusive analytics platforms, serve ads through a third-party ad network or use pervasive cookies to share and sell data on your users, you're contributing to a user-hostile web. You're using free and open-source tools created by thousands of collaborators around the world, over an open web and in the spirit of sharing, to subvert users.
What I'm against is the centralization of services; Facebook and Google are virtually everywhere today. Through share buttons, free services, mobile applications, login gateways and analytics, they are able to be present on virtually every website you visit. This gives them immense power and control. They get to unilaterally make decisions that affect our collective behavior, our expectations and our well-being. You're either with them or out. Well, I chose out.
You see, the web wasn't meant to be a gated community.
Do we want the web to be open, accessible, empowering and collaborative? Free, in the spirit of CERN’s decision in 1993 or the open source tools it's built on? Or do we want it to be just another means of endless consumption, where people become eyeballs, targets and profiles? Where companies use your data to control your behaviour and which enables a surveillance society—what do we want?