I recently wrote a post on Scrum mistakes that I have seen practiced throughout my career. At first I wanted to write why Scrum is bad - or about the bad parts of it. However instead I decided to write about why scrum can be a great agile methodology. As there are some positive aspects of scrum.
Creating 14 days of focus
Alright you got me. Sprints do not have to be 14 days even though this has always been the case for me. However scrum is meant to create focus and avoid disturbances. This is done by having the developers only work on what is in the sprint backlog. The scrum master helps this process by removing impediments. If your team has a clear goal (and not several goals + many small maintenance tasks) this creates focus. It enables the team to work towards a common goal for the current iteration.
Retrospectives
Retrospectives together with Daily scrum meetings are the strongest tools in Scrum, I believe. Retrospectives are a way to iteratively improve your process. Everyone gets heard and recurring impediments and issues are discussed. Retrospectives can be done in many ways to fit exactly your team. The goal is to bring things into light and improve our process. Often both the good and bad of the previous sprint is discussed.
As a team is becoming more mature, retrospectives may be less relevant as fewer items arise. However I still think as the world changes around us so will our processes - so we will have to adjust our agile approach as we go.
Daily scrum
So what is one of the most important principles in agile? "Individuals and interactions over processes and tools". Alright you got me, The daily scrum could be considered a "process", however it is there to increase communication and interactions. The daily scrum is a meeting where you get to know what the rest of the team is working on and has worked on. Most importantly, team members that need help or have impediments can raise this during this meeting. The meeting is not for finding solutions but to figure out who will help solve this after daily scrum.
The important thing here is that this does not become a daily status meeting for project managers. This meeting is for the team. It should also be avoided to have long daily scrum meetings - as we do not wish to waste valuable development time. I usually say that great daily scrums are 5 minutes or less.
Sustainable pace
In scrum a sustainable pace is promoted. Even though the team may improve and thereby burning points faster it should still be sustainable. Over-committing sprint after sprint burns out the team and makes it harder to plan how much you can put into a sprint. Overcommitting often sets up the team for failure and when the team continuously fails to meet its goals, people get stressed and the morale drops.
I have also seen by overcommitting that nothing gets done in some sprints, as all tasks move into progress as we have to start everything now to get it done in time. But these items get done in the next sprint where they would naturally get done. So you have some really high and low velocity sprints instead of having sprints that have an average velocity.
Sustainable pace of course also has a well-being and employee happiness side to it.
Products not projects
I have written more on this in my article on scrum mistakes, so I will only give a quick summary here. A scrum team has a product portfolio which is as stable as possible. This means that the team is not put together just to do a single project but creates new products and maintains them. These may be smaller or larger and make up the team's product portfolio. However with projects the team is likely put together just to do that project. Then split apart when the project is done. When the team owns the product the team is more stable. It is also easier to place the maintenance tasks when the project is over, if the team is still there. It is even easier if they own the product.
I like to say that projects are done when the deadline is met (or not?) products are done when they are dead. Often the word product is used together with the word MVP. As you release something early and built upon it.
Easy to cope with changes
This seemed to be the big selling point back in the day for agile methodologies. This was often put into contrast with waterfall. However most developers that I have met have actually never tried waterfall. The reason why scrum is good at handling changes is that you have short iterations. After a sprint if something has changed you can reprioritise for the next sprint. You may also end up in a situation where you mid sprint figure out that what you have planned for is no longer viable. Here you have the possibility to cancel the sprint and go ahead and start a new one. You will fail the sprint, but you are not wasting more precious time. If the items on the backlog are refined then starting a new sprint is straight forward.
This together with short iterations also encourages YAGNI - You are not gonna need it. Some features will be skipped, due to them not being prioritised or simply not needed.
Wrapping it up
All of the above can be used outside Scrum - no matter the agile methodology you use. They are not Scrum exclusive but come built into the package that is Scrum. There are unmentioned items on this list such as refinement and the use of scrum boards, I have left them out as they are part of most methodologies.
That was my list, I hope you liked it! If you have any disagreements, let me know in the comments below! :)