What Is Agile?
A lot of different definitions for Agile exist, ranging from the superficial to the authoritative and
pedantic. Not every definition is useful, nor is every definition really applicable to your job as a
software developer. Things only get more confusing once you realize that various Agile
methodologies exist, all of them competing for your attention.
At the end of the day, the most important thing to remember is this: Agile software development is
a conceptual framework that seeks to minimize risk by developing software in short amounts of
time. A typical iteration can last 1 to 4 weeks, during which time a software team performs tasks
from a complete project life cycle (planning, design, coding, testing, documentation). Each iteration
usually starts with stories (what Agile calls requirements ) and culminates in potentially shippable
software. Another important aspect of Agile is the team’s ability to self - organize as they
communicate face - to - face with stakeholders and other team members.
If you ’ re not familiar with Agile, you probably have one of two reactions:
- “ How is this different from cowboy coding? Agile sounds just like every chaotic code - and -fix project I 've ever been part of. ”
- “ How does anyone get anything done in so short a time? Agile sounds like a perpetual hamster wheel where everyone burns out. ”
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.
Post - Agilism
Any successful movement will have some members who eventually move on to something else. In the case of Agile methodologies, there is Post - Agilism. What is Post - Agilism? It ’ s a loose group of developers and other IT professionals who have experience with Agile but have now moved on to other approaches.The most thoughtful Post - Agilists (if they would allow themselves to be labeled as such, and even that is up for grabs) make a fine distinction between being “ agile ” (defined as being adaptive in a social or commercial circumstance) and being “ Agile ” (living by the rules, dogma, or inherited wisdom of a particular Agile methodology, like Scrum or XP). It ’ s therefore possible to be “ agile ” without necessarily having to take on all the trappings of any particular Agile approach.
Of course, the way I am using “ agile ” and “ Agile ” here is merely to differentiate the concepts. Within the Agile community and throughout this book, “ Agile ” is the way you see the word presented. There is no formal distinction between “ Agile ” and “ agile. ”
Another extremely valid concern brought up by Post - Agilists (again, please forgive the use of broad
labels) is that the Agile movement was once about shaking the industry out of the waterfall
methodology, the predictive mess to which everyone was so well accustomed. Now they feel that
everyone is trying to follow the Agile Manifesto (and other touchstone documents) as some kind of
canonical bible, replacing the earlier problem with a newer adherence - to - dogma problem.
To be clear, any time that “ Agile ” is mentioned in this book, it is in the spirit of little - “ a ” “ agile. ” It is more important for you, the developer, to be adaptive and successfully complete a project than to adhere strictly to the rules of a certain methodology.
Notable Agile Methodologies
Some people feel a little anxious about mixing methodologies. However, that is actually at the heart of being agile . Where Agile with a capital “ A ” focuses on the purity of the model, agile with a small “ a ” focuses on freeing you up to do whatever will help you quickly and easily achieve your goals. Being “ agile ” is about being adaptive and fast on your feet.In the real world when you are working with clients, any time you have to decide between getting things done on schedule and strictly adhering to theoretical rules, always err on the side of getting things done.
It may get under your skin a bit, but it ’ s really the only way to keep the customer happy.
Scrum
Scrum is an Agile project management methodology that offers small teams a great deal of flexibility(even by Agile standards). Here are the typical attributes of a Scrum undertaking:
- You need a product backlog (fr:"carnet de commande")— a prioritized list of work items that need completion.
- The self - organizing team uses the product backlog to create sprint backlogs .
- Each sprint is a short period of duration (usually 1 to 4 weeks) in which highly focused activity takes place.
- Each sprint begins with a sprint planning session , in which backlog items for the sprint are defined.
- Each sprint ends with a retrospective , in which a postmortem is performed.
Scrum recognizes that customers are wont to change their minds about what they want. Sometimes the changes in direction are subjective and capricious, and other times they come about because of market pressures. Regardless of the reason, change happens, and normal predictive methodologies have zero chance of predicting these changes (ironically). Instead, Scrum accepts that change is inevitable, unpredictable, and indefinable, and focuses instead on maximizing the team ’ s ability to adapt to change and still deliver a great product.
The team works closely with stakeholders (such as business owners, marketing managers, the CEO,
CFO, etc.) to develop a backlog of requirements that need to be addressed. Normally, this backlog of
requirements is maintained by a certain stakeholder called the “ product owner. ” In most cases, the
product owner is the CEO, but it can also be a marketing manager or project manager
The backlog is essentially a list of prioritized requirements that emanate from the end - customer. At the start of each sprint, the team takes the top remaining items from the product backlog and turns them into tasks on the sprint backlog. It ’ s important for the team to only take on as many tasks as can be completed in any given iteration.
The goal of any iteration is to create potentially shippable software — in other words, by the time you ’ re at the end of the time box (1 week, 2 weeks, whatever), what you have could be considered ready to ship. It is functionally complete, reasonably bug - free, and reasonably documented.
For example, a product backlog might have several prioritized items on it, like so:
- The customer wants to be able to securely check page views and other stats about their web site.
- The customer wants hyperlinks within the report.
- The customer wants real - time access to data, without lag.
- The customer wants info graphics associated with the data, not just tabular data.
- Create views to display the report.
- Create models to connect to data sources.
- Create a controller to identify and separate different destinations.
- Implement a security model.
organizing, the HTML/CSS expert would tackle the views, the database expert would construct the
models, and the security expert would implement the security model. If no security expert is on
the team, perhaps someone remembers that a security module was written for another project — might it not be useful in this context?
The sprint is set at 2 weeks, and the team takes on the tasks, meeting every day for a standup meeting that lasts no more than 10 minutes. At each meeting, the ScrumMaster asks three basic questions of each participant:
- What have you done since the last time we saw you?
- What are you going to do until the next time we see you?
- What obstacles or barriers are in your way?
concerns . The standup meeting allows the entire team to check in and understand how the project is
going with a great deal of transparency. Very quickly, everyone gets a feeling for what ’ s been
accomplished, what is still left to do, and what ’ s standing in the way.
Outsiders (other than developers, ScrumMaster, and product owner) are allowed to join the meetings, of course, but they aren ’ t allowed to interfere directly in the project. What does “ interfere ” mean?
Well, in many software development projects, you see many business managers or complete outsiders dictating requirements. These requirements don ’ t come from the customers, they just arbitrarily live in the minds of senior management or outside stakeholders. Often, these arbitrary requirements impede schedules and complicate matters.
For example, there is rarely any real value to a requirement like “ It must ship in Q1. ” In the mind of the person who brought it up, it has importance, but not to anyone else. What does that mean? Well, on somebody ’ s strategic plan, such - and - such a product must ship in Q1, and the stakeholder ’ s bonus depends on it. The customer doesn ’ t care when the product comes out, just that it works the way they need it to when it does come out. (This is not to say that you should totally disregard a powerful stakeholder ’ s concerns about schedules and money. After all, they will hopefully be rehiring you or referring you to another business in the future. Treat them seriously and with respect. Just don ’ t let their concerns interfere with what you need to do to accomplish the project.)
What concepts are you going to take from Scrum? The idea of a backlog is key, as is the nature of sprints.
You ’ ll find that on many small projects, a sprint can last 1 or 2 days. You ’ ll also find that you don’ t need to have a daily standup meeting, especially if it ’ s just you working on things.
XP
The main thrust behind XP is to put in place daily practices that reconcile humanity and productivity.What this means in practice is that there is more weight given to face - to - face communication and
feedback than to formal requirements’ gathering.
Furthermore, XP proponents expound on the value of doing something simple and clean today rather
than worrying about future problems that might entail complexity. For example, why worry about
scaling to 50,000 customers when you only have 5 customers today? Wouldn ’ t scaling out to 500
customers (or even 50!) be good enough to get something working now?
Another great thing from the XP movement involves the collegial respect between programmers.
Contributions are made in a give - and - take environment, and in fact, many programmers pair up to
tackle problems and work through issues. Finally, there is the matter of allowing programmers to take
ownership of their code. It is not unusual to see programmers refactor code to simplify even when it isn ’ t needed.
What are you going to take from XP? Definitely the simplicity and communication/feedback loops. It ’ s important to incorporate good listening skills to any Agile approach. When working with a client one -on - one, you will need to interface often. Make sure that you allow a significant amount of time for the face - to - face contact, as it can create a powerful bond between you and the client.
Modifying Scrum and XP
Scrum and XP (extreme programming), like all methodologies, are wonderful things, but one immediate drawback for you right now, as you read this book, is that you ’ re probably a lone programmer or work with a very small team. If so, you may be thinking that these approaches provide too much overhead even for you, and in some ways, you might be right. However, one of the great strengths of any Agile methodology is that it can be adapted to your needs.CONCLUSIONS
- Agile methodologies are adaptive as opposed to predictive.
- Agile methodologies work best if you’ve got a small team working with a software project that is easily time - boxed. The team should meet regularly (daily if possible) and communicate about their achievements, to do’s, and risks.
- It ’ s almost always better to gather requirements by starting top - down and drawing mockups (fr: maquettes) with the customer.
- It ’ s important that the product owner (the customer) take charge of the product backlog as soon as possible. They ’ ve forgotten more about their business than you ’ ll ever know.
- It ’ s your job as developer to convert product backlog items into functional tasks in a sprint backlog.
- It is also your responsibility to estimate properly. Don ’ t overcommit with too many tasks in any given sprint.
- Don ’ t forget that many functional tasks can be leveraged across various areas of the current sprint (and even future sprints). For example, setting up good models for each database table allows you to quickly and easily work with those database tables for the rest of the project.
- The point of Agile is to break projects into manageable chunks. The emphasis is always on potentially shippable software at the end of any iteration or sprint. If a task can ’ t be completed properly or on time, it ’ s good and proper to try to reanalyze its importance and do something about it, instead of letting it fester and become a big problem.
- Because Agile projects tend to be iterative, it ’ s sometimes hard to give accurate estimates to customers. Remember to think in terms of time spent on units of work and in iterations, and only give ranges. The further out the timeline, the less accurate you can be. The bigger the unit of work, the less accurate you can be. For example, if you are estimating a 2 - week job, you might give an estimate that is plus - or - minus 5 percent. A 6 - month job may be on the order of plus - or -minus 30 percent.
