Vukoje's blog about software development

Things learned at Scrum Master training

Last month I have attended Scrum Master training at Faculty of Organizational Sciences in Belgrade. My mentor was excellent Dan Rawsthorne, with huge experience in production and strong hold in agile development. His experience gave his opinions huge credibility and his agile approach gave me a completely new view point to Scrum compared to one I have gained from Ken Schwaber’s book.

Here is list of my most interesting notes from training:


  • Brains solve problems, not processes. Process should only exist to enable focusing on brain power. Scrum is designed to force us to make hard decisions.
  • Agility is opposite to prediction. We can not control the world, we can only adapt to it and that requires constant attention which is hard. Waterfall gives illusion of control and false comfort.
  • Every team member is doing the best they can, but not the best they could be doing.” This is really interesting statement and I think that one should always remember it when evaluating and improving team abilities.
  • Programmer’s job is to create value, not to write code.
  • Perfect is the enemy of good. Good is what we want, perfect is impossible.  
  • There are no “I don’t knows” in Scrum, every decision has to have good reason which should be known to all (or most of) team members.
  • Scrum is about committing, not about knowing. If you focus on knowing, you will be too slow. If you are not sure, build something and get feedback as fast as possible. You are committing to agreement, not to tasks. Tasks are there to help you commit. Do something and than get better.
  • You can not build quality back in to the code, you can only replace it. Regular questions like “Has anyone written code he’s not proud of?” can help identify problematic implementations. If they can’t be addressed right away, related correction tasks should be added to product backlog.



  • When product is reviewed on meeting, developers have urge to demonstrate unfinished functionalities and demonstrate only happy paths in Use Cases. Unfinished functionalities create false impression of faster product development which can only lead to shortening of deadlines and later confrontations with stakeholders. “Happy paths” often hide real world usage scenarios that are most problematic and that should be discussed the most.
  • Always time box exploration tasks.
  • Scrum Master can lead only one team because it is full time job. SM can also be team member, but you have to bear in mind that his team duties can lead to neglecting of SM responsibilities. SM shouldn’t be Product Owner because that would concentrate too much power in one person that can destroy self organization and initiative if SM doesn’t control his urge to control. Micromanagement is obstacle to self organization.
  • At the end Product Owner is the boss (decision maker). Team can only do it’s best to prove its concepts. PO has veto powers all the time, but he should control urge to use them.
  • Scrum doesn’t fit teams that aren’t constantly trying to improve them selves. If you can't imagine your tem being self organized and taking initiative, then that is probably because you really can't, and no methodology will help you.