Author Archive

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.

Fad-proofing your Agile adoption

As Agile methods become more popular, they risk turning into a pointless fad. Here are my tips for avoiding that trap on your own projects.

Agile is the new black

A friend of mine is a founder at a startup that’s very Agile: weekly iterations, releasing 2-10 times a month, heavy test coverage, and lots of pair programming. He met for coffee with a friend of a friend, an executive in charge of building his company’s first significant piece of software. Part of the conversation went like this:

My friend: So, how are you developing your software?

Executive: We’re doing Agile!

My friend: That’s great! We started out two years ago with a typical Extreme Programming set of practices, but since then we’ve made a number of significant changes, including [list of new and modified practices]. And we’re still continuously improving. How about you?

Executive: We’re doing Agile!

My friend: [Sighs, shakes his head sadly.] Nice weather we’re having, isn’t it?

In my experience, this is becoming more and more common: somebody hears that Agile is what all the cool kids are doing, so they take a very shallow understanding of what that means and run with it. This rarely works out well, and always puts me in mind of somebody who goes to a buffet restaurant and makes a meal out of the desserts. It’s theoretically appealing, but the long-term costs are fearsome.

Fad-proofing your Agile adoption

Agile methods have become popular because there’s real value to them. However, just jumping on the bandwagon won’t do you any good. Take the time to think through what you’re trying to achieve. Do an Agile adoption poorly and people may become cynical enough that you won’t have another chance. Here are 10 things you can do to help:

  1. Focus on what works – Your team isn’t there to create process or make software. You’re there to deliver sustainable long-term value via software. Use that as your primary ruler to measure success.
  2. Don’t expect miraclesThere are no silver bullets! Agile methods don’t fix your problems for you; they mainly make the problems obvious quickly, so you can solve them yourselves.
  3. Give yourself room – Thinking that “doing Agile” must be quick and easy, many teams don’t allow enough time to learn how to make the practices work well for them. Allow for an initial productivity hit, one that will get paid back richly down the road.
  4. Don’t get suckered – Now that “Agile” is a big buzzword, there’s an equally big incentive for consultants and authors to sell you Agile lite, the software process equivalent of cotton candy. Don’t fall for it!
  5. Don’t just “do Agile” – I’ll tell you a secret: there is no “Agile” that you can do. There is a collection of Agile methods; you can do any one of them. There are a whole host of practices to adopt. But unless you know enough to tell them apart, you don’t know enough to do any of them well.
  6. Get help from people who have done it – As a coach, I’m probably a little biased, but I think everybody who tries an Agile approach should involve somebody who’s done it before. Whether that’s a key player, a manager, or a coach doesn’t matter much. But it’s hard to learn Agile methods from books, let alone a couple of articles on the web.
  7. Track and pay down your debt – Part of an Agile adoption is raised standards. That leaves most people with a lot of cleanup to do. Make a list of all your code debt and testing debt, and have a plan for paying it off.
  8. Push power down – Agile methods do best in a context where teams are given broad latitude to solve problems on their own. Focus on supporting rather than directing your Agile teams.
  9. Improve continuously – An Agile method isn’t something like a turbocharger that you bolt on once and then use forever. If you aren’t having regular retrospectives and continually improving your process, you’re not Agile.
  10. Use your ignorance for good – One of the biggest mistakes people make is thinking that even though they’ve never used an Agile approach, they know enough to make big changes to it from day 1. Instead, accept that you’re trying something truly new to you, and act like it.

Feedback wanted

Have any war stories about the dangers of being fashionably Agile? How about tips on doing it right? I’d love your comments, and other readers would, too.

P.S. Hat tip to my old pal Christopher DeJong for the phrase “Agile is the new black”.

The 3 kinds of code

You can look at any chunk of code as belonging to one of three categories. Confusion between them plus a misunderstanding about the relative cost lead many people into trouble. With a little communication and some discipline, you can save yourself a lot of pain.

The 3 kinds

A few weeks back, I had to help smooth over a conflict between two co-workers. One was a seasoned developer. The other was a businessperson who just wanted some things added to their company’s web site. The conflict arose because they had very different ideas of the costs of software.

For their purposes, there were three plausible paths to take, matching the three kinds of code:

  • Temporary – Code written with a plan to throw away in a day, a week, or maybe a month. If it breaks, that’s ok — we were going to get rid of it anyhow.
  • Sustainable – Code that’s built to last. Well factored, well understood by the team, with strong automated tests, and generally meeting the team’s standards for something they’d happily maintain forever.
  • Half-assed – Everything in the middle. Code written by amateurs. Quick fixes that become permanent. Rush jobs. Things written when people say “we’ll clean it up later” and don’t.

When the businessperson expressed their desires, they wanted something cheap and quick. However, they didn’t want it to be fragile or throwaway; it had to be reliable and last indefinitely. They proposed bolting on an off-the-shelf solution that fell in the “half-assed” category. When the developer reacted poorly, they couldn’t understand why.

Follow the money

The misunderstanding comes because they had different perceptions of the costs:

businessperson
view
developer
view
Temporary low low
Sustainable high medium
Half-assed medium high

Given their perceptions, it’s natural that the businessperson would prefer the half-assed option. It’s more valuable to them than the temporary option. But doing things sustainably doesn’t get them any apparent increase in value, and they think it costs them more. Just as naturally, the developer resists what they see as the high-cost option.

In truth, they’re both right. They’re just looking at different sorts of costs. We can rewrite the column headers this way:

short-term
costs
long-term
costs
Temporary low low
Sustainable high medium
Half-assed medium high

The experienced developer is more aware of the long-term costs not only because they have more experience, but because long-term costs are generally thought of as their problem. As the maintenance costs of half-assed code add up, they won’t be attributed to last year’s excess schedule pressure from business stakeholders. Instead, the developers will be perceived as increasingly unproductive or unreliable.

Of course, that’s not just bad for the developers. It’s bad for the company as a whole. If a company’s costs for software continuously increase, that eventually becomes a powerful advantage for competitors who are more thoughtful and disciplined about their approach to software development.

Don’t fall in the trap

This is why many parts of the Agile world either explicitly or implicitly rule out the option of writing half-assed code.

Extreme Programming, for example, started out with a number of sustainability-focused practices, including pair programming, test-driven development, and merciless refactoring. As the book Planning Extreme Programming says, “With most of our planning, we assume that quality [is] fixed.” This continues up to the present day with efforts like Bob Martin’s Manifesto for Software Craftsmanship.

No matter what process you use, you can avoid the trap of half-assed code:

  1. Make sure everybody agrees that they are in it for the long haul.
  2. Educate stakeholders on how expensive supposedly cheap solutions are in the long term.
  3. Whenever people agree on a temporary solution, make sure that it is really temporary. In particular:
    • Agree in advance on the end date and expected issues. Write that down.
    • Budget for the costs of removing the temporary solution.
    • If a permanent solution is to follow the temporary solution, budget for that, too.
    • When the end date approaches, people will try to fudge it. Politely refuse, reminding everyone of the earlier agreement.

In addition, be constantly vigilant about half-assed code returning in disguise. For example, a lot of people get sold on outsourcing or offshoring because it looks cheap and easy. Sometimes it might be, but most of the projects like that I’ve seen are really half-assed code that got sold as sustainable. Just as dangerous is the cowboy coder who rides in to save the day, but leaves a lot of half-assed code behind for other people to deal with.

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.

Clicky Web Analytics