The Agile approach to software development has been one of the more fun innovations of the past few years. It’s fun because so much of Agile involves saying out loud truths which everyone knew but no one would acknowledge or act on. Things like: “No Product Requirements Document ever gets implemented as written.” Or, “We can’t predict the outcome of a coding project.” Or, “Businesses don’t know what they want, but they’ll know that what you gave them isn’t it.”
There are a lot of interesting aspects to agile development, but I want to start by focusing on the core—the irreducible minimum, if you will, of agile development. It seems that everyone has their own idea of what aspects of agile to try. The purists (and consultants) will tell you about stand-up meetings, pair programming, and a hundred other new and unknown processes. Businesses trying to adopt agile take a more limited approach—often just breaking their task list into small chunks and closing frequent baselevels. This cautious approach is understandable—you can eat an elephant if you take it one bite at a time—but if you trade off the essentials, the process just isn’t going to work.
The essential core of agile is fast iterations tested with user feedback. Everything else is there to make that core work better, faster, or in a more organized way. Throw away everything else if you must but don’t trade off this core. Let me explain why.
Fast iterations are the basis of all agile development—that’s what makes it agile. The theory is in a changing world with unclear requirements and disruptive technology we can never be certain that our plans will work out in practice. So we never do too much without feedback—we do a little, check our progress, redirect if necessary, do a little more, and so on.
This is a fundamental way of managing risk and the more risk, the more fundamental it is. The avionics for the space shuttle were developed using an iterative approach because, they said, the waterfall model could not be used due to the “size, complexity, and evolutionary nature of the program”. [fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][Madden and Rone, “Design, Development, Integration: Space Shuttle Flight Software System”, Communications of the ACM, Sept 1984] This also keeps the developers honest—at regular, frequent intervals they have to show that they are producing measurable value.
But of course, there’s no point in doing fast iterations if you don’t check your progress. And for a system that is to be used by people, that means checking with your users—most especially the direct end-users of your system. This feedback corrects errors early, ensures that you’re delivering real value, and reveals mistaken assumptions and approaches.
In some ways, the early development of WordPerfect—the first widely successful word processor on PC’s—illustrates agile development perfectly. The developers, Bruce Bastian and Alan Ashton, worked for the City of Orem, and their offices were downstairs from the secretaries and administrators their new word processor supported. They’d take a new kit upstairs, install it, see how their users responded, run back downstairs with a list of problems and new ideas, and have another kit ready in a few days.
But few of us live downstairs from our users. It’s tempting to want to get feedback on the cheap—identifying some kind of user surrogate instead of the real end-users. Maybe the Product Owner can pretend to be the user—though he works for our company and doesn’t do the work himself. Maybe we can hire a user to work for us—even though that means they’ll no longer be doing the work and come to share the development group’s outlook. (One agile group who tried this approach said, “They are just too nice to us.”) Maybe we can just do demos—even though user feedback in demo situations is notoriously unreliable. None of these options for feedback on the cheap are good enough, in the end. There’s no substitute for checking in with real users.
Later I’ll talk more about various aspects of agile development and how that fits with the organizational product development process and with user-centered design. But those are details. In the end, agile development always comes back to these two things—iterate quickly, check your progress. If you do these well, you won’t be going too far wrong.
[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]