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

Introduction to Scrum

Introduction to Scrum video

 

33 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…
    Thanks

  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: 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!

  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
    Avinash

  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

    Susanta,

    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

    Hi,
    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?

    Thanks.

  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?

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>