Ten Tips for the New Scrummer
What makes a good Scrummer? Well, if I knew an exact formula, I would be too busy selling it to Scrum-wannabees than writing tips about Scrum 😉
On a more serious note, the differences between organizations is so great, that any ten tips will never be good enough for all.
Nonetheless, I’ve gathered some of the things I found helpful in early stages of Scrum adaptations.
I hope that many will find this useful, since ‘Early’ is also organization specific – some teams I’ve encountered have become self-managed in less than 10 weeks, whereas other teams still struggled with the basic concepts after six months (and more) of doing Scrum.
So here it is – my Ten Tips for the New Scrummer:
- Start with a project small enough to become a success, yet important enough to attract decision makers.
It is not uncommon to see organizations start with multiple concurrent teams going Scrum, which makes the transition effort much greater than required. Instead, generate success by building a Scrum team that will give management the ‘appetite’ for more. - Celebrate small successes.
Focus on what’s working well. Peel-off all the cynicism that we so frequently meet in IT organizations, and find that people still love when told that they are doing good. - Appreciate that Scrum is a very different than traditional software development projects.
It is unrealistic to expect people who didn’t do Scrum before, or are fairly new to Scrum, to adapt to concepts that may seem counterintuitive at first. - Read the Scrum Guide. If you’ve already read it, read it again after a while.
This is a great concise description of Scrum, and you’ll learn something new with each time you re-read it. - Speak of forecast, and refrain from talking about commitments.
There are good reasons why the authors of Scrum chose ‘forecast’ as the team’s indication of what they will achieve in an iteration. - Start-off with sticky notes on a wall or whiteboard, and postpone choosing an electronic Scrum tool for as long as you can.
Deploying a change-request on a physical Scrum board costs almost nothing. Asking for a change request on a commercial tool might block you for a long time. Making your own tool – unless you plan to sell it for big bucks – don’t do there! - Learn. A lot.
The team you are a member of should expect itself to inspect-and-adapt indefinitely. What better way do you have than increasing your knowledge to have great ideas for your retrospectives? Read books, attend courses and workshops, read blogposts. The return on this investment is priceless. - Learn to trust relative estimations.
Learning to estimate and to continuously plan in a way that reduces overloading teams is critical, and one of the hardest transitions from traditional software projects. Relative estimations are key to letting go of unrealistic plans. - Excel in your engineering practices. No matter how well you do Scrum, if your testing cycle is too time consuming, if the feedback-loop on writing new code takes too long, or if your coding standards are inadequate for short iterations – you will hit a brick wall without paying your technical debt.
- What are your 10 tips?
Really, what ten tips would you give someone who is thinking about doing Scrum?
If you can’t come up with ten good tips, either you’ve got more learning to do, or you are going through a stressed phase and need to let go, or maybe Scrum is not right for you. Whatever the reasons, if you want to succeed in Scrum (and agile SW development in general), find ways to become passionate about it.
Of course I could be writing fifty or a hundred tips or more: invest in agile requirements, sharpen your Definition of Done, how to decide on the Iteration length, Always have a well-groomed backlog for Iteration start, … I arbitrarily chose a good selection of important ten tips.
Wanna give Scrum a go and not sure how? Start with a course. It will take you through the paradigm shift that comes with agile, you’ll get to try it out in a workshop setting, and it’s fun. You’ll be far more equipped for your first Sprint than any blogpost you’ll read. Drop me a line if you’re not sure.
Becoming agile 