Recently, I was asked by a colleague why I like Scrum. I didn’t have a good answer at hand immediately, and since then the question bugged me. Therefore it’s time to give you my top ten now:
- Team Spirit
- Continuum Of Work Pressure
- Don’t Assume, Show
- Team Knowledge Over Experts
- Control Is Good, Presentation Is Better
- Continuous Improvement
- True Incremental Development
- No One-Man Shows
- ROI Is The King
- Fun
1. Team Spirit
Scrum provides an environment that allows a team spirit to grow and to build up a strong team. I’ve worked in a couple of teams during my professional career and in my spare time. It comes down to always the same key points for me:
- Is there a clear goal (e.g. Sprint goal, Release goal, we want to win this match, we want to give the audience of our concert a good performance)?
- Can the team do whatever it thinks will get them to the goal (self-organizing)?
- Is success celebrated?
2. Continuum Of Work Pressure
Looking back at my times in non-agile projects there was almost always the same problem. You have a bunch of requirements to implement and a deadline. Normally, the deadline is somewhat far in the future (> 2 months) giving you no real estimate about how you are doing to get to your release goal until last minute panic takes over.
Scrum – with its short Sprint cycles – puts constant pressure on the team. That sounds negative at first but it helps to get things done and the Velocity and Planning gives you an instrument to steer how much pressure you want to put on the team. If the team handles this correctly then the result is that the pressure is in a range that makes the team very effective but with no burn-out signs: you do as much as is possible, the whole team is very focused but the team is not overworked (which results only in bad quality, leading to more work, leading to even worse quality and so on).
3. Don’t Assume, Show
I really like Sprint Reviews when you can show-off to the customer and other interested stake-holders what your team has accomplished in this sprint.
Okay, the “I-have-no-technical-knowledge-and-ask-for-unrealistic-things” stake-holder can be a pain but are your end users geeks like you or people like your customer? Truth hurts sometimes!
Therefore, show everything you’ve got and make the best of the feedback you get.
This is especially important when the team is not sure what you should do exactly. Take advantage of the Sprint Review to hear what your customer has to say.
This approach is so much more effective than having requirements meeting before you wrote any code and nobody (no, not even the developer) has a clue how the application has to come out.
4. Team Knowledge Over Experts
Before we used Scrum, our teams had experts for everything. There was the UI expert, the DB guy, the “you-name-it” specialist. These developers were very productive in their area of expertise but they introduced a lot of blocking scenarios in the development process and nobody risked to enter the backyard of an expert.
Nowadays using Scrum, every team member takes the task from the Story Board with the highest priority she or he can contribute. Note that in my team not everybody can do everything, there are still experts on some areas. But why not pair-program to get the basics correct and reviewed by the expert and the fill in the blanks alone? This way of working spreads knowledge which is important if the expert likes to have holidays from time to time. Furthermore, it improves the estimation skills of the team.
5. Control Is Good, Presentation Is Better
In each team there is some need for control:
- How are we estimating?
- Is the Story Board updated?
- Are all invitations for the next Sprint Review sent?
- Has someone organized the Apéro?
However, if the team is controlled whether it gets things done then this is bad. Much better is that the team shows what it has accomplished:
- Daily Sprint Meeting: what did I accomplish in the last 24 hours?
- Sprint Review: what did the team accomplish in the last Sprint?
Show what you’ve done and don’t let you being controlled.
6. Continuous Improvement
Retrospectives are the way to make you happy. In my team there is a continuous flow of new ideas how to improve how we build software:
- Rearrange office
- Tweak continuous integration
- Craft flags to show when someone does not want to be disturbed
We take an hour per Sprint to discuss what was good, what could have been better, rants and ideas. This really helps to get a team motivated and performing.
7. True Incremental Development
Normally, you can’t develop a single major feature completely in one Sprint, there is simply not enough time. Sounds bad? No, the opposite is the case. Because you don’t have time to do all in one sprint, there is the opportunity to do the most important part, get feedback from your customer, learn from your experience on this particular domain and set-up a plan for the next Sprint. This makes development faster and the result is what your customer wants (at least what she or he said to you).
8. No One-Man Shows
In Swiss-German there is the term “Gärtlidänke” (backyard thinking, everyone has his own private backyard) that describes what happens in a lot of development teams:
Every single developer is responsible for his or her own part of the whole application. Other developers normally do not know about what’s going on inside the other’s “backyard” or do not risk to take a step inside. Until someone has to because someone left the team or is on vacation.
Scrum can prevent you from this. If there a less “backyards” per Sprint than developers then they have to share. Simple but very effective for spreading knowledge and responsibility.
9. ROI Is The King
Do you hate endless discussions whether to do something this or the other way? There’s only one real solution, show your customer the Return-On-Investment for each solution INCLUDING the time and cost involved to get a decision.
10. Fun
Scrum is simply more fun than any other project management process I know. The main reason for me is that it focuses on people, communication and working software, and enables you to get rid of all blocking inefficiencies to get successful.
Enough of my brain dump! Go ahead and write what you think about Scrum or my article in the comment section.
