Archive for the ‘Uncategorized’ Category.

Agile’s Second Chasm (and how we fell in)

Some years back, I remember the excitement in the Agile community when the general public started taking us seriously. The common reaction went from “Get away from me, crazy people,” to “That’s interesting; tell me more.” It felt like the car we had been pushing uphill had finally reached the crest.

At the time, it was very exciting. In retrospect, perhaps that was the beginning of our doom: the car passed the crest, picked up speed, and careened out of control. Now the state of the Agile world regularly embarrasses me, and I think I’ve figured out why.

The first chasm

Geoffrey Moore’s seminal book “Crossing the Chasm” is about a gap between a product’s early adopters and the rest of a market. Writing in 1991, he looked at why disruptive technology products fail, and concluded that there was an chasm between the early market for a product and everyone else. Some companies fall in, some cross it to success.

crossing-the-chasm

The essence of this is that the early market, who are circa a sixth of the total market, are different. They are comfortable with changing their behavior, and are eager to do it to get a jump on the competition. In contrast, early mainstream purchaserswant evolution, not revolution. They want technology to enhance, not overthrow, the established ways of doing business.”  Later mainstream purchasers don’t want to change at all; they do it because they have to. For a physical technology product, that mainly shapes marketing and product accessories like support and documentation. But what does that mean for something as ethereal as a development process or a set of values?

The second chasm

You can’t buy an idea. Instead, people buy things like books, talks, classes, and consulting services. By and large, those buyers don’t measure any actual benefit. When wondering whether they got their money’s worth, they go by feeling and appearance.

For early adopters, that can be enough. As people who seek sincerely and vigorously to solve a problem or gain an advantage, they are strongly motivated to find ideas of true value and to make them work. But for the later adopters, their motivation for change isn’t strong. For many, it’s merely to go along with everybody else, or to appear as if they are.

Because those later adopters are numerically greater, they’ll be the majority of the market. And unlike early adopters, who tend to be relatively self-sufficient, they will consume more services, making them an even bigger influence. They’ll also tend to be the least sophisticated consumers, the least able to tell the difference between the product they want and the product they need.

Putting that together, it suggests that when people want an idea, the most money can be made by selling products that mainly serve to make later adopters look or feel like they’re getting somewhere. Any actual work or discomfort beyond that necessary to improve appearances would be a negative. Bad products and bad ideas could drive out the good ones, resulting in a pure fad. The common perception of the idea would come to be defined by the majority’s behavior and results, burying the original notion.

That’s the second chasm: an idea that provides strong benefits to early adopters gets watered down to near-uselessness by mainstream consumers and too-accommodating vendors.

Agile fell in

From what I can see, the Agile movement has fallen in the second chasm. That doesn’t mean that there aren’t bright spots, or people doing good work. You can, after all, find old hippies (and some new ones) running perfectly fine natural food stores and cafes. But like the endless supply of grubby, weed-smoking panhandlers that clutter San Francisco’s Haight-Ashbury district, I think there is a vast army of supposedly Agile teams and companies that have adopted the look and the lingo while totally missing the point.

Originally, I based this notion on the surprising number of people I talked to who were involved in some sort of Agile adoption that was basically bunk: Iterations that weren’t iterating. Testing that wasn’t testing. Top-down power relationships. Cargo cult Agile. Fixed deadlines and fixed scopes. Teams that aren’t teams. Project managers who pretend to be Scrum Masters. Oceans of Scrumbut.

That could have just been me, of course. But over the past year or so I’ve talked to a number of Agilists that I met in the 2000-2003 timeframe. They have similar concerns. “This isn’t what we meant,” is something I’ve heard a few times, and I feel the same way. Few these days get the incredible improvements we early adopters did. Instead, they get little or no benefit. The activity of the Agile adoption provides a smokescreen, and the expected performance gains become a stick to beat employees with.

Honestly, this breaks my heart. These days, every time an acquaintance starts off saying, “So now we’re ‘doing Agile’ at work…” I cringe. I used to be proud to be associated with the Agile movement. But although I still love many of the people involved, I think what happened is a shame. Looking back, I see things I wish I had done differently, things I intend to do differently next time. Which makes me wonder:

  • Have other early Agilists noticed this?
  • If you had it to do over again, what would you do differently?
  • To what extent do you think the problem is solvable?

