I recently read through 37 Signals’ excellent manual, Getting Real. It describes in detail a successful method for developing and launching web-based software. Many of its tenets are based on the principles of Agile Development, first articulated by Kent Beck et al in The Agile Manifesto. There is so much hope and good will in these documents – it makes me a little sad. Agile started out as a way to free software developers from the chains of a brittle, dogmatic technology age, where change was viewed as expensive and collaboration dangerous. Agile is supposed to tilt development toward the ways in which developers naturally work. Despite its promise, agile has become one of those professional chew-toys that has been so thoroughly mangled and salivated over, it’s barely recognizable anymore. Many of its principles have been diluted by blind adoption. At the same time, Agile Development has a dark side. It’s the perfect crutch for refusing to do the diligence that’s required on many tech projects, and, sadly, for denying developers the avenues it was meant to open.
Agile Development is in danger of slipping into the ditch already occupied by brainstorming sessions, train-the-trainer, and team-building: that of management double-speak and great ideas used as excuses to continue the same old practices.
I know I’m not the first person to point all this out – however, unlike many of them, I don’t see Agile as a panacea or a ploy. It is precisely because I believe in the principles of Agile Development that I feel a little twinge of pain when I see it going wrong. Rather than trying to forecast why it must fail or trumpet its invincibility, this post is simply trying to paint some yellow stripes on the bumps in the road, in the inevitable web list format:
1) Working From Small To Large – Agile Development aims to put practical decision-making in the hands of the people doing the work. This sounds dangerous to the people who ostensibly have the “vision”, as they realize that real-world concerns are shaping “their” project. However, this is only a problem when there are errors in the vision in the first place. As Getting Real aptly points out, this style can only work when a motivated team understands and embraces the vision of the project. If management thinks, “well, I’ve got a superb and agile team of developers over here and a great concept over here – now all I have to do is start assigning tasks”, the project is doomed to snarl. After all, agile development teams don’t need reams of documentation and planning, right? Sometimes that’s true, and then only if they deeply understand the goals of the project. Agile Development is like high-end audio gear. It can make everything shine, but it will also highlight all the flaws. Make the effort to get your direction aligned before you start your project running. You want a nimble bobsled team, not a game of tag.
2) Agile Development on a Non-Agile Project – How many workstations have felt the concussion of a developer’s forehead after the project manager (or the project manager’s manager) stops by to report that the glorious, elegant solution the developer came up with is nixed for a reason that the developer herself had pointed out weeks, maybe months ago. Agile teams are supposed to respond to change quickly and enthusiastically. However, agile precepts are corrupting when applied to non-agile projects. If the business isn’t sure what they want, it means trouble for most projects, but an immediate fail for an agile project, which is better adapted to change, but also more vulnerable to it. Even cases where the business side is focused may not be suitable for agile methods. For example, one of the main tenets of Agile Development is that developers and business units collaborate to find the best approach for the customer. If you are Apple, you make your living by exceeding the curve and leading your customers (in theory) to the right place. However, if you are in an industry that requires stable, trusted solutions (banking would be one that comes to mind), you would do well to temper that agile enthusiasm with a solid dose of risk assessment.
3) Teams Not Independent – Unlike the previous examples, this one is a prime example of giving lip service to an idea while ignoring it completely in the day-to-day life of a project. Micromanagement and agile do not go well together. Though this is a well-known problem in many types of projects, it actually goes against everything agile stands for. The Agile Manifesto points out that face-to-face discussions are the most effective means of conveying information. But what do you do when you’re having a face-to-face conversation with someone who wants to insert personal preferences into his developers’ work? Or when management cannot protect the team from peripheral, time-sapping requests? In these cases, it may be best to put your nose to the grindstone and polish up your resume.
4) Over-Employment – So far, we’ve touched on common problems, but this point is rooted directly in the areas where agile excels. The concepts of Agile Development have proven so successful that many developers expect to find them on day one: being able to call on business personnel to clarify / collaborate over requirements and solutions; the use of small teams to accomplish discrete tasks; flexibility in planning; experimentation and prototyping as integral to the development process. When you’ve got it, you don’t need to push it. You don’t want to show off the strings you just cut and find yourself holding the strings in the process. If your developers are in the comfort zone, don’t push them out of it just to try and fulfill what someone says is “properly” agile.
5) Scope Defenses Are Down – We’ve all heard that change is key to success, and in the world of software development, the ability to rapidly change direction can mean a decisive edge on the competition. But there is a big difference between an agile redirection of resources and a stumbling, careening project that no longer knows where it’s going. Part of this involves scope. Imagine a current of water traveling through a gulley. You realize you need to divert the gulley 90 degrees to the left. What happens if you dig out a leftward channel but also leave the gulley intact? Imagine doing this every time the project needs a change – you are left with a flooded delta, not an effective change. If developers or managers are thinking “this is an agile project, so scope creep shouldn’t matter”, they are lining themselves up for a waste of resources and a messy, unfocused project – there is nothing agile about that.
6) Weak Push-Back – If Getting Real gets unrealistic at points, it’s probably in the area of push-back on feature requests. Sure, if you’re a crack team of multitalented developers and designers with a shared vision and a successful product, you can afford to ride out an initial wave of resistance as customers adjust to your latest release. When you have a corporate customer relations manager whose phone banks are blowing up, and he’s coming over to speak with your boss, things “get real” in a hurry. For Agile Development to fulfill its promise of responsiveness, developers must – somewhat ironically – be allowed to provide context to the business. As usual, communication early and often is key. Remember that good developers want their applications to be effective and well-received. Imagine that your team and the business are on the same page, you think you have a brilliant answer, you roll it out, and the users hate it – and continue hating it. Agile Development can really shine for you here. Now imagine the same situation, except that the developers knew users would hate it, and they said so, but you didn’t listen? How is the fix going to go?
7) Paying The Bills – An agile team should, according to The Agile Manifesto, be able to run indefinitely, making changes and adjustments, keeping up a regular pace. This does not mean, however, that kludges and workarounds should be allowed to fester when they can be cleaned up. Get Real puts it well: “The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don’t, you’ll just be paying interest (fixing hacks) instead of paying down the principal (and moving forward).” If your team is maintaining a constant pace, they’ll be fixing these issues eventually. Better to account for it.
8) How Do We Do This – Agile Development requires not just developer feedback on the project itself, but developer feedback on the process. The Agile Manifesto calls this “tuning”, and requires it at regular (and, we can assume, scheduled) intervals. Failure to pay heed to this tenet of the manifesto results in what I like to call “Casual Development”, with everyone plugging along, ignoring opportunities to create efficiency and save time and money. Can there be a better rationale to the business side than “this will save you time and money”? A regular reflective breather helps create more smoothly running teams and exposes issues that may be silently eating away at a project. It also gives deeper meaning to the term “agile” itself: the ability for a team to self-diagnose and fix issues before they arise.
9) Docu-drama – As someone who enjoys writing, making diagrams, and having sensible project outlines, I’ve never had a problem with documentation, unless it’s bad documentation. Some developers and managers act like documentation is a pure waste of time, or else as archaic as stone tablets. This is hubris. Thinking that having an agile project means documentation is superfluous is to ignore the experience and wisdom of others – is your project so cutting edge that no one has ever attempted anything like it before? Then maybe you don’t need documentation, and you can just wing it on the strength of your genius. Will no one ever touch your application besides you and your team? Surely if they do, they will simply read through your sublimely intuitive and graciously commented code and instantly intuit exactly what is going on. Just like pre-writing is a great creative exercise for all kinds of non-linguistic projects, documentation is immensely helpful to produce, even if you think you’ll never need it. Go ahead, get your thoughts, your vision, your risks and assumptions, you technical specs down on paper. You may be very glad you did.
10) Users? What users? – Oh, the poor, poor users. Who is looking out for them in the world of Agile Development? One of the main creeds of Agile Development is that everyone should be looking out for the souls who have to use our wonderful applications. Too often, no one is looking out for the user, so caught up are they in the idea that in the modern, agile era of development, all the user has to do is wait until the next release. The truth is that sometimes the business and the development teams get together and end up with zero idea of how users are going to react. Here we come full-circle: some projects are well cut out for Agile Development, and some are not. If you are a small startup and you’re desperately trying to get your app to market, agile may be what you’re looking for. If you’re in the midst of transitioning a legacy application that thousands of users are relying on daily, you may want to (shudder) think of your users first and your developers second. As I’ve pointed out, many agile habits have already worked their way into the mainstream, so don’t be afraid to be a bit selective about how far you want to push the methodology on any given project. At 37 Signals, users can marvel at the process, but that doesn’t mean your users necessarily want to be made aware of your process. It pays to spend the time and effort to get to know your users.
Agile Development is neither a gift from above nor a mere trend – it’s an important crystallization of ideas that can often provide real clarity of purpose for developers and help projects adjust to a fast-changing world. But it can also be a destructive force if used carelessly. It’s like business casual: it can be fun and freeing, but in some circumstances and some hands, it can be disastrous. I hope this post helps you choose your outfit wisely.