Agile in practice

Software development models are almost as malleable and tractile as software itself. There are no absolutes in how to get from start to finish, no building inspections to pass, no physical structures or environments dictating what has to happen when. A software project can feel like a creative writing class. The teacher might have scheduled draft deadlines and story reviews throughout the semester…or they might have left it all up to the students and just told them to bring a finished story to the last class.

The agile movement didn’t invent the idea of iterative development, code reviews, frequent feedback from customers, or automated testing, but it helped popularize them. Advocating agile development used to be a revolutionary call to arms, but now it’s just an embrace of the establishment. Everyone is agile, or says they’re agile. There’s a cottage industry of agile consultants and certifications ready to help the few lumbering non-agile sloths still left out there. Meanwhile, there’s a murky backwater left behind that, whether they speak up or not, doesn’t quite see all the promised benefits or trip on the way to the promised land. For a doctrine that’s supposed to be ultra-adaptive and flexible, the Agile behemoth does not treat kindly those who find faults with it. And with that in mind, here are some faults found not in rock star super-hip start-ups, but just mundane garden variety software shops that probably resemble where a lot of people work.

Really, we’re not supposed to plan anything? Martin Fowler wrote years ago about the tension between agile practices, which condemn big, initial designs, and software architecture. Agile is deeply skeptical of planning and assumes it will result in tedious, overly detailed designs that will suck up time and resources and most likely change before they’re implemented anyway. There is a little discussion of agile architecture, but really, you know where agile’s heart is.  Plan less, do more! That may sound great to those who have worked at big bureaucratic companies like Chrysler, but believe it or not, there are places where not enough design goes on, where developers stumble along meeting the most immediate requirements with quick fixes but accumulating huge technical debt that will never get paid off.

Change is not always cheap. If requirements always change and design always has to be revised, you might as well plan for change and try to accommodate it as cheaply as possible.  That’s the agile way and it’s good as far as it goes, but some change is painfully expensive. Maybe sometimes  a little more long-range planning would have helped. There is a risk that you will end up doing work that never gets used, but it’s not necessarily a greater risk than omitting work that is harder to add later. Continual refactoring may sound like a dream to developers, and no doubt it’s the best way to write quality software if you can do it, but most non-developers are less than excited about it. There are some situations, like when software is getting shipped out and updates are difficult, that trying to plan for possible future contingencies does not seem like such a bad idea.

Where’s my user? Talking frequently with the people who know what your software is supposed to be doing is common-sense, but what if you don’t have great access to your users? Agile calls for users to be deeply involved in the development process. It’s not agile’s fault if users can’t or don’t want to do it, but still, developers don’t choose their users, users choose their developers. What’s Plan B if you’ve got a bad user situation? Even if users are present and available, agile can minimize the difficulty of training users to be good collaborators in the software development process. Some people aren’t good at thinking through what they want. If you’re a front-end developer, you can at least show users what’s going on easily. Many people, though, have trouble following tedious back-end logic.

Sometimes, too, the user doesn’t know best. A home-owner can come up with a crazy idea that they’re architect or contractor needs to talk them out of. People can come up with really dumb ideas or misjudge the necessity of crucial technical details. The user is so emphasized in the agile world, there hardly seems any room for the developer’s professional expertise to sometimes overrule them.

You didn’t really follow agile. Off-hand, I can’t think of any methodology that blames problems on its users quite as much as agile. Maybe that’s just the nature of blog posts and responses, but when someone writes about having problems while following agile practices, inevitably, they are told that they didn’t really do agile right.  At some point, the agile movement needs to grow up and talk responsibility for its failures, and everything fails sometimes. Or to try to put it more objectively, what percentage of agile adopters have significant problems and at what percentage would agile proponents consider it an issue with the process itself and not just with clueless users?

This entry was posted in ruminations. Bookmark the permalink.

One Response to Agile in practice

  1. Enrique says:

    Agile seems like another variation on Structured analysis.
    The Issue of Users being unclear on their stories is classic . “Just what you asked for but not what you wanted or needed.”
    It seems to shift the Systems concept to the user who usually is responsible for defining the system being replaced.

    That said I have used elements of Agile for the past 20 years. and I used to call it mini JAD or Frameworks where working prototypes of the stories were produced very early in the Project.

Leave a Reply

Your email address will not be published. Required fields are marked *