Agile Methodology

What Is Agile?

The Agile movement proposes alternatives to traditional project management. Agile approaches are typically used in software development to help businesses respond to unpredictability.

What is Scrum?

Scrum Reference Card

The Scrum Reference Card

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.

What’s Wrong With Traditional Approaches?

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, each phase depending on the previous. 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 the lack of communication between the specialized groups that complete each phase of work.

It’s easy to see the problems with the waterfall method. It assumes that every requirement can be identified before any design or coding occurs. Could you tell a team of developers everything that needed to be in a software product before any of 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. Your 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?

Today very few organizations openly admit to doing waterfall or traditional command and control. But those habits persist.

Why Agile?

Agile development provides opportunities to assess the direction 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. When a team stops and re-evaluates the direction of a project every two weeks, there’s time to steer it in another direction.

This “inspect-and-adapt” approach to development reduces development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, stakeholders have recurring opportunities to calibrate releases for success in the real world. Agile development helps companies build the right product. Instead of committing to market a piece of software that hasn’t 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. Agile development preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

Introduction to Scrum

Introduction to Scrum video


115 thoughts on “Agile Methodology

  1. Amandeep

    It helps me a lot to understand agile methodlogy,but you sould use more examples and diagrams to make it more clear…

  2. Bhu

    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?

  3. Adithya Chandrashekar

    I shall be thankful if i can get the process (Quality Assurance aspect)for this methodology

  4. Wissam Khater

    It would be perfect if i can get the details of the methodology in terms of diagram, testing scripts and other deliverables

  5. admin Post author

    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!

  6. admin Post author

    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.

  7. admin Post author

    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!

  8. Aaron

    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.

  9. Lokesh

    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..

  10. admin Post author

    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: 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: Hope this helps!

  11. gtuc

    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.

  12. Deenanath Dinkar

    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.

  13. Henrik Larsson

    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!

  14. Angie

    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.

  15. avinash shitole

    Short and simple “Inspect & adapt ”
    one need to read further to get into this methodology

  16. David Baltimore

    I am seeing this methodology implemented in many corporate environments. How do you deal with “feature creep” as sales and marketing will always continue to add more bells and whistles.

    Also if you don’t plan your work and work your plan you end up with people wanting to move “load baring” walls and tear out major portions of code to go in another direction.

    There is always version 2!

  17. Santosh

    What is your suggestion for the managers who are going to manage project in Agile method ?. Any specific sequence of steps to follow ?. Any pitfalls to avoid ?. How to build confidence in client since the manager is managing the project for the first time in Agile way ?.

  18. Susanta

    I don’t understand agile saves development effort. From QA point of view test case that designed earlier needs to be changed again and again.

  19. admin Post author


    If we could get the requirements perfectly the first time, we wouldn’t need Scrum. But as far as I know, all new products require iterations before they are useful to anyone. Scrum attempts to speed up these iterations so we learn faster what the customer really needed.

  20. Daniel Erasmus

    If you cannot get sign off on the business requirements prior to design how do you calculate what the project will cost?

  21. Mahesh

    – Inspect & adapt
    — Time & cost saver to market with ‘analysis paralysis’
    — More flexible & error reducible (due to re-evaluation at specific regular tiem interval)
    — Best option for client & there business
    — Can go with the current trend & requirements in new as well as existing application. Competative with current market place.
    — A bit hectic for developers,testers,managers. (but think how much scope of new learning in just one single application/module/process developement)

  22. Peter Bjorkman

    I am still curious about the types of projects APM best lends itself too. All examples I see relate to software development. Is that all?

  23. Kathleen

    If companies are looking for a Project Manager and they do Agile/Scrum, are they really looking for a product owner since there is no “project manager”?

  24. admin Post author

    Kathleen, yes, companies that say they do Agile/Scrum but advertise project manager positions are probably actually doing some kind of traditional/Agile hybrid and don’t really know what they want. The benefits of Scrum will be pretty limited in such environments, though an effective Scrum Master might be able to nudge them one way or the other.

  25. admin Post author

    Peter, Agile is partially inspired by “lean manufacturing” ideas extracted from the Toyota Production System. Agile techniques are gaining popularity in software development because we’ve learned how to reduce the slope of the cost of change curve for software more than we have for physical objects like bridges and houses. But we’re starting to see examples in other fields.

  26. Irving

    Thanks for nice sharing your provided information is very useful for all blog readers. You define agile and scrum very beautifully. These are very famous in these days among different organizations. Which promotes a project environment of adaptation, teamwork, self-organization, rapid delivery and client focus.

  27. shefali

    It’s a wonderful piece of information on Agile!
    Could you please also write on the role of a Business Analyst in Agile?
    Also, are use cases not a part of Agile?


  28. Jacob Sina

    Excellent Tutorial.
    My concerns are the role of the Manual Tester – is there place for him/her since the testing begins when there is a potentially usable product?

    How about the UI automation tester.

    With SCRUM and Unit Testing – what does a manual tester do in the mean time – I know test design and test data preparation – but every sprint?

  29. Dev

    Hi Admin,
    This article is really helpful. Thank you.

    Could you please explain how the change in requirement is kept track of ? Do we follow any documentation process here ?

  30. Chiru Toleti


    I have a doubt.
    If we understand the complete requirements of a project, We can search for different possibilites then we can pickup a short way to develop the complete software. But according to agile methodology we get a piece of requirements from client, then we go for designing, coding and so on. Here we may go through a long way to complete the project instead of picking shortways.
    Im not against to agile, i just wanted to know about the technology clearly.
    I obsolutely aggree that we can release first phase in a short time without any consequnces.


  31. Karthik

    This overview is very helpful.
    But, i would like to know how this Agile methodology helps the QA team in their perspective.
    Wih this methodology what are all the things which needs some rework and what are the advantages for QA?

  32. Mr Sketch

    I have just discovered Agile, due to recently joining a company using this methodology and I find it a very positive environment. Working in the testing environment, I think the quickly changeable development to be challenging, but if you follow the sprint cycles using a milestone testing system you know what changes to expect and can easily spot unexpected behavior ensuring a more robust and manageable testing environment

  33. Ray

    Is there we can have a written version of practical demo on Agile? Like how do we maintain records, how do we keep track of progress made on application development and so on, Daily standup meetings, dashboard and so on…. Not the theoretical part ……. We know there are two weeks to four weeks sprint and so on but what really will benefit most readers will be if they have a written practical application knowledge of Agile methodology…..

  34. Niharika Tripathi

    Nice piece of info.

    What i understood is that Agile generally does not reduce the development effort rather it can ensure the product validity or usability so that efforts does not gets waste and could be useful at the end.

    please confirm on my understansing.

  35. Saeed Lajami

    I owe it to you, my first and main source of learning about the Agile Methodology…didn’t need to go anywhere else.

  36. Plamen

    That was really helpful – thanks a lot. So I will be able to manage the dev team. My issues are more about the commercial aspects. If you have to answer an RFP with defined prices you should be able to tell what functionalities will be delivered. To my understanding scrum requires time&material pricing – not the favourite method for pricing for most of the customers. Or I am mistaken?

  37. Bradford

    Development teams have long wanted to ignore all best practices and just “wing it”. Agile gives them what they want. This sounds good on paper but ignores the majority of controls that need to be in place to secure information.

    Example: If I don’t define that I have a business requirement to secure personally identifiable information before I start the project and just tell the team what I want it to look and feel like, then I ignore the important controls that need to be in place in most of today’s systems and wont realize it until it is too late.

  38. admin Post author

    Plamen, Scrum is really just three roles, 4-5 defined meetings, and a few rules. So Scrum has nothing to say about contracts, pricing, etc.

    That said, one advantage of the Agile Approach is that it allows for “drip funding” — seeing results sooner allows the buyer to pay just a little up front, then make go/no-go decisions along the way. Agile or not, the track record of software companies achieving cost/schedule goals of fixed-scope/fixed-price contracts is terrible, partly because no one really knew what the scope was at the outset. But if you must deal with contracts, there are some techniques to mitigate the risk. Some unpredictability is necessary, but unnecessary unpredictability can be reduced by keeping the same team together, keeping the Sprint duration constant, and using techniques such as TDD to reduce undetected regression failures and other surprises. For more good ideas, see .

  39. admin Post author

    Bradford, I’m curious what gives you these impressions. I’ve seen reliable and secure systems built using Agile approaches, and some awfully insecure systems built using traditional approaches.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>