The question I suggest is what you meant by “speed”?
- Speed of product development?
- Speed of understanding of the product?
- Speed as a term of team adulthood?
- Speed with which they run to the coffee machine?
I’m going to get out of speed of product development because most of the questions are about this.
However, the focus on this type of speed is not what Scrum focuses on.Scrum prefers quality than productivity. Higher productivity is often inversely proportional to the quality of a product.
Especially with a starting team it will take a while before a team reaches a higher speed.The focus should be on knowledge amusing the build product. After that, the focus is to reach a stable speed.
It’s sound contradictory, but the best way to accelerate a team is to take them less at the same time.
By working together and building a product functionality together, the team learns to know each other and the product better.This begins when collaborating in pairs (also known as “pair Programming”). Then the focus shifts to together as team Product Backlog parts picking up and rounding.
This is also the reason why a Sprint goal is agreed during the Sprint schedule.It’s a focus point. The team wants to succeed and deliver value. Just think about how you feel when you’ve done something that doesn’t need to be necessary for something that appears to be very much appreciated after you’ve done it.
A Sprint goal often has a connection to a business goal.As a result, the Product Backlog components (Product Backlog items or PBi-in IT often User stories) that belong to that Sprint target are often highly valued by the users (at least, if the Product Owner has done a good job).
The questions we often ask during the daily Scrum do not refer to the Sprint goal for nothing.(See proposal for questions in the Scrum guide)
If we focus as a team on a PBi and work on that with forces and ask us the question, what to do to get this PBi to completed (Done) today?Then we are most likely to get off.
My answer to your question is therefore:
- Facilitating learning
- (a.o. by:) Collaborate more
This requires that the Product Backlog is clearly (Ready) for the development team so that they do not make any assumptions and need to do rework.
- Ensure that the Product Backlog is Ready enough
If you drive a team up to speed they will make more mistakes.We also know this from our own daily practice (hasty rush is rarely good). This also applies to overtime work. A team that is driven to productivity and overtime will make even more mistakes and the speed you measure is no longer reliable.
Suppose a team overworked a Saturday to get more done in a sprint and you take the speed (velocity) of this sprint as a yardstick for the next.Shouldn’t the team overwork AGAIN?
At scrum we love a speed that you can keep full (sustainable pace).Speed that can keep a team full, without too many additional mistakes and for a longer period of product development will increase automatically.
However, what you will see in experienced teams is that they will not by definition produce a product faster, however they will probably deliver better and better product without mistakes by improving their process.They will also get to know the product AND the users better and thus yield more value. And THAT’s the real focus of Scrum and Agile.