I’d love to hear what other people think, be that via email, on Twitter, or in the comments below.

Against Managerial Time Travel

I just realized that two things that frequently bug me about software projects are really two sides of the same problem: managers who think they are living in a fantasy/science fiction novel. (I’m pretty sure it’s sci-fi, for reasons I’ll explain below.)

See the future!

Johanna Rothman’s recent post “But I Need to Know When the Project Will Be Done” is a great example of the first. A manager wants to know when a project will be done. It’s for a hazily defined feature set, one that will be changed by future feedback. Often, this is asked of teams with little history together, working with novel technologies, and with some staff still to come. But somehow they want a fixed date. It’s like they’re asking for this:

equation2

Do they believe that developers are psychic, able to part the mists of time with the raw power of their minds? Could they think that the team, having already sold their souls for power over bits, can just ask their dark minions about the future? In other words, is it the stuff of fantasy?

Or is it that they think we nerds, among our other magic machines, have one that lets us travel through time? Is it a science fiction dream they’re living?

Change the past!

I think it has to be the latter, because of their desire to change the past. Because what else can you make of project post-mortems that seek to identify every mistake made, and every person who made it? Of bringing up again and again people’s past mistakes, without investing at all in preventing future problems. Of playing out endless “If only you had done X” scenarios. What other purpose could all their blame-seeking behavior serve? After all, it hurts morale, reduces innovation, and eventually drives your best workers out the door.

The most reasonable explanation for this is that they are just saving up issues for when they finally get their time machine, so they can go back and fix all those niggling things that went wrong the first time. Like so many time-travel mad scientists, their obsession with perfecting the past makes them heedless of the future consequences of their actions.

Flip it and reverse it

Of course, people doing this (which certainly includes me, sometimes) have it exactly backwards. What managers (and everybody, but especially managers) should practice is seeing the past and changing the future. And I think the best way to do that is focusing on the present: the people we work with, the systems that guide us, and our current realities. Our powerful imaginations may make the past seem mutable and the future fixed, but they aren’t. When we act as if it were otherwise, we live a fiction.

The Lean Startup Kanban board

In my last post, “Responsible Technical Debt: Not an Oxymoron“, I said I’d propose a way to responsibly handle technical debt in a Lean Startup context, where a substantial number of your units of work are experimental, and unlikely to be kept as first written. That way follows. I should explain that although I haven’t seen in practice, it’s one I’ll be trying soon in my very own startup, so I’ve given it a fair bit of thought. My thanks to the many Lean Startup and Kanban people who have inspired this.

Standard Kanban boards

The core notion of a software development Kanban board is that you represent visually the state of various units of work. These units of work are pretty small, generally a few person-days. A basic one looks something like this:

normal

Stories flow in from the backlog on the left. After they are worked on (D-E) and reviewed (F), they are released and put in the file of finished stories, rarely to be looked at again. There are generally limits, so that a team will only have a certain number of stories in each stage at one time. Because the code could be around for years, we need to make sure to write it in a sustainable way, and the Agile movement, especially the Extreme Programming end of it, has discovered and promoted a lot excellent techniques for making code that lasts.

This flow makes a lot of sense when you are using Agile techniques to solve a known problem, and have pretty high confidence that the things you build will last indefinitely.

Lean Startups are different

However, in software startups, and especially when following the Lean Startup approach, you are solving an unknown problem. The goal, especially in the early stages, isn’t to build software; it’s to discover needs and wants that people will pay you to satisfy.

The standard startup approach, typified by dot-bomb Webvan, is known in the Lean Startup community as the “field of dreams” approach. You build a complete product in the hope that when you finish, your customers will come. The Lean Startup approach instead requires that you identify your hypotheses about your customers, your market, and your products, and test those hypotheses as early as possible, partly by trying a lot of things out and seeing how they work.

Another way to look at this comes from Eric Ries:

The Lean Startup Loop

