As I have already written, I have attended a ScrumMaster certification in Munich on thursday and friday, done by Boris Gloger at TNG Technology Consulting. At this point I want to thank Boris and Andreas for the great Scrum session, it really gave me a much clearer impression of what Scrum is and should be. I also want to thank TNG for hosting the event, you have a great office, the food was good, I liked it very much!

So for me what are the most important things I learned about Scrum and being a (now certified) ScrumMaster? Here is a quick review about that:

1. “there is no truth” – every Scrum Trainer may tell you something different about implementing Scrum (or parts of it). That may be as it is, but you need to remember, there is no single true only valid method of Scrum. Do what works for you and your company – but stick to it (and improve it over time)! But the basic Scrum elements should be there, otherwise don’t call it Scrum.
2. Skill No. 1 the ScrumMaster has to learn: to say “NO” to the boss! You can’t protect your team, you can’t even try to change your organisation (especially the bad parts in it) if you can’t say “NO” to the boss at some level. A ScrumMaster is like a fish swimming against the river, he goes against the rules in the organisation preventing the team to be successful in delivering quality (potentially shippable) software.
3. don’t try to use electronic tools too much – a task board, product backlog and impediment backlog can easily be managed with sticky notes and a movable board/flipchart. It makes handling the information (especially when estimating and in daily scrum meetings) much easier.
4. never ever ever ever estimate the effort – only estimate the functionalities and their relation to each other. Velocity changes with the constraints and technical details but the functionalty stays the same – and so does the estimation. I believe that’s the hardest part to make clear to Management guys who still want to think in men days and currency. So give it to them but don’t estimate the implementation, estimate the functionalities and you can give them a release plan that (should) work(s).
5. work with your Product Owner and make sure he presents the Vision and big picture behind the product to the team – make him repeat that as often as possible so it doesn’t get lost.
6. keep the roles separated – a ScrumMaster should never be a Product Owner or be part of the team. You ask why? Because he could not fulfil his role to protect the team or create a safe environment for them.
7. the ScrumMaster helps the team, but he doesn’t do the work for them! Be sure to let the team handle stuff like Burn Down Chart or running the daily scrum.
8. Be there for them and help them if they need it, and be sure to remove all impediments they might have. Try to find out if there are any impediuments the team might not know about (e.g. when a task isn’t done after like 2 days, ask why it isn’t and find out what the possible impediment could be.
9. get a clear “definition of done” from the team. Make sure the team includes possible constraints set by company rules e.g. documentation.
10. make everybody stick to the time box. Expect them to be there on time and don’t use more time than being specified!

Ok thing those are the most important items I got from the last 2 days. There was a lot more information (naturally) but if you need (or want) to know more about Scrum and the techniques, I recommend Boris’ book Scrum: Produkte zuverlässig und schnell entwickeln and Your Scrum Checklist: Scrum Hard Facts: Roles. Artefacts. All Meetings.