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.

Comments (4) -

  • Pawel Brodzinski

    1/22/2010 3:53:29 AM | Reply

    Very insightful thoughts. This however brings me to my old opinion about agile. Agile is sold as a game-changer in software development and/or project management. That's perfectly fine. The problem is not everyone wants to agree for rule changes.

    From my perspective these are customers who hamper agile adoption most. I don't want to judge whether they do right thing or wrong thing (although <a href="">agility versus predictability</a> argument remains valid). You can't even say whether hampering agile adoption is a bad thing after all.

    Actually sometimes I thing people convincing us to agile forget about their own advice: "perfect is the enemy of good." If it doesn't broken don't fix it. If it is broken but no one really cares about it don't fix it.

  • vukoje

    1/22/2010 5:25:54 PM | Reply


    I agree there is absolutely no silver bullet, and that agility is often advocated as one. There is "agile hype" going on currently and I respect any thoughtful criticism.

    I see agility in development as adopting and welcoming change in code and also in customer requirements. If customer agreed on predictability vs. change, I would still embrace changes in code because code will be changed even if requirements don't.    

  • Management Training

    4/29/2010 4:46:23 AM | Reply

    I like the Rawsthorne concept of agility as well. I think it's a very practical and realistic way to deal with expectations when it comes to programming new products. I wish I'd gone to that seminar, but your summary tells me enough. Thanks

  • Training Management Software

    4/30/2010 4:29:13 AM | Reply

    Good tips every high-level programmer should know. Processes indeed don't solve problems, humans do. It's great to see that people are moving out of mechanical thinking and re-introducing human agency. Thanks for sharing your summary with us!