Anything that makes that loop longer is worse. Technical debt can surely do that. But if you write something to last the ages and then remove it next week, that can also slow down your feedback loop.

My answer is to explicitly accept there will be two kinds of code in the system. There will be sustainable code, the kind that Agilists have spent the last 15 years learning how to create properly. And there will be temporary code, code that we explicitly plan to throw away. I still think the third kind of code, half-assed code, has no place in a serious software project. But there’s a risk, one many of us have lived: what if the temporary code sneaks into the permanent side, putting the project on the road to a technical debt bankruptcy?

Lean Startup Kanban boards

My solution to this is to expand the Kanban board to explicitly represent the flow of experiments. Below, experiments are represented in blue:

kanban-startupFor the early part of their lifecycle, experiments and regular features share a pretty similar path. They hang around in a backlog until the are put on deck (C). They get worked on by the team as part of the regular flow (E), and accepted by product managers (G). But then, after release instead of being put in the released-and-forgotten box, those stories are tracked as active experiments (H-M).

When the experiment is concluded, then the feature might be accepted permanently, in which case the code will need to be cleaned up, and the rest of the system refactored to accommodate the new code. More likely, the code will be removed. Possibly because the feature turned out to be a bad idea, at least in its current form.

Or possibly it was a good idea, but not good enough in its current form to keep.  Often the first approach to a feature (or to its implementation) isn’t the right one; it can be better to remove the experiment and its code in favor of an upcoming correct implementation. In which case, it will yield a number of new story cards for the backlog.

I think this approach will mitigate the biggest risk of accepting any temporary code: you forget that it’s temporary, and suddenly you’ve got technical debt in your system and no scheduled time to clean it up. There are other risks, some of which I hope to write about over the coming weeks and months.

Have thoughts on this? Have you tried something similar? I’d love to hear about it. Leave a comment!

Responsible technical debt: not an oxymoron

Kent Beck’s recent talk at the excellent Startup Lessons Learned conference has created some controversy. As somebody who attended the conference and who has been involved in startups for many years, I agree with some things on each side of the argument, and I want to give my take on how to be responsible with technical debt.

The Agile reaction

In the dark days of waterfall, code bases had only two states: being re-written or slowly getting worse. The project would start out with great hope. People would write something beautiful, launch a 1.0, and then spend their time patching it. Inevitably, and despite initial efforts to resist, the code base would go slowly downhill. Gradually increasing technical debt would lead to technical bankruptcy, forcing a big rewrite. Then the agonizing cycle would start again.

One of the key insights of the Agile movement, one crystallized by Martin Fowler’s book Refactoring, was that decay was not inevitable. We could clean things up incrementally as we went, without needing periodic giant rewrites. Another key insight comes via Kent Beck’s Extreme Programming: if we worked iteratively and refactored all the time, then we could start clean and stay clean, forever, ending the cycle of giant rewrites.

As easy as that sounds, it’s actually very hard; every solid Agile practitioner has spent time developing a nose for technical debt, and a hate of it. So when Kent Beck suggested that startups could responsibly create some technical debt, it caused a lot of strong reactions: to some people it sounded like the pope saying that premarital sex and adultery were occasionally fine.

But startups are about learning

For this to make sense, you have to understand two things:

  1. Startups—even software startups—are businesses, not software development projects.
  2. The point of a startup isn’t to create a software product; it’s to discover a sustainable business model.

In a startup, software development isn’t an art for its own sake; what makes sense from a pure engineering perspective may not make sense more broadly. That’s true for any business really, but it’s especially true for a startup. That’s because the main goal of a startup is to discover a valuable business. Discovery requires experimentation, and the amount you can learn is a function of the cost of your experiments.

So suppose I have a new idea for a game. I believe it will be A) fun and B) a moneymaker. I could take a number of months and design it, develop it, polish it, and publish it. Then the market would tell me whether my beliefs were correct. Or I could make a very crude version with 1 level, have some people play it, and see if the core gameplay is enjoyable. That’s my first experiment to examine hypothesis A, fun. If it works, I could put it up on the web, buy a few ads, and see if the game sounds interesting enough to click through and try it. That would be my first test for hypothesis B, making money with the game.

