The Nuts and Bolts of Agile and Scrum

The Nuts and Bolts of Agile and Scrum

By J. LeRoy Ward,  PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL

Agile and Scrum: What’s the difference?

It seems like almost every company, regardless of their industry, is practicing Agile and Scrum in some way and at some level of proficiency. If you’re new to Agile and Scrum, you may be scratching your head wondering first, what are they? And, second, what’s the difference between the two?

What is Agile?

First and foremost, Agile is a philosophy, an approach to work (think producing software or some other product) that says we will have more satisfied customers if we break up our project into iterations than try to do the whole thing at once. As we complete each iteration we have a workable increment of the product. The customer will examine it and provide feedback that we can use for the next iteration. We continue with this iterative, incremental approach until the customer is completely satisfied. An Agile approach significantly reduces the risk of customer dissatisfaction.

This is markedly different from the Waterfall approach where requirements are collected at the outset and then the team, with very little customer interaction, builds the entire product which is then delivered to the customer for acceptance. The Waterfall approach, while useful for certain projects, has proven completely unsatisfactory for projects where a high level of customer interaction is required because of the uncertainty inherent in the end product.

The Agile philosophy is best described in the Agile Manifesto, written in 2001.

Because Agile is a philosophy, it can be implemented in many different ways. One of those is Scrum. Let’s take a look

What is Scrum?

Scrum is the world’s most popular way to implement Agile. It’s not a methodology; rather it’s a framework, but with some very specific “rules of the road,” which you can find in The Scrum Guide, written by Sutherland and Schwaber. Here’s how Scrum works.

The Scrum Team is comprised of a Scrum Master, Product Owner, and the Development Team. (Note: there are no Project Managers in Scrum!) The Scrum Master is a servant leader who makes sure the Development Team follows the Scrum process. The Scrum Master also provides interference for the Scrum Team from outsiders. One important point: the Scrum Master is not the boss!

The Product Owner (PO) is responsible for maximizing the value of the product the Development Team is producing. The PO works very closely with the Development Team, helping them understand what’s important by managing the Product Backlog which is a rank-ordered list of all features, functions, requirements, enhancements, and/or fixes related to a specific product.

The Development Team does the work! They are self-organizing and make all the decisions regarding how to do the work and define what “Done” means. Each backlog item is accomplished in a series of Sprints, or iterations, which last no longer than 4 weeks. A Sprint Review is held at the end of a Sprint where the PO reviews the results.

Each day of the Sprint, the Scrum Team meets for fifteen minutes in a “daily standup,” where they answer three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. What obstacles are in your way?

The Team is not briefing the PO or Scrum Master. They are briefing each other.

Scrum is very easy to understand but is difficult to master because of the organizational change that needs to occur to implement it. Thousands of companies are using Scrum with very impressive results. Yours may find it helpful as well.

About the Author
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.

Comments (5)

  • Monica Nicolescu

    Brief, concise and sharp – just to the point ! Thank you.

    Monica Nicolescu, MBA, PMP, MSc

  • Srinivas Bothala

    Very insightful article ….. who define the DoD (definition of Done) ? is that PO or Scrum team ? I have seen and experienced that PO has a larger say in articulating DoD …please confirm

  • LeRoy Ward

    Thanks for your question Srinivas. It’s a great one for sure. Here is the DoD from The Scrum Guide by Schwaber and Sutherland, the co-founders of Scrum:

    Definition of “Done”
    When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

    The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done”.

    Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. If the definition of “Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.

    If “Done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done”.

    Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

    As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is a standard for any work done on it.

    And here’s my view. The client, or user, is the person who ultimately defines Done. If they don’t get what they wanted or expected then the product is not Done and the project is unsuccessful. Sure, we can have multiple levels of done DURING a project, but in the END It’s the client who decides if it’s done or not.

  • Srinivas Bothala

    Thank you for the detailed response with appropriate scenarios. This really helped

  • Srinivas Bothala

    Greetings ! could you help share your thoughts on this query – Does co-located / distributed PO impact Agile teams functionality ? I mean, what is advisable work model , have one PO stationed with Agile team or having 02 different PO working with Distributed teams on same scrum project ?

Leave Comment