What Is Agile?
Agile methodology is an alternative to traditional project management, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Agile methodologies are an alternative to waterfall, or traditional sequential development.
What is Scrum?
Scrum is the most popular way of introducing Agility due to its simplicity and flexibility. Because of this popularity, many organizations claim to be “doing Scrum” but aren’t doing anything close to Scrum’s actual definition. Scrum emphasizes empirical feedback, team self management, and striving to build properly tested product increments within short iterations. Doing Scrum as it’s actually defined usually comes into conflict with existing habits at established non-Agile organizations.
Scrum has only three roles: Product Owner, Team, and Scrum Master. These are described in detail by the Scrum Training Series. The responsibilities of the traditional project manager role are split up among these three Scrum roles. Scrum has five meetings: Backlog Grooming (aka Backlog Refinement), Sprint Planning, Daily Scrum (aka 15-minute standup), the Sprint Review Meeting, and the Sprint Retrospective Meeting.
Many books and classes are available from a variety of competing sources of varying accuracy and quality. One place to start would be the Scrum Training Series, which uses an entertaining approach to cover the most popular way of introducing Agile to teams. You can also download the 6-page illustrated Scrum Reference Card.
Where Did Agile Come From?
In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which criticized sequential development. He asserted that software should not be developed like an automobile on an assembly line, in which each piece is added in sequential phases. In such sequential phases, every phase of the project must be completed before the next phase can begin. Dr. Royce recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to this approach due to the lack of communication between the specialized groups that complete each phase of work.
It’s easy to see how the “waterfall” methodology is far from optimized compared to agile methodology. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?
Why Agile?
Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.
The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. Agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to continuously replan their release to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace. Development using an agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.
Posted under
This post was written by admin on October 23, 2008




It helps me a lot to understand agile methodlogy,but you sould use more examples and diagrams to make it more clear…
Thanks
Agile is good on papers but when it comes to actual implementation, changing requirement at each sprint is the real problem in a product.
How to deal with testing as the test case needs to be revamped at each and every sprint. In most cases, many a times the test case becomes invalid. Any suggestions relating to test design is greatly welome?
I shall be thankful if i can get the process (Quality Assurance aspect)for this methodology
It’s very useful, It helps me a lot to understand agile methodlogy.
Thanks,
It would be perfect if i can get the details of the methodology in terms of diagram, testing scripts and other deliverables
Hi, Amandeep. As I add more posts, I’ll keep your suggestion in mind and try to add more examples and graphical content. Thanks for reading!
Hi, Bhu. I think you’re right, to some degree: Agile looks great on paper. Only when organizations are in the midst of a transformation do they begin to realize how difficult it is to reorient the way its teams work. Adjusting to the changes that agile demands requires effort from the entire organization and often takes several months before individuals begin to feel comfortable again. Updating requirements each sprint is just one part of that. The thrash of requirements is a problem that plagues every software project, but you must admit that a framework that gives the development team more opportunities to revisit and refine work is better than one that assumes all requirements can be identified at the outset. Having to assess progress, interface with the customer, and revise requirements each sprint might seem like it’s creating headaches, but consider the alternative. If you completed a project based on initial requirements-gathering, your customer might tell you to scrap your work and start over, which is a very expensive and time-consuming catastrophe.
As for your second comment, I’ll try to post something on test cases in the near future.
Hi, Adithya. Thanks for your comment. I’ll try to write a post on how agile handles quality assurance soon.
For other readers: If you have topics you’d like to see discussed here, feel free to request a post on a particular subject in the comments section. Thanks!
Can you give case studies relating to agile methodologies ?
Are there any case studies of using Agile methods for changing business processes? Our projects may require IT change, new build or purchase of 3rd party applications. Some are business process only changes. Currently, we approach most business process projects using the waterfall method while applying project management and continuous improvement. Currently, my role is “Business Project Manager” in the finance industry. My background is both business and IT. I started learning/using Agile until I moved to the business side. Thank you.
i appreciate the positives of this method, but is there a way to reduce the over work that a QA team and Developer team do. Like many times it is felt that agile method of working may come up with a requirement which requires you to rethink of the framework you are using as a solution.. Or it only tackled with your negotiable talent with the clients. i am just wondering.. can you please through in some light on this as well..
Hi, Vignesh and Aaron. I don’t have any case studies that I’ve authored personally, but Danube has some great ones up at the customers section of its web site: http://danube.com/customers. They’re quick reads that break down the problems companies were facing before turning to agile project management, how they made the transformations, and, of course, the results. I’ve definitely gotten some good ideas for my team from reading about how other companies have handled similar challenges.
Aaron: If your company is implementing agile, there are two great white papers on the site that address the challenges of that transformation. Part one is here: http://danube.com/system/files/WP_Enterprise_Strategy_1.pdf. Hope this helps!
Good overview what about the broader application of agile methods in business i.e. not just in software development?
Agile process works if you have the right team with the right skills sets. I lost my job because I was not “Agile” enough. I could not meet my sprint requirements, because I did not have the skills set. Things that I knew, I had no problems with. Things I did not know, I failed miserably at them.
So overall, it’s a process I won’t be using in business venture going forward. I can meet my deliverables so other way.
I am agree with admin that agile gives us flexibility to revisit the requirement based on customer unwanted or additional demand….
Also if we can have some use cases and diagram presentation then that would be great help.
Nice overview and introduction to agile approach. There are still many poeople out there who have never heard about agile way of working.
I have been in the agile world for several years now, but sometimes forget to talk to beginners in a way they understand.
Keep up the good work!
Agile Methodologies are usually recommended for small projects that require immediate resolution for teams of 2 and with direct user involvement. Massive or secured projects are mostly served best with the traditional specification detailed approach to project or system developments.
Short and simple “Inspect & adapt ”
one need to read further to get into this methodology
Avinash