Now if these tests fail, then my code base may be pretty short lived. They say that hard work pays off eventually, while laziness pays off now. The same is true for good development practices. A lot of Agile practices get you long-term sustainability, but they cost you in the short term. For sufficiently small and short-lived pieces of code, worrying about technical debt does not make business sense. Better to invest in more experiments.

Danger Will Robinson!

At this moment, some of my readers are leaping up to say “But! But! But!” That’s what I wanted to do during Kent’s talk, anyhow. Because when businesspeople hear that they can have something quicker, they will often interrupt to say, “Yes! Do that!” As I explain in “The 3 Kinds of Code“, a lot of business/engineering fights arise because engineers are more aware of the long-term costs of short-term thinking. I have seen good teams, even ones otherwise well-versed in Agile techniques, give in to that business pressure again and again, creating giant messes.

So hacking things together, and the resultant technical debt is extremely dangerous, but sometimes very powerful. What should a responsible team do?

I believe there are good ways to handle this dilemma, and will propose one approach in my next post.

9 Signs of Bad Team Spaces

One of the most popular articles here is 10 Rules For Great Development Spaces, so I thought I’d follow up by explicitly listing signs of bad spaces. These are my top 9, but I’d love to hear what others people have noticed.

  1. People wearing headphones. Part of the reason to sit together is to listen to one another. If team members are wearing headphones, they can’t do that. Don’t blame them, though; figure out what noise or distraction drives people to do that and eliminate the root problem. And if they aren’t part of the team, move them elsewhere.
  2. Stale artifacts on the walls. Every artifact on the wall should be there for a reason. If there are a lot of stale plans, charts, or lists on the walls and whiteboards, that’s a sign of trouble. Immediately prune the junk!
  3. Workspace as information desert. Development teams turn knowledge into software products. Rather than requiring effort to find things out, a good workspace requires effort to avoid knowing what’s going on. Bare walls often indicate low collaboration or high confusion.
  4. Minimal interaction. If team members sit near one another and never talk, it’s often a sign of an underlying problem. I’ve seen this caused by bad relationships, code silos, excess division of labor, too-long release cycles, excess schedule pressure, and plain old shyness.
  5. Furniture as barrier. Furniture should help you work, not get in the way. Barriers are great to reduce noise and chaos at team boundaries, but true teams should be able to share space and collaborate effectively.
  6. Sad or ugly spaces. You will likely spend more waking hours in this room than any other. Shouldn’t it be nice?
  7. Seating by job description. Agile approaches require cross-functional teams to make whole products. If people are grouped by job description, that is at least a barrier to collaboration, and often a sign of unhelpful silos. Group people by project instead.
  8. Space and furniture as status markers. In some companies, being distant from the action is a sign of status. On Agile teams, that’s a mistake. Instead of using rooms and desks to indicate hierarchy, give people the tools they need to do their jobs.
  9. No laughter, no fun. This is a big one for me. Every really productive team I’ve visited enjoys the work and their fellow team members. Money can make people show up, but it’s joy that gets the best results.

That’s my list. What’s yours?

Proactive versus reactive

Somebody recently asked me if Agile approaches aren’t essentially reactive, with Waterfall being proactive. It’s a good question, and I’m sure there are a lot of interesting answers. Here’s my take.

Proactively reactive

In terms of product produced, you can be more proactive in an Agile context than you can in a Waterfall context. With Waterfall methods, you just have to hope your designs and plans are correct, reacting massively after each large release. With Agile approaches you can continually test your assumptions and hypotheses, allowing you to eliminate bad ideas early and invest more resources in areas that have been proven to deliver more long-term value.

Some Agile shops may end up stuck in purely reactive cycles, with no long-term plans. (I don’t see that much.) But the good ones are continuously updating their plans based on the new information that you can only gain if you can release frequently. It has been said that Waterfall is plan-driven, while Agile methods are planning-driven. Having tried both, I think frequent plan improvement is much more proactive.

The Agile conversation

Another way to look at it is that Agile approaches proactively take advantage of people’s reactive skills by creating situations where their reactions will be maximally useful.

