Waterfall: you're hired to build a house. the client tells you how many rooms he needs, how many windows, etc. then you build a house. then client tells you that he needs to use a living room as a plane hangar and the bedroom should be painted in purple
Scrum: you're hired to build a house. client comes by every week to tell you what he likes and doesn't like so you can make changes before it's too late. sometimes the client comes in the middle of the week and tells you that he's showing the house to his friends tomorrow and it would be nice if there was a fireplace in the living room. and most of the time the client isn't interested in technical details so spending a week making pillars to support the second floor is not a good idea because you'll have nothing to show
Develop a product prototype for 2 weeks, in a team of people.
Demonstrate the working prototype to other developers, business people and customers/users. Get feedback on how to improve it.
In the team, reflect how the last two weeks went. Agree on things to improve.
Repeat steps 1.-4., to incrementally enhance and improve the product. Ship the product, if you want to.
The “2 weeks” is called “sprint length”. It could be anything up to 4 weeks instead.
Step 1 is called “sprint planning”. The decision what to build is made by the “product owner” role, the decision how much to build is made by “developers“.
Step 2 is called „sprint“. The developers have the main responsibility here. A „daily scrum“ meeting makes sure everybody is on the same page, problems can be communicated and if necessary, replanning of details can occur.
Step 3 is called „sprint review“. It involves the team, and outside stakeholders invited by the product owner.
Step 4 is a team activity.
There‘s another role I did not mention: the Scrum Master. She makes sure the above process is understood and followed by the team and organization. And she helps people with collaboration and actively removes impediments.
Actually, I simplified things a bit in step 1: there is a plan for more than 2 weeks - the product backlog, maintained by the Product Owner. And a plan for 2 weeks, called sprint backlog, maintained by the developers.
Both plans always need to reflect reality and need to be revised frequently.
Even if you have different responsibilities, Scrum works best if all people involved collaborate daily, starting with creating the items in the Product Backlog.
Many things can go wrong when implementing Scrum. That’s why Scrum doesn’t always have a good reputation. Those things can have to do with contracts, budgeting, bonuses, a command & control leadership style, fights between departments and lack of technical practices like test automation. So think twice before blaming the Scrum ideas for that.
Executed well, I have seen it to be an effective way to develop complex products.
I agree with most of what you've said, except #2:"Develop a product prototype for 2 weeks".
During the sprint, the development team have to create what is called an increment. As stated in the Scrum Guide, "The Increment is the sum of all the Product Backlog items completed during a Sprint and the
value of the increments of all previous Sprints".
To put it in simpler terms, during at the end of the sprint, the dev team has to deliver a piece of software that is actually functional and is properly integrated with the existing system/functionalities.
A prototype is basically a proof of concept. It's basically something that... sort of works... but isn't meant to be shipped to a customer.
To be clear: none of these usages is "right" or "wrong", it's just a different usage of the term.
And if what I say is correct, I completely agree with what you're saying. :)
I was not aware of these 2 different types of prototypes.
Indeed we were thinking of different "prototypes".
If evolutionary prototype is what you meant, then I retract what I said. :)
Robert's father is sick. He was a poor man until late but recently he has some money to take care of things. They were too poor to afford any beds or furniture at home. But laying down on the cold floor is too much for the old man. He went to the carpenter to make a new bed. Robert wants the bed in 2 weeks but he also has some custom requirements. He wants a post like thing on which he can hang the drip/medicine. He wants a small retractable tray on which his father can keep the plates which he used to eat and a few other such requirements.
Carpenter tells him that it is impossible to get him such a bed in 2 weeks as he needs to build it from scratch.
But carpenter comes up with a solution. His father does not need facilities like the food plate tray immediately. The need of the hour is to avoid lying on the cold floor. So carpenter promises to deliver the board on which the legs will be later attached, in 2 weeks. Robert got the board in 2 weeks as promised and in the next 2 weeks, the carpenter worked on the legs. He completed them and attached it to tje board he delivered previously. Eventhough the legs were done later, carpenter did leave the provisions to attach the legs as he had the plan inhis mind. In this way, he slowly added features to the bed to give Robert the kind of furniture he had asked for without making his dad lie on the floor for too long. This is scrum/agile development. 😂
If the carpenter asked for 8 months to deliver the bed and his dad used to suffer the cold floor amd insects, that is waterfall.
Hope I wasn't too lame... 😂😂
This is the saddest story and now I cannot hear “agile” and not think of a poor family :-/
Previously Agile(scrum) would always remind me of us in the room with cookies and our funny board with lots of colors and user stories and also my team members leaving chocolate on it for me :-/
Why couldn’t you come up with a less sad story, and how’d those smilies fit in with this devastating story :-)))))) enough internet for today!
The Agile Manifesto and its accompanying principles describe in abstract terms how developers and teams should build software. By design it contains no concrete details. For example, one of the principles is:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
How do you make sure that developers communicate face-to-face?
Business people and developers must work together daily throughout the project.
How should they work together? What does that mean?
Scrum is an implementation of Agile. It is a set of guidelines that, if followed, should mean that a team is working according to Agile principles. Whether or not that is the case is debated. Some would say that you can practice Scrum but totally lose sight of Agile. That doesn't make Scrum bad. It just means that we have to understand the underlying principles.
Here's some interesting reading on how the success of Scrum depends on Agile principles:
Scrum is a product development framework. The team continues to work on a product until it goes off market. What happens afterwards is not restricted by Scrum. So there are no projects.
Top comments (11)
Waterfall: you're hired to build a house. the client tells you how many rooms he needs, how many windows, etc. then you build a house. then client tells you that he needs to use a living room as a plane hangar and the bedroom should be painted in purple
Scrum: you're hired to build a house. client comes by every week to tell you what he likes and doesn't like so you can make changes before it's too late. sometimes the client comes in the middle of the week and tells you that he's showing the house to his friends tomorrow and it would be nice if there was a fireplace in the living room. and most of the time the client isn't interested in technical details so spending a week making pillars to support the second floor is not a good idea because you'll have nothing to show
Hahaha that is awesome.
The “2 weeks” is called “sprint length”. It could be anything up to 4 weeks instead.
Step 1 is called “sprint planning”. The decision what to build is made by the “product owner” role, the decision how much to build is made by “developers“.
Step 2 is called „sprint“. The developers have the main responsibility here. A „daily scrum“ meeting makes sure everybody is on the same page, problems can be communicated and if necessary, replanning of details can occur.
Step 3 is called „sprint review“. It involves the team, and outside stakeholders invited by the product owner.
Step 4 is a team activity.
There‘s another role I did not mention: the Scrum Master. She makes sure the above process is understood and followed by the team and organization. And she helps people with collaboration and actively removes impediments.
Actually, I simplified things a bit in step 1: there is a plan for more than 2 weeks - the product backlog, maintained by the Product Owner. And a plan for 2 weeks, called sprint backlog, maintained by the developers.
Both plans always need to reflect reality and need to be revised frequently.
Even if you have different responsibilities, Scrum works best if all people involved collaborate daily, starting with creating the items in the Product Backlog.
Many things can go wrong when implementing Scrum. That’s why Scrum doesn’t always have a good reputation. Those things can have to do with contracts, budgeting, bonuses, a command & control leadership style, fights between departments and lack of technical practices like test automation. So think twice before blaming the Scrum ideas for that.
Executed well, I have seen it to be an effective way to develop complex products.
I agree with most of what you've said, except #2:"Develop a product prototype for 2 weeks".
During the sprint, the development team have to create what is called an increment. As stated in the Scrum Guide, "The Increment is the sum of all the Product Backlog items completed during a Sprint and the
value of the increments of all previous Sprints".
To put it in simpler terms, during at the end of the sprint, the dev team has to deliver a piece of software that is actually functional and is properly integrated with the existing system/functionalities.
A prototype is basically a proof of concept. It's basically something that... sort of works... but isn't meant to be shipped to a customer.
I think we use the term prototype differently.
I am talking about an evolutionary prototype.
You are talking about a throwaway protoype.
To be clear: none of these usages is "right" or "wrong", it's just a different usage of the term.
And if what I say is correct, I completely agree with what you're saying. :)
I was not aware of these 2 different types of prototypes.
Indeed we were thinking of different "prototypes".
If evolutionary prototype is what you meant, then I retract what I said. :)
Robert's father is sick. He was a poor man until late but recently he has some money to take care of things. They were too poor to afford any beds or furniture at home. But laying down on the cold floor is too much for the old man. He went to the carpenter to make a new bed. Robert wants the bed in 2 weeks but he also has some custom requirements. He wants a post like thing on which he can hang the drip/medicine. He wants a small retractable tray on which his father can keep the plates which he used to eat and a few other such requirements.
Carpenter tells him that it is impossible to get him such a bed in 2 weeks as he needs to build it from scratch.
But carpenter comes up with a solution. His father does not need facilities like the food plate tray immediately. The need of the hour is to avoid lying on the cold floor. So carpenter promises to deliver the board on which the legs will be later attached, in 2 weeks. Robert got the board in 2 weeks as promised and in the next 2 weeks, the carpenter worked on the legs. He completed them and attached it to tje board he delivered previously. Eventhough the legs were done later, carpenter did leave the provisions to attach the legs as he had the plan inhis mind. In this way, he slowly added features to the bed to give Robert the kind of furniture he had asked for without making his dad lie on the floor for too long. This is scrum/agile development. 😂
If the carpenter asked for 8 months to deliver the bed and his dad used to suffer the cold floor amd insects, that is waterfall.
Hope I wasn't too lame... 😂😂
This is the saddest story and now I cannot hear “agile” and not think of a poor family :-/
Previously Agile(scrum) would always remind me of us in the room with cookies and our funny board with lots of colors and user stories and also my team members leaving chocolate on it for me :-/
Why couldn’t you come up with a less sad story, and how’d those smilies fit in with this devastating story :-)))))) enough internet for today!
The Agile Manifesto and its accompanying principles describe in abstract terms how developers and teams should build software. By design it contains no concrete details. For example, one of the principles is:
How do you make sure that developers communicate face-to-face?
How should they work together? What does that mean?
Scrum is an implementation of Agile. It is a set of guidelines that, if followed, should mean that a team is working according to Agile principles. Whether or not that is the case is debated. Some would say that you can practice Scrum but totally lose sight of Agile. That doesn't make Scrum bad. It just means that we have to understand the underlying principles.
Here's some interesting reading on how the success of Scrum depends on Agile principles:
The True Corruption of Agile
FlaccidScrum - that's really the title. There's no space in it.
When the project is completed does the team usually get laid off?
Scrum is a product development framework. The team continues to work on a product until it goes off market. What happens afterwards is not restricted by Scrum. So there are no projects.