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


98 thoughts on “Agile Methodology

  1. Jay

    Hi there,

    This tutorial is immensely useful, I learnt a lot.

    Would you consider making the videos downloadable though? Of course, you could always watermark to ensure your credit. That would help people who are not always connected to learn offline.

    Thanks in any case.


  2. Joanne

    Nice, short, easy to understand overview. Just an edit: the first sentance of the second pararaph under What’s Wrong With Traditional Approaches? is missing a word: “It’s easy to ? the problems…”

  3. Marie

    I used the training to get up to speed with current practices because I am re-entering the workforce after being away for 5 years starting my family. The training modules were very helpful and I feel that I gained the knowledge I needed quickly. It feels good to be back!

  4. Abhishek

    Great… ! Key points mentioned very well in short and crisp video and scrum card.

    I really liked that lot of things mentioned about the attitude of scrum team and culture required by product owner, Scrum master and team for a successful delivery.

  5. Amar Bhaskar

    Thanks this is very useful information and i went through this trying to prepare for a short speech on why agile project management.

  6. rui

    I’m just getting into SCRUM, and this training series is simply great – so, thank you :)
    On a quick note, the “next” link at the end of part 4, which should point to part 5, seems to link back to part 4…

  7. Patrick Gribben

    Have you ever seen a scrum? There are two sides and they clash. The thought of clashing heads with our fragrant srum master was a daily distraction. Second but. Have you ever tried to sprint right after a sprint? Emil Zatopek could do it but most sprinters can’t.

    This is not to diss the methodology. I’ve used it and been subjected to it. It works well.

  8. Prabhu Muthaiyan

    Really a worth reading for all who is new to agile. Every points have been put in short and clear. Good one team, Kudos!

  9. Matt Bossemeyer

    As someone who is completely new to Scrum, this series was incredibly helpful and entertaining as well. Very nicely done! I also find it interesting how many similarities there are between Agile and Lean Manufacturing (from which the training indicated some Agile concepts are derived), as well as between facilitating Scrum teams and Kaizen events (essentially the Lean equivalent of a Sprint).

    Thank you for creating and sharing this.

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>