Agile and Scrum

Hi Alfredo,

Welcome!

1. I recommend reading the agile manifesto here, and then following the links to the principles, and about the authors and manifesto: http://agilemanifesto.org/
2. The Scrum Guide refers to Scrum as a lightweight framework. Is there a problem with referring to it as a framework?

Hi Simon and thanks for your answer. 

Regarding Scrum Framework, I mean the case when somebody asks to compare Scrum with waterfall. I think (it may be mistake) it is not correct to compare waterfall methodology with Agile, much more correct to compare waterfall with Scrum. But Scrum is Framework and waterfall is methodology. 

Well, on one hand I understand what you mean. On the other hand:

1. If you read agile manifesto, you might notice that it sort of compares two approaches. But yes, it is not really specifically about waterfall. It compares philosophies. Waterfall might also be a philosophy.

2. Scrum is pretty well defined. Waterfall on the other hand might come in many, many forms. I assume some of its forms could be described in a document also as concise as the Scrum Guide. Or even shorter! Therefore, in this specific example, I would not really be afraid to compare a "framework" to a "methodology".

The whole distinction of "framework" vs "process" vs "methodology" was just meant to foster understanding of the fact that not all teams do Scrum in the same way: the skeleton will and should be the same, but the skin may vary.

Agile is a mindset above all else. Within Agile, there are many different frameworks and methodologies used while still incorporating the Agile Mindset. Scrum is called a framework because there are not strict, rigid rules that must be followed; instead it is flexible and can be used for many different products across countless industries. A process or method dictates HOW developers will do their job, a Framework lets the Developers decide how to do their job. 

You can 100% compare waterfall to scrum. Waterfall includes no customer feedback throughout the process, only at the beginning when they initiate the request and the end when they receive the end product. Scrum includes the customer frequently throughout the process to make sure the customer receives what they want and that there are no surprises when the customer receives the end product. 

Here is a great example I heard from one of my trainers of my PSM class. Think about the process of ordering a pizza through Pizza Hut and going into Subway to get a sandwich. For PH, you call the store and order a pizza for delivery. You order a Large Pepperoni with Mushrooms. PH employee says "A Large Pepperoni with Mushrooms, we will have it there in 30 minutes." So 30 minutes late, the delivery guy shows up and presents you a Large Pepperoni pizza with no mushrooms. So you say "I ordered mushrooms, where are they?" Delivery guys replies "I didn't see that mushrooms were supposed to be on there". So you send it back and to get the pizza you ordered. So you lose out because it takes another hour to get the pizza, PH loses because the lost resources of time and ingredients because of remaking the pizza. 

Now consider the process of going to Subway. You start by saying "I'd like a footlong sandwich please" Subway employee says "great, what kind of bread?" You reply with "Wholewheat" so the Subway employee grabs a footlong loaf of wholewheat for your sandwich. Next you move on to the meat, you put your request in, the subway employee adds it to the sandwich, then cheese, followed by veggies, and then ending with a sauce. At the end when you receive your sandwich, you'll have the one that you want and there won't be any surprises or let downs because you were included in the entire process.

Pizza Hut is like Waterfall, the customer's time invested is short (maybe 2 minutes on the phone) and painless. You're not included in the process, you just hope and trust that they get it right and deliver to you what you wanted. Subway is like scrum. Each station is a sprint and you're involved through each sprint and able to inspect the progress. If you get a sandwich that is not what you wanted, you can't really blame Subway for not reading your mind, it's your responsibility to give proper feedback to ensure you receive what you want. 

I love that analogy because the majority of the population can relate to that, you don't need to know anything about the specifics of scrum or waterfalll to be able to understand the difference. 

Agile is an evolution of Lean that aims to change the way things are managed. Several frameworks and methodologies fall into the definition of Agile, but Agile itself is not a framework or methodology. Agile would be the generic general description, whereas Scrum or XP would be the more specific name. Then you have Kanban which misses the mark as a pure Agile method, but it meets enough of the criteria to be classified as an Agile method.

Like a mammal. You could ask what a mammal is. It would provide a general description of animals that need to meet certain criteria and sometimes there is overlap, a skunk or human would be specific types of mammals, and a duck-billed platypus would be an overlap. 

To be Agile it must meet most criteria that not everyone can agree on but is generally described in the Agile Manifesto for software engineering projects.

Agile has more uses than software and whole corporations can and have adopted Agile in general business usage

For non-software descriptions most people can agree that Agile must:

1. Be focused on the product or outcome as the measurable result.

2. Utilize continuous improvement (it is a child of Lean) with regular inspections

3. Provide Iterative and Incremental releases of a potentially usable product (Kanban is slightly different here - rather than incremental it is continuously releasing with no timeboxed increments, this is also different than just the kanban cards one might use in Scrum or Lean Manufacturing)

4. Allow for and embrace changes and adaptation throughout the process

5. Utilize servant-leadership philosophy

6. Allow teams to have more control over how they do the work

I like the pizza/sandwich comparison, Curtis. Thank you.

Dear all,

Sorry for late answer from my side. Thanks a lot for your comprehensive answers. Pizza - Sandwich comparison is great :))

I like the example of the Pizza Hut versus the Subway sandwich. Funny thing is that, the way I understand Waterfall and agile, you can also use the pizza hut example for agile and  the Subway for Waterfall:

Pizza hut: 1st iteration I get a pizza without the mushrooms, I provide feedback and in the second iteration I get a pizza with mushrooms. Both served pizzas were edible and delivered value though. I could have also decided to eat the pizza without the mushrooms if I was very hungry. Ergo: Agile

Subway: Since I the example I dont get my increment untill I have picked all the ingredients one by one I cannot taste and provide feedback. Ergo: Waterfall.

Thanks for your reply, Jeroen. Very good comparison, too

Interesting way of turning around the Pizza Hut and Subway examples. It reminds me of when people say that a Kanban board with more than three columns is like waterfall. e.g. To Do, Coding, Ready to Review, Reviewing, Ready to Test, Testing, Ready to Release, Done.

In essence, while Subway have a more explicit process and greater customer collaboration, their lead time is almost always going to be less than that of a pizza delivery; so the lack of iteration is mitigated. For a whole host of reasons, not-least hygiene, the way to iterate at Subway would be to queue up once, order, eat, and queue up once more. Most people would wait until their next visit to iterate.

In the Pizza Hut example, they've released a defective pizza. A customer made a specific purchase, and received something other than what was agreed. It's still useful to look for opportunities to gain feedback even with a defective release, but it's a side-effect of a failing process, rather than a system optimized for feedback.

Another thing that also came to mind is what happens when you make a team responsible for UX, and particularly product discovery. Essentially, Subway have made a decision to carry out a series of short customer interviews at various stages of the development process.

Rather than releasing a "Done" sandwich based on assumptions, and asking for feedback, they have chosen the considerably cheaper option of talking to the customer to validate and eliminate assumptions.

This works extremely well for onion, where the customer is usually well informed about the choice they are making, but less well for sauces, where a first-time customer is unlikely to know how spicy the Chipotle sauce is, and many customers outside of the US will have no idea what Ranch is.