Conversations are in some sense essentially reactive: you say something, I respond to it, you respond in turn. But we can proactively decide to have a conversation and expect to get something useful, perhaps novel out of it.

Agile approaches have conversations with markets and user communities, using new releases to advance the discussion. We release something and say, “How about this?” People respond: they love X, they hate Y, and how did you miss Z! We release another thing and say, “Is this better for you?” And so the conversation goes, week after week.

The myth of “undesigned”

Some teams talk as if design is something you can add to software later, saying, “Oh, that interface we built hasn’t been designed yet.” That way of thinking is based on a fundamental error.

The problem

Many real-world teams treat certain kinds of design, including visual design, user interface design, and interaction design, as quantities that you can add later. Often this is done with the best of intentions.

For example, the team’s designer may be unavailable, so the rest of the team will get to work on a story, building an obviously rough interface. If, by the time they’re done, the designer still isn’t available, the product owner might accept the story as complete, making a mental note to come back later, perhaps much later.

When somebody external comments on the ugly interface, the developers might say, “Oh, that hasn’t been designed yet.” They’re wrong.

Software is nothing but design

People often talk about software with an implied analogy to industrial production. One group of people makes up some blueprints, and then an entirely different group of people makes physical objects. That second group is judged not by the utility of the objects, but by conformance to the design. This can sometimes be a useful analogy, but in an important way it’s entirely false.

In truth, the creation of software is 100% design. The computer does all the work of making things happen in the real world. The software is just the blueprint the computer uses to decide what to do. In the same way that a good manufacturer is one that follows the instructions well, a good computer is one that executes the software faithfully and reliably. All the humans participating in the creation of software are involved in a joint design activity.

“Not designed” is badly designed

So if software is pure design, then what’s going on with the ugly interface? The notion that it is somehow “not designed” is wrong. It’s just badly designed. Why does that matter? Because good design isn’t something you can spray on later like a new coat of paint.

Programmers already know that for the kinds of design they appreciate. Good developers try hard to avoid  spewing out reams of confusing, badly organized code that they hope to clean it up later. They know that’s wasteful, and likely to hide tricky problems. Tactically, they may choose to leave certain things messy for a short period. But experienced developers do that judiciously, painfully aware of how easily a controlled low-quality situation can turn into an uncontrolled one.

Teams should have the same attitude about every kind of design that matters for their project. Each story should be well designed from every perspective before it is declared complete. That sounds like it could be a lot of work, but it needn’t be. As with the software architecture, other sorts of design can be approached incrementally and iteratively.

The only hard part is making sure that you have all key contributors working together. The easy way to do that? Put them all in a room, and have them release something every week. They’ll figure it out.

Slow down to boost profits

A team in which everyone works at top capacity has got to be the most productive, right? This article explains why it ain’t necessarily so.

(Note: I didn’t invent the exercise described here. I first saw something like it presented at the Agile2006 conference by Ashley Johnson and Rich Phillips of Valtech Technologies, Inc.)

The assembly line analogy

I recently conducted an exercise with the folks at North Bay Agile in which two teams formed assembly lines for folding paper airplanes. Each assembly line consisted of a number of distinct operations, as follows:

  • Operation 1 – Get raw material (a sheet of paper) from stock.
  • Operation 2 – Fold inward lengthwise, then unfold.
  • Operation 3 – Fold top corners inward.
  • Operation 4 - Fold sides inward, fold in half, fold wings down.

In the first shift, every member of each team worked at top capacity. The result: Each team produced about a dozen airplanes in 5 minutes.

But then I had each team fill out a “profit and loss” statement. They got credit for “selling” all planes produced, but they were also debited for the labor and material costs of uncompleted airplanes (which stacked up in front of Operation 4, the bottleneck). The financial news: Both teams incurred a loss.

In the second shift, the teams were instructed to slow down to match the rate of the slowest operation. This was accomplished by creating a “buffer zone” before each operation and following a rule which said, “you can’t pass your work on to the next operation until that operation’s buffer zone is empty.” The result: Each team still produced around a dozen airplanes in 5 minutes.

