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. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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. :)