Chapter 2: Agile Methodologies and Approaches
Chapter 2: Agile Methodologies and Approaches
24
First of all, if you have doubts when you first encounter Agile, welcome to the club. Rest assured that
everyone who takes a closer look and sees Agile in action usually crosses over.Second, many people out there made the initial mistake of distinguishing Agile methodologies as
somehow “ lightweight ” (as opposed to the heavyweight models like waterfall) or “ unplanned ” (which
inspires the mistaken belief that Agile developers are undisciplined).A better way to look at Agile is to say that the entire process is adaptive instead of predictive. For
example, if you were to start a project using waterfall methods, you would spend a lot of time trying to
nail down schedules, resources, requirements, deadlines, milestones, and the like. If anything changes,
you have to go back and reevaluate your initial inputs. It ’ s very much like planning a road trip to Las
Vegas down to the last detail (including where you would make rest stops, how much gas you would
buy at each gas station, what sandwiches to pack) but then encountering a sandstorm right at the edge of
the city and having to turn back home to try again later.An Agile road trip to Vegas would be different. The process would start with a focus on gambling in
Vegas, and then a minimal amount of work would be done to get the car ready and rolling. Everyone
would bring his or her own snacks and gas money. Once on the road, travelers are free to take advantage
of opportunities. Perhaps someone sees a casino just outside the town they left from, and the group
decides to gamble there. After all, the goal is to gamble, right? It ’ s this kind of adaptive thinking that
gives Agile its power and flexibility.Third, many outsiders have a bone to pick over the short iterations in Agile. They can ’ t conceive that
quality software can be developed in a week or two. Normally, this assertion would be true, but with the
right tools (i.e., CodeIgniter and other MVC frameworks, especially those that focus on delivering
convention - over - configuration benefits), you can achieve in hours what normally would take days or
weeks. Most people don ’ t stop to consider that an enormous amount of overhead time is devoted to non -
programming tasks. Developers tend to forget the painful hours spent in meetings, all the hours devoted
to planning and analysis, and all the time spent debugging. On a typical project, a developer might
spend 2 to 3 hours a day programming and the rest in meetings, debugging, documenting, or
researching a tough problem. If she ’ s lucky! On the other hand, it is possible, with the right tools and the
right methodologies, to create shippable software in very short iterations. The result is working software,
happy customers, and developers with a sense of job satisfaction. What could be better?Are there places where Agile is not a good idea? Of course: Agile works best when you have smaller
teams in one location, more experienced developers, quickly changing environments, and a culture that
is not exclusively driven by top - down command and control structures. In other words, trying to build a
giant weapons software platform for the Army that involves 1,000 developers in three geographically
separate locations would probably not make a good case study for any Agile methodology.That being said, your average web application can easily be built following Agile. It doesn ’ t matter what
kind of application: blog, newsletter tool, content management, shopping cart, or content portal. If you
can keep the team under 20 developers (or better yet, a dozen) and keep them communicating well,
you can pull it off.