When the profit and loss statements were filled out a second time, each team showed a profit. This was directly due to the fact that no work-in-process inventory built up, thus reducing the amount spent on materials and labor.

The most obvious difference in the overall activity of the assembly lines from shift to shift was that, in the second shift, the upstream operations were sometimes idle. By slowing the upstream operations to match the rate of the slowest operation, both assembly lines increased their productivity.

Increasing productivity stepwise

After the first shift in the exercise, the inclination of several participants was to try to find ways to improve the performance of the slowest operation. As the second shift demonstrates, however, a simpler first step is to just slow down all of the upstream operations to match the rate of the slowest operation.

The business novel The Goal outlines a process for increasing the productivity of a manufacturing system:

  • Step 1 – Identify the system’s bottlenecks.
  • Step 2 – Decide how to exploit the bottlenecks (e.g. don’t let a bottleneck be idle).
  • Step 3 – Subordinate everything else to the above decision (e.g. throttle back the upstream operations).
  • Step 4 – Elevate the system’s bottlenecks (e.g. speed up a slow operation).
  • Step 5 – If, in a previous step, a bottleneck has been broken (i.e. a bottleneck is no longer a bottleneck) go back to Step 1.

 As you can see, the recommendation is to slow down all non-bottleneck operations before trying to speed the bottlenecks up.

How does the assembly line exercise relate to software development?

Although software development is not the same as manufacturing, there are situations in development that exhibit the characteristics of an assembly line. Suppose, for example, that you are a developer building components for use by other developers. If you (the upstream operation) produce components at a rate faster than the other developers (the downstream operations) can understand and use them, you can create a bottleneck, causing excess “inventory” to build up.

Software development is about creating and sharing knowledge

Here are some simple things to remember when considering whether it is more profitable to work at top capacity or to be idle part of the time:

  • Knowledge is the inventory of software development
  • People consume knowledge at their own rate
  • Creating knowledge faster than it can be consumed causes excess inventory
  • Excess inventory reduces profits

In other words, working at your own top capacity may not be the positive thing you think it is. If you’re producing software components at a rate greater than the rate at which they can be put to use, you could be hurting the bottom line.

Marshmallows, mortgages, and metacognition

One of the reasons traditional processes fail is that they are fitted to how people think they think, not how they actually do. Below I link to two interesting articles about how people think, and talk about the software process lesson I draw from them.

Waiting for marshmallows

Ninja programmer Brian Slesinsky recently pointed out to me this great New Yorker article: “Don’t: the secret of self-control.” 40 years ago, a psychologist performed a simple experiment on small children: He told them they could have one marshmallow now, or two if they waited a bit. Unsurprisingly, some children managed to do it; some didn’t.

The interesting part is why, and what happened later. Following up over the decades, it turns out this sort of self-control is powerfully predictive of success in life. One researcher found that the ability to delay gratification was better than IQ scores for predicting grades.

But how did this work? Do some kids just have more willpower than others? Was it just that some didn’t have all the facts about what they’d get when? No, it turns out. Instead, the children best at waiting put the marshmallow out of their minds. They covered their eyes, or sang Sesame Street songs. Focus on the marshmallow and you were guaranteed to lose. In other words, the successful children changed their situations to support the right sort of thinking.

Waiting for foreclosure

In this weekend’s New York Times there was an article “My Personal Credit Crisis”. The writer, Edmund L. Andrews, opens:

If there was anybody who should have avoided the mortgage catastrophe, it was I. As an economics reporter for The New York Times, I have been the paper’s chief eyes and ears on the Federal Reserve for the past six years. [...] I wrote several early-warning articles in 2004 about the spike in go-go mortgages. Before that, I had a hand in covering the Asian financial crisis of 1997, the Russia meltdown in 1998 and the dot-com collapse in 2000. I know a lot about the curveballs that the economy can throw at us. But in 2004, I joined millions of otherwise-sane Americans in what we now know was a catastrophic binge on overpriced real estate and reckless mortgages.

Again, knowing the facts weren’t enough. There were few people on the planet with more information about the topic, and he had unfettered access to people who knew the rest. But when he put himself in a situation where circumstances combined to reinforce his desires, mere knowledge wasn’t enough to save him.

So what’s this have to do with Agile development? I see two related lessons:

Product dreams

Think, for a moment, about the classic waterfall dream:

  1. you work hard to make a big plan,
  2. you follow the plan for a long time,
  3. you produce what you planned,
  4. and then you have a big success.

This can go off the rails in a number of ways, but key to many of the failure modes is that it mostly avoids contact with the external world up until the end. People spend most of their time in a context where their focus is on conforming to other people’s notions, rather than the real environment.

On a truly Agile project, you try to avert this through particular practices, like frequent releases, weekly iterations, and energetic engagement with users and stakeholders. Rather than pretending that you can imagine your way to a good product, you put yourself in a situation where the environment pushes you toward a great product.

Technical dreams

This has parallels on the technical side.

All good programmers like to build things. In the wrong context, this can lead to developer gold-plating and infinite infrastructure. I once saw (but, thank goodness, didn’t work on) a system that spent $120 million on years of planning, development, and initial rollout. Many years into the project, it only had 4 working screens, which wasn’t enough to be useful to anybody. But it had plenty of infrastructure.

More insidiously, technical choices tend to be self-reinforcing. Suppose in the first week of a project a team starts out with an SQL database, just because it’s convenient. If you point out to the programmers that they’re making a big technical choice on the basis of minimal data, they will say: of course we can change the design later. But there’s a reason that those programmers work for a paycheck while Oracle’s Larry Ellison has $20 billion in the bank and collects exotic jets. Only Larry understands that very shortly they will have a hard time even conceiving of making that change.

To avoid these perils, it’s important to follow practices like simple design, pair programming, automated testing, merciless refactoring, and YAGNI. But just as important is to think just like great product managers do: treat the project as a series of small bets. Instead of grand architecture visions, it’s more effective to continuously run small experiments that help you decide between different design options.

If you structure your environment to force continuous learning and small, feedback-driven steps, your thinking will come to reflect that. And you’ll be better off for it.

10 rules for great development spaces

Sidereel main room

Building a great team development space is tricky. You have to balance a lot of factors: human, social, environmental, economic, and personal. There is no universal solution, but I wanted to share a few lessons I’ve learned over the years.

Note that these only make sense if having a productive team is a high priority. For a lot of organizations, other motivations regrettably win out.

My 10 rules

  1. Put everybody vital to the project in one space. Agile methods are built around communication. Having everybody together means that instead of having to work to communicate, they’d have to work not to.
  2. Isolate the team from off-topic noise. You want to create a space where people are comfortable listening to the conversation around them. Most of what they hear should be related to the work at hand, at moderate volume, and free of drama.
  3. Have plenty of wall and whiteboard space. The workspace should be richly informative, with product plans, task lists, backlogs, charts, and source material obviously present. Make it easy to know what’s going on.
  4. Allow room for a daily stand-up. Every morning, I like to have a team get together and spend a few minutes getting back in sync about what’s going on. That will often involve referring to in-room artifacts like task breakdowns, backlogs, and interface sketches. Give them enough room to huddle up!
  5. Pairing WorkstationGet collaboration-friendly desks. I’m amazed by the number of companies that talk up collaboration and then buy furniture that is actively hostile to it. Whether or not the team officially practices pair programming, every development station should allow two people to sit comfortably side by side and have equal access to the screen and keyboard.
  6. Minimize distractions. For programmers, interruptions are doom, causing lost productivity and decreased product quality. (This doesn’t apply as much to non-programmers, but those folks should still be wary of distractions.) To minimize chaos, I often suggest these rules for development stations:
    • No phones. Some teams avoid individual phones entirely; others just keep them away from development stations.
    • No email or IM. Relegate that to machines out of or at the edge of the main work area. A common solution is shared development stations, with personal laptops for email, IM, and the like.
    • No off-topic conversation. Agree that if even one person is concentrating, off-topic conversation must happen out of the team room.
    • Executives stay muted. Often higher-ups are used to being the center of attention. Some teams have learned to keep working, but that requires the bosses to be quiet and modest in their demeanor. If the execs can’t do that or the team can’t ignore them, keep them out during periods when work is getting done.
    • Control foot traffic. I like to put developers away from the door, with managers, product owners, and designers closer to it. Visitors are very likely to talk to the first person they see; if that’s the person most able to help them, that’s better for everybody.
  7. wall-o-cardsOnly direct contributors sit in the room. The people sitting in the room should be focused mainly on the project at hand. A good solution for part-time contributors is to have guest desks, so that they can be present when participating and return elsewhere when they aren’t. People with unrelated work, especially noisy work like sales, should never sit in the room.
  8. Have necessary spaces nearby. Making software should be the primary focus of development teams, but make sure to allow space nearby for other important activities. These can be formally designated areas, or informal things like spare offices and nearby coffee shops. Often they are shared with other groups. I like to see:
    • Small meeting areas. These should suit one person who has to take a phone call, or two to three people who have to meet.
    • A large meeting area. This need is usually filled by the classic conference room. Whiteboard space is mandatory.
    • A lounge. Office space should encourage focused activity, but people need rest, and good ideas often come out of more casual conversations.
    • Related projects and staff. Communication patterns tend to mirror spatial patterns. Take advantage of that!
  9. Make the space pleasant. I’m not talking about gold-plated faucets here, just about making a space comfortable rather than hostile. Sure, people can work almost anywhere, but you should save their gumption for delivering value. This often includes:
    • NewEdu Team RoomGood lighting. Some natural light, supplemented by good room and/or task lighting. For whatever reason, programmers often hate fluorescents, especially the low-grade ones, so I try to avoid those.
    • Decent air. Team rooms often have a higher person density than normal, so it’s especially important to make sure that there’s good ventilation and temperature control. By 3 pm, too many team rooms smell like a packed dance club on an August night.
    • Comfortable, reliable furniture. I’m not talking about deluxe furniture here; often a mid-range Ikea equivalent is fine, and I generally suggest good tables rather than standard desks. But a shaky desk or an uncomfortable chair costs far more in productivity than it saves in cash.
    • Plants and decorations. It takes very little extra to turn a room from adequate into appealing. A little greenery and a couple of framed posters is a good start. Depending on company culture, a couple of toys can be good, especially ones that encourage interaction or collaboration.
    • Snacks. Food and drink is a central part of hospitality in every culture I’ve heard of. Normally I’ll put out some healthy snacks, like a bowl of fruit and some baby carrots, plus a water cooler or a fridge of bottled water. Typically I put more elaborate or less healthy things, like coffee, soft drinks, crackers, and cereal, in a kitchen or lounge area.
  10. Get good tools. The one area I think it’s worth spending a little extra is on quality tools, including things like whiteboards, IDEs, screens, keyboards, and build servers. Amortized over thousands of hours of use, even the high-end ones are practically free. Don’t waste time and energy with slow builds and dodgy tools.

But that’s too expensive!

Expense is a common complaint, but I don’t think it makes a lot of sense when you look at cost/benefit trade-offs.

If you add up what you’re already spending on a team for the life of a project, it’s going to be quite a lot of dough. And that’s not even the right number for comparison; any software team should generate a return on investment well above obvious costs. If what I recommend above yields even a modest improvement in productivity or reduction in turnover then it’s well worth it. In my experience, the gains are dramatic, not modest.

Startup OfficeBut that’s too hard!

Sometimes these things are hard for legitimate reasons. For example, moving offices or rebuilding part of your space is undeniably a lot of work. But some hard work at the beginning of the project is much easier than years of strain trying to compensate for bad working conditions.

Sometimes, though, this is hard because companies value other things more than productivity. Some teams can’t fix workspace issues because of office politics, too-rigid budgeting, control-obsessed furniture police, nonsensical corporate policies, dysfunctional decision-making processes, or the valuing of appearance over results. If that’s your situation, consider explicitly discussing your company’s cultural problems.

If you’re scared to even bring these issues up, it’s worth asking yourself whether you’re working at the right company. Your employer may not share your desire to get things done, but I promise that there are many who do.

For more info

I know of a few good related resources:

Have more? Please mention them in the comments.

Clicky Web Analytics